API REST

Chaque capacité,
exposée comme une API.

Le tableau de bord n'est pas le produit. L'API l'est. Chaque action dans l'interface de Nimbu est un appel à la même API REST que votre code peut effectuer. Si la plateforme peut le faire, vous pouvez le piloter depuis votre code.

Explorer la documentation Réserver une démo

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

Lisez-le sans vous connecter

Une requête et ce qui revient. Aucun SDK n'est nécessaire pour comprendre la structure, juste un appel HTTP vers la même API que celle utilisée par le tableau de bord.

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

Une seule API pour le contenu, le commerce, les clients et la recherche

La surface, c'est toute la plateforme. Contenu et données personnalisées avec les channels et les custom fields, sans migration quand vous ajoutez un champ. Commerce avec variantes, schémas de prix et une machine de commandes à 13 états. Clients avec groupes, accès B2B et champs chiffrés au repos avec des clés conservées dans l'UE. Recherche adaptée à la langue sur une quarantaine de locales.

Aucune surface de second rang Ce que le tableau de bord peut faire, votre code peut le faire.
Ajoutez un champ, il est dans l'API Aucune migration, aucun redéploiement. Le contrat se met à jour au même instant.
Un seul schéma d'authentification pour tout OAuth2/OIDC et scopes granulaires sur le contenu, le commerce et les clients.

Référence complète de l'API

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

Authentification et contrat

OAuth2 et OIDC, avec des scopes que vous contrôlez

L'authentification se fait en OAuth2 avec OpenID Connect, le standard que votre stack parle déjà. Les scopes sont définis par ressource, en lecture et en écriture. Une intégration qui lit des commandes reçoit un scope commandes en lecture seule et rien de plus. Un jeton fuité depuis une intégration n'est pas une clé vers tout le compte.

Le contrat est versionné. Une mise à niveau est une décision que vous prenez selon votre calendrier, pas une surprise du mardi matin qui casse un site client en production.

Scopes granulaires en lecture et écriture Limitez les intégrations et les agents exactement à la surface dont ils ont besoin.
Contrat versionné Testez et avancez selon votre calendrier. Les changements incompatibles ne sont pas des surprises.
OAuth2/OIDC standard Aucun schéma de jeton maison à décortiquer.

Référence sur l'authentification

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

La plateforme pousse les événements que vous interrogeriez sinon en boucle

Enregistrez un webhook sur les événements qui vous intéressent et Nimbu envoie une requête HTTP sortante quand ils se déclenchent, aussi bien pour le contenu que pour le commerce. Un enregistrement publié déclenche une purge de cache ou une reconstruction statique. Une commande payée est envoyée à la logistique ou à l'ERP d'un client. Un client créé se synchronise vers un CRM. La plateforme est la source de vérité et vos autres systèmes y réagissent.

Événements de contenu et de commerce entry.published, order.paid, order.fulfilled, customer.created.
Aucun polling requis C'est Nimbu qui vous appelle. Votre intégration réagit en temps réel.
S'intègre dans n'importe quelle stack Nimbu est la source de vérité. Vos autres systèmes s'y abonnent.

Référence sur les webhooks

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

Le langage dans lequel vous travaillez déjà

Vous n'avez pas besoin d'écrire du HTTP à la main pour utiliser l'API. L'outillage est polyglotte et public.

SDK JS

Client typé pour l'API REST

Les appels depuis un service Node ou une fonction serverless se lisent comme des appels de méthode, pas comme des chaînes d'URL. Typés, publics et maintenus en parallèle de l'API.

npm install @nimbu/client

@nimbu/testing

Testez avant que cela touche la production

Testez la logique d'intégration et de Cloud Code contre des fixtures en mémoire avant qu'elle ne touche un site en ligne. Aucun effet de bord dans la CI.

Référence sur les tests

CLI et skill d'agent

Plus de 35 agents pilotent la même API

Le CLI nimbu est livré comme skill d'agent ouvert pour Claude Code, GitHub Copilot et plus de 35 agents. Sortie JSON et TSV, authentification via le trousseau du système, mode read-only et listes de commandes autorisées.

Plateforme agent-native

Headless ou basé sur des templates

Même modèle, votre choix de diffusion

Faites le rendu côté serveur avec des themes Liquid, basés sur Git et sans étape de build, ou récupérez le contenu via l'API dans un frontend statique. Une seule source de vérité, dans les deux cas.

CMS et themes

Du terrain

Nous avons branché les données de commandes d'un client directement dans leur ERP via l'API en un après-midi. Grâce au contrat versionné, nous avons livré, mis en ligne, et l'intégration a continué de répondre après la mise à jour suivante de la plateforme.

Développeur, Zenjoy

La référence complète se trouve dans la documentation

Chaque endpoint, paramètre, scope et réponse est documenté sous forme de référence OpenAPI sur docs.nimbu.io. Cette page en donne la forme. La documentation en donne le détail.