Public API Settings
Last updated
Public API Settings is the screen for delivering a project’s items and assets to the outside. It is under Public API in the left menu. The screen consists of two tabs, Reading and Posting.
Reading
Section titled “Reading”The settings for delivering a model’s data to the outside. It has two sections, the per-model delivery switch and API keys.
Per-model delivery
Section titled “Per-model delivery”The table lists the project’s models, with an “Assets” row at the end. The Assets row is the setting for whether the project’s assets are delivered as a whole. The columns are as follows.
| Column | Content |
|---|---|
| Enable | Whether that model (or the assets) is delivered. Shown when the project’s visibility is Private |
| Model | The name of the model |
| Endpoint | The URL data is delivered from. “GET” is shown before the URL |
- When the project’s visibility is PUBLIC, every model is delivered. The switch column is not shown.
- When the project’s visibility is Private, you choose per model whether it is delivered.
A model with delivery enabled can be read by anyone who knows the endpoint. Such a model cannot be restricted through API key permissions. Only items whose status is published are delivered.
API keys
Section titled “API keys”An API key controls the scope of delivery when the project’s visibility is Private. It cannot be used when the project’s visibility is PUBLIC.
The list shows “Name” and “Key”. Each key holds the following items.
| Item | Content |
|---|---|
| Name | The name that identifies the key |
| Description | A description of what the key is for |
| API Key | The secret token string used for API requests. It can be regenerated |
| Permissions | The models and assets this key allows to be delivered |
Posting
Section titled “Posting”The setting that allows data to be submitted anonymously from outside. Because submissions are accepted without authentication, the sites they can come from are limited. When a submission is accepted, a new item is created in that model in draft status. It is not published, and no request is created. Only Owner and Maintainer can change this setting.
Allowed Origins
Section titled “Allowed Origins”The list of sites whose submissions are accepted. An origin identifies a website by its scheme and domain name, as in https://example.com. It does not include the path of a page beyond that.
What is checked against this list are API requests that carry an Origin header. Only requests from origins registered in the list are accepted, and when no origin is registered, all of them are rejected. API requests that carry no Origin header, such as those from programs on a server or command-line tools, are not checked against the list. You can register more than one origin, and the number registered is shown. “Clear all” deletes all of them.
What you enter is the scheme (http or https) and the domain name. You can add a port number if you need one. A URL that includes a page path or a query, such as https://example.com/form, cannot be registered. When there are several subdomains, register them one by one. If you enter a value that does not match the format, “Please enter a valid origin (e.g. https://example.com).” is shown. A trailing slash is removed on registration.
Per-model posting
Section titled “Per-model posting”The table lists the project’s models. Assets are out of scope. The columns are as follows.
| Column | Content |
|---|---|
| Enable | Whether submissions to that model are accepted |
| Model | The name of the model |
| Endpoint | The URL submissions are sent to. “POST” is shown before the URL |
| (no header) | The “Copy” button that copies an example API request to that model as a cURL command |
When no allowed origin is registered, this table cannot be operated.
How to call the API
Section titled “How to call the API”For how to actually use the API, including the structure of the endpoints, authentication, and how to write a request, see the CMS Developer Docs.