Querying content

Metabind exposes content through three query surfaces. Each suits a different consumer; all return the same content model.

API	Best for
REST	Server-to-server, bulk operations, simple integrations
GraphQL	Web and mobile clients needing flexible joins and shape selection
Mobile SDKs (iOS, Android)	Native apps with offline caching, BindJS rendering

This page is a tour of each surface. Deeper API references live in the REST API and GraphQL API tabs.

REST

Endpoint shape:

GET https://api.metabind.ai/api/v1/organizations/{org}/projects/{project}/content
GET https://api.metabind.ai/api/v1/organizations/{org}/projects/{project}/content/{contentId}
GET https://api.metabind.ai/api/v1/organizations/{org}/projects/{project}/content/search

Authenticate with your project API key in the x-api-key header:

curl -H "x-api-key: YOUR_API_KEY" \
  "https://api.metabind.ai/api/v1/organizations/YOUR_ORG_ID/projects/YOUR_PROJECT_ID/content?typeId=YOUR_TYPE_ID&limit=10"

REST works well for:

Backend services pulling content for SSR.
Cron jobs syncing content to other systems.
Bulk operations (import/migrate/archive).

For the full REST API, see the REST API tab.

GraphQL

Endpoint:

POST https://api.metabind.ai/graphql

Example query:

query GetArticles {
  contents(typeId: "YOUR_TYPE_ID", limit: 10) {
    data {
      id
      name
      content
      tags
      updatedAt
    }
  }
}

GraphQL is the recommended pathway for:

Web apps that need to fetch only the fields they render.
Mobile apps that want to batch related queries.
Any client where reducing roundtrips matters.

Subscriptions are also supported — see GraphQL: Subscriptions for live content updates.

Native SDKs

The iOS and Android SDKs wrap this GraphQL API with a local cache and BindJS rendering. On iOS, MetabindClient exposes async fetchers — fetchContent(id:) for a single entry and fetchContents(typeId:limit:) for a list — plus streamContent(id:) and subscribeToContent(id:) for cache-then-network and live streams. The Android SDK exposes coroutine and Flow equivalents through ComponentRepository. For installation, configuration, and rendering, see the Mobile SDKs:

iOS SDK

MetabindContent — fetch and render content with SwiftUI.

Android SDK

metabind-content-android — fetch and render content with Compose.

Choosing draft or production

REST and GraphQL requests made with an API key return published content only; neither has a draft flag. To read draft content, create a preview link and pass its token to the GraphQL preview query:

query { preview(token: "YOUR_PREVIEW_TOKEN") { ... on ContentPreview { contentId content { id name } } } }

Use draft for editor previews and staging environments. Default to published in production.

Caching

Caching is on by default at the CDN edge for published content. Cache keys include the project, content type, query parameters, and locale. Invalidation:

Automatic. Publishing or unpublishing an entry invalidates that entry’s cached responses within seconds.

The iOS and Android SDKs add a local cache on top — entries persist between app launches and update via background refresh.

Pagination

Both APIs use cursors:

REST. ?limit=10&lastKey=<lastKey> — pass pagination.lastKey from the previous response to get the next page.
GraphQL. cursor and limit arguments; responses include pagination { cursor hasMore }.

The iOS and Android SDKs take the same cursor and limit arguments; pass the returned cursor to get the next page.

Filtering

REST supports filter parameters per content type. GraphQL exposes typed filter inputs:

query {
  contents(
    typeId: "YOUR_TYPE_ID",
    filter: { tags: { any: ["featured", "running"] } }
  ) {
    data { id, name }
  }
}

For complex queries, save a search and reuse it via the saved searches API.

Resolved content

Content can be returned resolved, with its compiled code and the package data needed to render it. Avoids round trips for client rendering:

query {
  content(id: "abc-123") {
    name
    compiled
    resolvedPackage {
      package { version components }
      dependencies { version components }
    }
  }
}

REST has a /content/resolved endpoint with similar behavior.

When to use which

A few rules of thumb:

Native mobile app? Use the iOS/Android SDK. They handle caching, offline, and pair cleanly with BindJS.
Web app? Use GraphQL. Flexible queries, single-request data fetching, subscriptions for live updates.
Backend service? REST. Simple, well-cached, works with any HTTP client.
MCP App? Use a Data Tool that calls REST or GraphQL. The Data Tool pattern abstracts content fetching behind an AI-callable surface.

REST API

Full REST reference.

GraphQL API

Schema, queries, subscriptions.

Mobile SDKs

iOS and Android client libraries.

AI content creation

AI-driven content workflows.

Overview

Managing Content

AI Content Creation

Mobile SDKs for content

Sample Apps

GraphQL API

GraphQL Object Types

GraphQL Queries

GraphQL Subscriptions

GraphQL Advanced

Content MCP Server

Context

Discovery

Creation

Articles

Querying content

REST

GraphQL

Native SDKs

iOS SDK

Android SDK

Choosing draft or production

Caching

Filtering

Resolved content

When to use which

REST API

GraphQL API

Mobile SDKs

AI content creation

​REST

​GraphQL

​Native SDKs

iOS SDK

Android SDK

​Choosing draft or production

​Caching

​Pagination

​Filtering

​Resolved content

​When to use which

​Related

REST API

GraphQL API

Mobile SDKs

AI content creation

REST

GraphQL

Native SDKs

Choosing draft or production

Caching

Pagination

Filtering

Resolved content

When to use which

Related