REST API

Every capability,
exposed as an API.

The dashboard is not the product. The API is. Every action in the Nimbu UI is a call to the same REST API your code can make. If the platform can do it, you can drive it from code.

Explore the docs Book a demo

api ~ nimbu

# fetch published blog entries

$ curl https://api.nimbu.io/channels/blog/entries \

$ -H "Authorization: Bearer $NIMBU_TOKEN"

{"count":2,"results":[{"slug":"why-we-still-ship-liquid",...}]}

# same API the dashboard uses

Read it without logging in

A request and what comes back. No SDK required to understand the shape, just an HTTP call against the same API the dashboard uses.

bash

# Fetch published entries from a channel

$ curl https://api.nimbu.io/channels/blog/entries \

$ -H "Authorization: Bearer $NIMBU_TOKEN" \

$ -H "Accept: application/json"

{"count": 2, "results": [{"id": "6620e1f0...",

"title_en": "Why we still ship Liquid",

"title_fr": "Pourquoi nous livrons toujours du Liquid",

"slug": "why-we-still-ship-liquid",

"status": "published", "published_at": "2026-05-14T09:12:00Z"}]}

# localized fields, one auth scheme, one contract

One API across content, commerce, customers, and search

The surface is the whole platform. Content and custom data with channels and custom fields, no migrations when you add a field. Commerce with variants, pricing schemes, and a 13-state order machine. Customers with groups, B2B access, and encrypted fields at rest with EU-held keys. Language-aware search across roughly 40 locales.

No second-class surface What the dashboard can do, your code can do.
Add a field, it is in the API No migration, no redeploy. The contract updates the same moment.
One auth scheme for everything OAuth2/OIDC and granular scopes across content, commerce, and customers.

Full API reference

endpoints

# content + custom data

$ GET /channels/{slug}/entries

$ POST /channels/{slug}/entries

# commerce

$ POST /products

$ GET /orders?status=paid

# customers + auth

$ POST /customers

# multilingual search

$ GET /search?q=linen&lang=fr

Auth and contract

OAuth2 and OIDC, with scopes you control

Authentication is OAuth2 with OpenID Connect, the standard your stack already speaks. Scopes are per resource, for read and write. An integration that reads orders gets a read-only orders scope and nothing more. A leaked token from one integration is not a key to the whole account.

The contract is versioned. An upgrade is a decision you make on your schedule, not a Tuesday-morning surprise that breaks a client site in production.

Granular read/write scopes Narrow integrations and agents to exactly the surface they need.
Versioned contract Test and move on your schedule. Breaking changes are not surprises.
Standard OAuth2/OIDC No bespoke token scheme to reverse-engineer.

Auth reference

oauth

# exchange credentials for an access token

$ POST /oauth/token

{"access_token": "eyJ...", "token_type": "Bearer"}

# scoped per resource: read-only orders

$ GET /orders?status=paid

# OpenID Connect discovery

$ GET /.well-known/openid-configuration

# least privilege, versioned contract

The platform pushes events you would otherwise poll for

Register a webhook against the events you care about and Nimbu sends an outbound HTTP request when they fire, across both content and commerce. A record published triggers a cache purge or static rebuild. An order paid posts to fulfillment or a client ERP. A customer created syncs to a CRM. The platform is the source of truth, and your other systems react to it.

Content and commerce events entry.published, order.paid, order.fulfilled, customer.created.
No polling required Nimbu calls you. Your integration reacts in real time.
Fits into any stack Nimbu is the source of truth. Your other systems subscribe to it.

Webhook reference

webhooks

# register a webhook on order.paid

$ POST /webhooks

$ {"event": "order.paid",

$ "url": "https://erp.example.com/webhooks/nimbu"}

{"id": "wh_01", "event": "order.paid", "active": true}

# also: entry.published, customer.created,

# order.fulfilled, order.refunded

The language you already work in

You do not have to hand-roll HTTP to use the API. The tooling is polyglot and public.

JS SDK

Typed client for the REST API

Calls from a Node service or serverless function read like method calls, not URL strings. Typed, public, and maintained alongside the API.

npm install @nimbu/client

@nimbu/testing

Test before it touches production

Test integration and Cloud Code logic against in-memory fixtures before it touches a live site. No side effects in CI.

Testing reference

CLI and agent skill

35+ agents drive the same API

The nimbu CLI ships as an open agent skill for Claude Code, GitHub Copilot, and 35+ agents. JSON and TSV output, OS-keychain auth, read-only mode, and command allowlists.

Agent-native platform

Headless or templated

Same model, your delivery choice

Render server-side with Liquid themes, which are Git-based and need no build step, or pull content over the API into a static frontend. One source of truth, either way.

CMS and themes

From the field

We wired client order data straight into their ERP over the API in an afternoon. The versioned contract meant we shipped, went live, and the integration kept answering after the next platform update.

Developer, Zenjoy

The full reference is in the docs

Every endpoint, parameter, scope, and response is documented as an OpenAPI reference at docs.nimbu.io. This page is the shape of it. The docs are the detail.