API Settings
The Workspace API provides configuration at multiple levels to control behavior, security, and access.
Settings Hierarchy
Settings are resolved in order of specificity:
- Entity-level — per-table overrides (highest priority)
- Workspace-level — workspace-wide defaults
- System default — hardcoded fallback (lowest priority)
Workspace Settings
Configure workspace-wide API defaults in the Admin app under Workspace Settings > API Config.
Max Expand Depth
Controls how deeply relationships can be expanded. Default: 3.
GET /api/v1/acme-corp/sales/orders?expand=customer.address.countryIf the depth exceeds the configured limit, expansion stops at the maximum level.
CORS Allowed Origins
Restrict which browser origins can call the API. By default, all origins are allowed (*).
Set specific origins to lock down browser access:
{
"maxExpandDepth": 5,
"corsAllowedOrigins": [
"https://app.example.com",
"https://dashboard.example.com"
]
}TIP
CORS restrictions only affect browser-based requests. Server-to-server requests (cURL, Zapier, Make) are not affected by CORS.
Setting corsAllowedOrigins to null or an empty array allows all origins.
Entity Settings
Configure per-entity API behavior in the Admin app under View Settings > API Config. These override workspace-level defaults.
Default Expand
Relationships to expand by default when no ?expand parameter is provided.
{
"defaultExpand": "customer,items.product"
}Max Expand Depth
Overrides the workspace-level max expand depth for this specific entity.
Default Fields
Fields to return by default when no ?fields parameter is provided. null means all fields.
{
"defaultFields": "id,name,email,created_at"
}Expandable Relationships
Whitelist of relationships that can be expanded. If set, only these relationships are allowed in ?expand. null means all relationships are expandable.
{
"expandableRelationships": "customer,items"
}Attempting to expand a non-whitelisted relationship returns 400 Bad Request.
Filterable Fields
Whitelist of fields that can be used in ?filter[...] parameters. If set, only these fields are allowed. null means all fields are filterable.
{
"filterableFields": "name,email,created_at,status"
}Column API Visibility
Individual columns can be hidden from API responses using the apiVisible flag. This is separate from the UI visible/hidden setting.
apiVisible: true(default) — column appears in API responsesapiVisible: false— column is excluded from API responses
Use this to hide sensitive data (SSN, internal notes, etc.) from the REST API while keeping it visible in the admin UI.
INFO
The primary key (id) column is always included in API responses regardless of the apiVisible setting.
Public Access
Entities can be configured for unauthenticated access, allowing requests without an API key.
| Level | GET | POST | PUT | DELETE |
|---|---|---|---|---|
| NONE (default) | Requires API key | Requires API key | Requires API key | Requires API key |
| READ_ONLY | Public | Requires API key | Requires API key | Requires API key |
| READ_WRITE | Public | Public | Public | Public |
Use Cases
- READ_ONLY: Public product catalogs, reference data, company directories
- READ_WRITE: Contact forms, feedback submissions, public registrations
Behavior
When a request arrives without an Authorization header:
- The API checks the entity's
publicAccesssetting - If
NONE— returns401 Unauthorized - If
READ_ONLY— allows GET requests, returns401for mutations - If
READ_WRITE— allows all operations
When an Authorization header is present, the API key is always validated and its permissions take priority over the public access setting.
WARNING
Public READ_WRITE access means anyone can create, update, and delete records without authentication. Use this only for entities where this is intentionally desired (e.g., form submissions).