Skip to content

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:

  1. Entity-level — per-table overrides (highest priority)
  2. Workspace-level — workspace-wide defaults
  3. 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.country

If 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:

json
{
  "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.

json
{
  "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.

json
{
  "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.

json
{
  "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.

json
{
  "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 responses
  • apiVisible: 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.

LevelGETPOSTPUTDELETE
NONE (default)Requires API keyRequires API keyRequires API keyRequires API key
READ_ONLYPublicRequires API keyRequires API keyRequires API key
READ_WRITEPublicPublicPublicPublic

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:

  1. The API checks the entity's publicAccess setting
  2. If NONE — returns 401 Unauthorized
  3. If READ_ONLY — allows GET requests, returns 401 for mutations
  4. 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).

SchemaStack Documentation