Vue d'ensemble
L'API de la plateforme Inklura expose les domaines métier de la plateforme (produits,
commandes, clients, factures, campagnes et bien d'autres) sur une seule surface : tRPC.
Chaque procédure est accessible à l'adresse /api/trpc/<router>.<procedure>.
URL de base
https://manage.inklura.fr
Tous les exemples de cette page utilisent cet hôte. Voir Environnements pour les autres applications de la plateforme.
Format des requêtes et des réponses
tRPC est monté sur /api/trpc et accepte GET comme POST. La sérialisation utilise
superjson : les entrées sont encapsulées sous la forme {"json": <value>}, et la réponse
se trouve sous result.data.json.
| Type de procédure | Verbe HTTP | Entrée |
|---|---|---|
| Query | GET |
?input={"json":<value>} (encodé dans l'URL) |
| Mutation | POST |
corps de requête {"json":<value>} |
Query (GET)
Une query passe son entrée dans l'URL. Ici, auth.getSession ne prend pas d'entrée, donc
?input= est omis :
curl "https://manage.inklura.fr/api/trpc/auth.getSession" \
-H "Authorization: Bearer $INKLURA_TOKEN"
Une query qui prend une entrée encode une enveloppe superjson dans ?input= :
curl -G "https://manage.inklura.fr/api/trpc/products.getById" \
-H "Authorization: Bearer $INKLURA_TOKEN" \
--data-urlencode 'input={"json":{"id":"<product-id>"}}'
La réponse place le résultat sous result.data.json :
{
"result": {
"data": {
"json": { "id": "<product-id>", "name": "…" }
}
}
}
Quand le résultat contient des valeurs que JSON ne représente pas directement (des dates, par
exemple), superjson ajoute un objet meta à côté de json. Un client superjson le décode pour
vous.
Mutation (POST)
Une mutation envoie son entrée dans le corps JSON, là encore encapsulée dans
{"json":<value>} :
curl -X POST "https://manage.inklura.fr/api/trpc/clients.create" \
-H "Authorization: Bearer $INKLURA_TOKEN" \
-H "Content-Type: application/json" \
-d '{"json":{"name":"Acme SARL","email":"contact@acme.example"}}'
La réponse a la même forme result.data.json. Voir Procédures tRPC
pour un exemple avec @trpc/client et l'ensemble des conventions d'appel.
Batching
L'endpoint accepte le protocole de batch standard de tRPC : un client configuré avec
httpBatchLink peut regrouper plusieurs appels en une seule requête HTTP. Les queries peuvent
aussi être envoyées en POST (le remplacement de méthode est activé). Voir
Procédures tRPC.
Portée locataire (tenancy)
Inklura est multi-locataire. Chaque appel s'exécute dans un locataire et un site :
- Votre token nomme le locataire et le site d'origine de votre
compte ; la portée est résolue à chaque requête. C'est ce qui fait de
manage.inklura.frun endpoint unique pour tous les locataires. - Avant chaque appel à une procédure protégée, la plateforme vérifie la portée au regard des
accès de votre compte (son locataire d'origine, ses appartenances ou l'administration de la
plateforme). Une portée à laquelle vous n'avez pas accès est refusée avec
FORBIDDEN.
Les données d'un locataire portent un tenantId, et l'API filtre les appels sur la portée
résolue. Voir le Modèle de données.
Pour aller plus loin
| Page | Contenu |
|---|---|
| Sessions et tokens | Ordre de résolution des identifiants, portée locataire/site |
| Procédures tRPC | Niveaux d'accès, conventions d'appel, catalogue des routers |
| Endpoints REST | Pourquoi l'API est uniquement tRPC, et les autres routes HTTP |
| Modèle de données | Multi-tenancy et entités principales |
| Erreurs et limites de débit | Enveloppe d'erreur, codes et limites par fonctionnalité |
| Pagination et filtrage | Comment les procédures de liste paginent |