canonical: https://jentic.com/apis/newt.so/newt # Newt So Newt API Newt is a Japanese headless CMS, and this spec documents its CDN API - the read-only delivery surface that powers production websites and apps. The three endpoints retrieve content lists with query filters, fetch a single content item by ID, and return app-level metadata for a space. Authentication uses a Bearer token (the CDN API token from the Newt dashboard) and the host is parameterised by the space's spaceUid, giving each tenant its own subdomain at {spaceUid}.cdn.newt.so. ## For AI agents Read content from a Newt headless CMS space via the CDN delivery API. Fetch lists with filters, single items by ID, and app metadata for production websites. ## Scope Does not handle content creation, updates, deletion, or asset uploads - use for read-only CDN delivery of Newt content only. ## Capabilities - Fetch a paginated list of content items from a Newt model with field, filter, and sort query parameters - Retrieve a single content item by its content ID for detail-page rendering - Read app-level metadata - including model definitions - through GET /space/apps/{appUid} - Authenticate with a CDN-scoped Bearer token isolated from the editing-side credentials - Resolve content via per-space subdomains using the spaceUid path parameter ## Use cases ### Headless Blog Delivery Marketing teams running a Newt-backed blog use GET /{appUid}/{modelUid} to fetch the latest posts at build time or request time. Query filters select published-only items, sorting orders by date, and the response feeds a static-site generator or server-rendered React or Next.js page. GET /{appUid}/{modelUid}/{contentId} powers the individual post detail pages. Example prompt: Fetch the 10 most recent published posts from the 'blog' model in app 'marketing' and render them on the homepage ### Marketing Site Build Pipeline Static-site generators query Newt's CDN API during the build step to assemble the full content set. GET /space/apps/{appUid} returns the model definitions so the build can validate field shapes, then per-model calls populate the rendered pages. This pattern keeps the live website served from the CDN while the build pipeline talks to Newt over the same API. Example prompt: List every model in the 'marketing' app, then fetch all content items from each model into a single JSON manifest ### Single-Item Lookup for Detail Pages When a visitor opens a permalink, the application needs only one content item - the post or product they clicked. GET /{appUid}/{modelUid}/{contentId} returns that item with all configured fields, avoiding a heavier list call. Combined with the Bearer token, the CDN API serves these reads at low latency from Newt's edge. Example prompt: Get the content item with id post-2026-launch from the 'blog' model in the 'marketing' app and return its title and body ### Agent-Driven Content Audit An AI agent uses Newt's CDN API through Jentic to audit which content items exist in production. The agent walks GET /space/apps/{appUid} for each app, then enumerates GET /{appUid}/{modelUid} for every model, building a snapshot the agent can compare against the editorial calendar. Jentic injects the Bearer token automatically. Example prompt: Build a JSON inventory of every model and every published content item across all apps in the space ## Key endpoints | Method | Path | Description | | --- | --- | --- | | GET | /{appUid}/{modelUid} | List content items in a model with filter, sort, and pagination | | GET | /{appUid}/{modelUid}/{contentId} | Fetch a single content item by ID | | GET | /space/apps/{appUid} | Get app metadata including model definitions | ## Key resources - **Contents** — Read content items in a model - list with filters or fetch by single content ID - **Apps** — Read app-level metadata, including the model definitions used by the contents endpoints ## Why Jentic - **Setup:** Wiring Newt by hand means learning its bearer token auth, building the per-space CDN subdomain (spaceUid.cdn.newt.so), and threading appUid, modelUid, and contentId yourself. Through Jentic you install once, import the Newt API from the API Directory, store the token once, and your agent calls it. - **Permission scoping:** Newt puts the app id in the URL path (/{appUid}/{modelUid}), so a rule can pin your agent to one app: it can read that app's models and content and nothing else. This CDN surface is read-only, so the agent has only fetch operations to call and no way to write or delete. - **Credential handling:** Your Newt CDN bearer token is stored once, encrypted, by your own Jentic One instance and injected into the Authorization header at execution time. It never enters the agent's prompt, logs, or context. - **Discovery method:** Agents search Jentic by intent such as 'fetch content from a Newt model' or 'get a single content item', and Jentic returns the matching Newt operation with its query parameter schema so the agent supplies appUid, modelUid, and filters without browsing the reference docs. ## Related APIs - **Contentful API** — Contentful is a global headless CMS with content delivery and management APIs - **Sanity API** — Sanity provides a structured-content backend with GROQ querying instead of REST filters - **Storyblok API** — Storyblok pairs a headless CMS with a visual editor and a similar CDN read API ## FAQ ### What authentication does the Newt CDN API use? The CDN API uses a Bearer token issued from the Newt dashboard. Through Jentic the token sits in the encrypted vault and Jentic injects the Authorization header on each call, so the agent never holds the raw credential. ### Can I filter and sort content with the Newt CDN API? Yes. GET /{appUid}/{modelUid} accepts query parameters for filtering by field values, sorting by any field, and paginating results. The exact parameters available depend on the model's schema, which can be inspected through GET /space/apps/{appUid}. ### What is the {spaceUid} placeholder in the Newt base URL? Each Newt tenant has its own subdomain - {spaceUid}.cdn.newt.so - so requests are scoped to the calling space. Through Jentic, spaceUid is supplied as a parameter when loading the operation, and Jentic constructs the full host URL automatically. ### How do I fetch a list of blog posts from Newt through Jentic? Search Jentic for 'fetch content from a newt model', load the GET /{appUid}/{modelUid} schema, and execute with appUid set to your app, modelUid set to 'blog' (or your model name), and any filters you need. Jentic injects the Bearer token automatically. ### Can the Newt CDN API write or update content? No. This spec covers the read-only CDN delivery API. Creating, updating, or deleting content is handled through the editing API surface, which is not part of this spec. ### Can I limit what my agent is allowed to do with the Newt API? Yes. Because you run Jentic One self-hosted, your own rules decide which Newt operations and credentials the agent may use, and Newt puts the app id in the URL path (/{appUid}/{modelUid}), so a rule can pin the agent to a single app and let it read only that app's models and content. The Newt CDN surface is read-only, so the agent only ever has the three GET operations to call: list content in a model, fetch a single content item by ID, and read app metadata. There is no create, update, or delete operation for the agent to reach, and the CDN bearer token stays with your instance rather than the agent.