canonical: https://jentic.com/apis/cosmicjs.com/cosmicjs

# Cosmicjs Cosmic API

Jentic publishes the only available OpenAPI specification for Cosmic API, keeping it validated and agent-ready. The Cosmic API is the v3 surface of the Cosmic headless CMS platform, exposing 16 endpoints to manage buckets, content objects, object types, object revisions, and media uploads. Authentication supports a Personal Access Token (cos_ prefix) sent as a bearer token plus per-bucket read and write keys passed as query parameters, which lets developers separate public read traffic from privileged write operations.

## For AI agents

Manage headless CMS content in Cosmic - list, create, update, and delete objects and object types, upload media, and track object revisions. Supports a bearer Personal Access Token plus per-bucket read/write keys.

## Scope

Does not handle visual page building, customer identity, or e-commerce checkout - use for Cosmic headless CMS object, type, revision, and media management only.

## Capabilities

- List, create, fetch, update, and delete content objects inside any bucket to power website and app content surfaces
- Track object history by adding revisions through the dedicated revisions endpoint
- Manage object types - the schemas that define content models - including creating and deleting type definitions
- Upload, update, and delete media assets attached to a bucket and reference them from objects
- Separate public reads from writes by routing read traffic through the bucket read key and writes through the write key
- Probe the API status endpoint to verify Cosmic availability before running batch jobs

## Use cases

### Headless CMS for a Website

Power a marketing site or app by storing pages, blog posts, and reusable components as Cosmic objects, organised by object type. The build pipeline reads objects through the bucket read key, while the editor's CMS uses a Personal Access Token to publish updates that flow into the next build.

Example prompt: On build, call GET `/buckets/{bucketSlug}/objects` with the bucket read key to fetch all published posts, render the static pages, and invalidate the CDN.

### AI-Generated Content Publishing

An AI workflow drafts product descriptions, blog posts, or release notes and publishes them directly into Cosmic by creating typed objects. Each generation that needs revising is recorded as a revision so editors can roll back without losing prior text.

Example prompt: Call POST `/buckets/{bucketSlug}/objects` with the generated object payload, then POST `/buckets/{bucketSlug}/objects/{objectId}/revisions` on every subsequent edit so editors can audit the history.

### Bulk Media Migration

When migrating assets from another CMS or DAM, upload images and documents to Cosmic in batches, then attach them to existing objects through metafields. The media endpoints support upload, update, and delete so the migration script can clean up failures without manual portal work.

Example prompt: For each asset call POST `/buckets/{bucketSlug}/media` to upload, store the returned media ID, and PATCH `/buckets/{bucketSlug}/objects/{objectId}` on the relevant content object to attach the new media reference.

### AI Agent Content Operations via Jentic

An agent assists editors with prompts like 'publish this draft as a blog post on Cosmic' or 'archive every product object older than two years' by mapping the request to the right Cosmic operation through Jentic. The agent reasons over content intent rather than memorising bucket slugs and HTTP methods.

Example prompt: Search Jentic for 'create Cosmic object' or 'delete Cosmic object', load the matching operation, and execute it with the bucket slug and object payload provided by the editor.

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| GET | `/buckets/{bucketSlug}/objects` | List objects in a bucket |
| POST | `/buckets/{bucketSlug}/objects` | Create a content object |
| PATCH | `/buckets/{bucketSlug}/objects/{objectId}` | Update a content object |
| DELETE | `/buckets/{bucketSlug}/objects/{objectId}` | Delete a content object |
| POST | `/buckets/{bucketSlug}/objects/{objectId}/revisions` | Add an object revision |
| GET | `/buckets/{bucketSlug}/object-types` | List object types |
| POST | `/buckets/{bucketSlug}/media` | Upload media to a bucket |

## Key resources

- **Status** — Health check for the Cosmic API.
- **Objects** — Create, read, update, delete, and list content objects inside a bucket.
- **Object Revisions** — Add a revision entry to track changes on an object.
- **Object Types** — Manage the schemas that define object structure inside a bucket.
- **Media** — Upload, update, and delete media assets attached to a bucket.

## Why Jentic

- **Setup:** Wiring Cosmic by hand means handling its bearer token plus separate read_key and write_key query parameters, pinning the v3 host, and coding your own object and media requests. Through Jentic you install once, import Cosmic from the API Directory, store the keys once, and your agent calls it.
- **Permission scoping:** Cosmic puts the bucket slug in the URL path (`/buckets/{bucketSlug}/objects`), so a rule can pin your agent to one bucket: it can work only within that bucket. You choose the operations it may call, so destructive ones like deleting an object are not included unless you add them.
- **Credential handling:** Your Cosmic keys are stored once, encrypted, by your own Jentic One instance and injected at execution time. They never enter the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'list objects in a bucket' or 'upload a media file', and Jentic returns the matching Cosmic operation with its input schema so the agent calls the right endpoint without browsing the reference docs.

## Related APIs

- **Contentful API** — Enterprise-focused headless CMS with deeper localisation, roles, and workflow features than Cosmic.
- **Sanity API** — Real-time, query-driven headless CMS with the GROQ query language.
- **Storyblok API** — Visual editor headless CMS focused on marketing and component-based pages.

## FAQ

### Why is there no official OpenAPI spec for Cosmic API?

Cosmic publishes API documentation but not a single OpenAPI specification. Jentic generates and maintains this spec so that AI agents and developers can call Cosmic API via structured tooling. It is validated against the live API and kept up to date. Get started with Jentic One, the self-hosted execution layer.

### What authentication does the Cosmic API use?

The API supports three credentials: a Personal Access Token with the cos_ prefix sent as a bearer Authorization header, plus per-bucket read_key and write_key values passed as query parameters. Through Jentic, all three are stored encrypted and the right one is injected per operation so the agent never sees the raw secret.

### Can I create new content objects with this API?

Yes. POST `/buckets/{bucketSlug}/objects` creates a new content object inside the named bucket, accepting the object's type slug, metafields, and slug as inputs. Use the bucket write key or a Personal Access Token for this operation.

### How do I track changes to a Cosmic object?

Call POST `/buckets/{bucketSlug}/objects/{objectId}/revisions` after each meaningful edit. Cosmic stores the revision so editors can audit history or roll back without external version control.

### What are the rate limits for the Cosmic API?

The OpenAPI spec does not declare numeric rate limits. Treat HTTP 429 responses as authoritative, back off using the Retry-After header where present, and consult the Cosmic dashboard for plan-specific limits before running heavy migrations.

### How do I upload media through Jentic?

Search Jentic for 'upload media to Cosmic', load POST `/buckets/{bucketSlug}/media`, and execute it with the file payload and bucket slug. Jentic returns the operation schema so the agent does not need to read Cosmic docs for the field names.

### Can I limit what my agent is allowed to do with the Cosmic API?

Yes. Because Jentic One is self-hosted, your own rules decide which Cosmic operations and credentials the agent may use. Since Cosmic puts the bucket slug in the URL path (`/buckets/{bucketSlug}/objects`), you can pin the agent to a single bucket so it only ever works within that one. You also choose the exact operations it can call, so destructive ones like DELETE `/buckets/{bucketSlug}/objects/{objectId}` stay out of reach unless you explicitly allow them.