> ## Documentation Index
> Fetch the complete documentation index at: https://docs.metabind.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Querying content
> Read content from your client apps using REST, GraphQL, and the mobile SDKs
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:
```bash theme={null}
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:
```graphql theme={null}
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](/graphql/subscriptions/overview) 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:
`MetabindContent` — fetch and render content with SwiftUI.
`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:
```graphql theme={null}
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=` — 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:
```graphql theme={null}
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](/rest/saved-searches/overview).
## 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:
```graphql theme={null}
query {
content(id: "abc-123") {
name
compiled
resolvedPackage {
package { version components }
dependencies { version components }
}
}
}
```
REST has a [`/content/resolved`](/rest/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.
## Related
Full REST reference.
Schema, queries, subscriptions.
iOS and Android client libraries.
AI-driven content workflows.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.