Install Jentic One Beta
Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the Cosmic API, or any other public or private API you need. You set the rules, the agent never sees your credentials, and every call is logged.
Two steps, two machines. Install the instance in a safe environment, then register your agent from wherever it runs.
Step 1: Jentic One Host machine
# On the machine that will host your Jentic One instance:
curl -fsSL "https://jentic.com/install.sh?src=apis&api=%2Fapis%2Fcosmicjs.com%2Fcosmicjs" | shStep 2: Agent machine
# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL "https://jentic.com/install.sh?src=apis&api=%2Fapis%2Fcosmicjs.com%2Fcosmicjs" | sh
jentic register # connects your agent to your Jentic One instanceJentic One is in public beta. The setup above keeps your agent separate from the instance, which is what you want before using real credentials: an agent running as the same OS user as Jentic One can read its stored keys directly. Just evaluating? A single local install is fine to start. See the secure deployment guide for the tiers.
What an agent can do with Cosmic API.
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
GET STARTED
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
Patterns agents use Cosmic API for, with concrete tasks.
★ 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.
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.
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.
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.
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.
16 endpoints — jentic publishes the only available openapi specification for cosmic api, keeping it validated and agent-ready.
METHOD
PATH
DESCRIPTION
/buckets/{bucketSlug}/objects
List objects in a bucket
/buckets/{bucketSlug}/objects
Create a content object
/buckets/{bucketSlug}/objects/{objectId}
Update a content object
/buckets/{bucketSlug}/objects/{objectId}
Delete a content object
/buckets/{bucketSlug}/objects/{objectId}/revisions
Add an object revision
/buckets/{bucketSlug}/object-types
List object types
/buckets/{bucketSlug}/media
Upload media to a bucket
/buckets/{bucketSlug}/objects
List objects in a bucket
/buckets/{bucketSlug}/objects
Create a content object
/buckets/{bucketSlug}/objects/{objectId}
Update a content object
/buckets/{bucketSlug}/objects/{objectId}
Delete a content object
/buckets/{bucketSlug}/objects/{objectId}/revisions
Add an object revision
/buckets/{bucketSlug}/object-types
List object types
/buckets/{bucketSlug}/media
Upload media to a bucket
What agents get from Jentic-routed access to this vendor.
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 isolation
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.
Intent-based discovery
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.
Alternatives and complements available in the Jentic catalogue.
Specific to using Cosmic API through Jentic.
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.
Know of an official OpenAPI document? Contribute it →
For 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.
Use for: List all blog post objects in my Cosmic bucket, Create a new content object of type 'product' in Cosmic, I want to update the body field of a Cosmic object, Delete an object that is no longer needed
Not supported: Does not handle visual page building, customer identity, or e-commerce checkout - use for Cosmic headless CMS object, type, revision, and media management only.
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.