Newt So Newt API

Name: Newt API
Brand: Newt API
Availability: InStock

✓ Official Vendor SpecMarketingContent Managementbearer3 EndpointsREST

For 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.

Install Jentic One Beta

Connect the Newt API to your agent

Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the Newt 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%2Fnewt.so%2Fnewt" | sh

Step 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%2Fnewt.so%2Fnewt" | sh
jentic register       # connects your agent to your Jentic One instance

Jentic 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.

Capabilities

What an agent can do with Newt API.

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}

GET STARTED

Start building with Newt API

Explore with Jentic One

View OpenAPI Document

Use Cases

Patterns agents use Newt API for, with concrete tasks.

★ 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.

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.

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.

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.

Build a JSON inventory of every model and every published content item across all apps in the space

Key Endpoints

3 endpoints — newt is a japanese headless cms, and this spec documents its cdn api - the read-only delivery surface that powers production websites and apps.

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

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

Why Jentic?

What agents get from Jentic-routed access to this vendor.

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 isolation

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.

Intent-based discovery

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.

FAQs

Specific to using Newt API through Jentic.

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.