Skip to main content
All Metabind API requests require authentication. The platform supports two authentication methods depending on your use case.

​
Route Structure

The Metabind API uses two route prefixes that determine which authentication method to use:
Route PrefixAuthenticationAccess LevelUse Case
/app/v1/JWT Bearer TokenFull CRUDCMS dashboard, admin operations
/api/v1/API Key (x-api-key)Read-onlyClient apps, content delivery
All endpoints are available via /app/v1/ with JWT authentication. Some endpoints are also available via /api/v1/ with API key authentication for read-only access to published content.

​
Bearer Token Authentication

For administrative operations and full API access, use JWT bearer tokens with the Admin API (/app/v1/ routes).

​
Obtaining a JWT Token

JWT tokens are obtained by signing into the Metabind CMS. After authentication, your session provides the JWT tokens used for API requests. For programmatic access to admin operations, you can:
  1. Sign into the Metabind CMS
  2. Use browser developer tools to inspect the Authorization header in API requests
  3. Copy the bearer token for use in your scripts or tools
JWT tokens expire periodically. For long-running integrations that require admin access, consider using the CMS interface or contact Metabind support for service account options.

​
Using Bearer Tokens

Include the JWT in the Authorization header: 
headers: {
  'Authorization': 'Bearer YOUR_JWT',
  'Content-Type': 'application/json'
}
Example request: 
curl -X GET "https://api.metabind.ai/app/v1/organizations/org123/projects/proj456/content" \
  -H "Authorization: Bearer YOUR_JWT"

​
API Key Authentication

For client applications consuming published content, use API key authentication with the Client API (/api/v1/ routes). This is the recommended approach for mobile apps, web frontends, and other client-side integrations.
When building client applications (iOS, Android, React, web), use the /api/v1/ routes with API keys. Reserve /app/v1/ routes for admin tools and CMS integrations that require full access.

​
REST Client API

Include the API key in the x-api-key header: 
headers: {
  'x-api-key': 'YOUR_API_KEY',
  'Content-Type': 'application/json'
}

​
GraphQL API

For the GraphQL API, use the same x-api-key header: 
headers: {
  'x-api-key': 'YOUR_API_KEY',
  'Content-Type': 'application/json'
}

​
WebSocket Subscriptions

For real-time subscriptions, include the API key in the connection parameters: 
connectionParams: {
  headers: {
    'x-api-key': 'YOUR_API_KEY'
  }
}

​
Obtaining API Keys

API keys are created and managed through the Metabind CMS:
  1. Navigate to your project settings
  2. Go to the API Keys section
  3. Click Create API Key
  4. Provide a name and optional description
  5. Copy the generated key (it won’t be shown again)
API keys are displayed only once when created. Store them securely. If you lose an API key, you’ll need to create a new one.

​
API Key Access

API keys provide read-only access to published content within their project scope. They cannot:
  • Create, update, or delete resources
  • Access draft content
  • Access administrative functions
For administrative operations, use bearer token authentication with appropriate user permissions.

​
Client API Endpoints

The following endpoints are available via /api/v1/ with API key authentication. All return published content only. For practical code examples using these endpoints, see Using API Keys.

​
Content Discovery

GET /api/v1/organizations/{organizationId}/projects/{projectId}/saved-searches

GET /api/v1/organizations/{organizationId}/projects/{projectId}/saved-searches/{savedSearchId}

POST /api/v1/organizations/{organizationId}/projects/{projectId}/saved-searches/{savedSearchId}/execute

GET /api/v1/organizations/{organizationId}/projects/{projectId}/tags

GET /api/v1/organizations/{organizationId}/projects/{projectId}/tags/{tagId}

GET /api/v1/organizations/{organizationId}/projects/{projectId}/content-types

GET /api/v1/organizations/{organizationId}/projects/{projectId}/content-types/{contentTypeId}

GET /api/v1/organizations/{organizationId}/projects/{projectId}/content-types/{contentTypeId}/versions

​
Content Access

GET /api/v1/organizations/{organizationId}/projects/{projectId}/components

GET /api/v1/organizations/{organizationId}/projects/{projectId}/components/{componentId}

GET /api/v1/organizations/{organizationId}/projects/{projectId}/packages

GET /api/v1/organizations/{organizationId}/projects/{projectId}/packages/{version}/resolved

GET /api/v1/organizations/{organizationId}/projects/{projectId}/content

GET /api/v1/organizations/{organizationId}/projects/{projectId}/content/{contentId}/resolved

GET /api/v1/organizations/{organizationId}/projects/{projectId}/assets

​
Real-time Updates

GET /api/v1/organizations/{organizationId}/projects/{projectId}/events

GET /api/v1/organizations/{organizationId}/projects/{projectId}/{resourceType}/events

GET /api/v1/organizations/{organizationId}/projects/{projectId}/{resourceType}/{resourceId}/events

​
Security Best Practices

API keys should be kept on the server side. For mobile apps, use a backend proxy or the GraphQL API with appropriate rate limiting.
Create separate API keys for development, staging, and production environments.
Periodically revoke old API keys and create new ones, especially if you suspect a key may have been compromised.
Delete API keys that are no longer in use to reduce your attack surface.