API & MCP Z-Commerce
pour développeurs et partenaires
Z-Commerce expose 70+ endpoints REST, un MCP server, et un cahier des charges clair pour brancher un nouveau fournisseur (catalog, orders, tracking, finance) en quelques heures de dev. Tout est typé, versionné, testable en demo_mode.
01Quick start
Trois étapes pour passer ton premier appel API.
Récupère un JWT
Authentifie-toi via POST /auth/login avec ton email/mot de passe d'admin Z-Commerce. La réponse contient accessToken (durée 24h) et refreshToken (7 jours).
Choisis ton environnement
Switch Test (Tailscale, accès interne) ou Prod dans la sidebar. Les exemples de code en dessous se mettent à jour automatiquement.
Appelle l'API avec ton JWT
Header Authorization: Bearer <token> sur toutes les routes sauf /auth/* et /orders/webhook/shopify.
02Environnements
🟢 Production
Données réelles. Attention : un send_order ici envoie une commande réelle au supplier.
🧪 Test (Tailscale)
Même code, même BD, mais accessible uniquement via Tailscale. Utilise demo_mode: "1" sur les requêtes supplier.
📚 Swagger UI
Documentation OpenAPI interactive. Essaie chaque endpoint depuis le navigateur.
📊 Mega Dashboard
Interface admin agrégée (overview, suppliers, commandes Shopify/Stockly, santé connecteurs).
03Authentification
JWT Bearer. Pas d'OAuth, pas d'API key statique — chaque utilisateur a un token court-vivant et un refresh token.
Login
curl -X POST "http://zc1.tail077eb3.ts.net:4002/api/v1/auth/login" \ -H "Content-Type: application/json" \ -d '{"email":"zoomici@gmail.com","password":"<motdepasse>"}'
Réponse
{
"accessToken": "eyJhbGciOiJIUzI1NiIs...", // JWT - durée 24h
"refreshToken": "eyJhbGc...", // 7 jours
"user": { "id": "...", "email": "...", "role": "SUPER_ADMIN" }
}
Rôles
SUPER_ADMIN— accès complet, gère tous les suppliers et usersADMIN— accès complet sans gestion des SUPER_ADMINSUPPLIER_ADMIN— limité à sonsupplierIdSELLER_ADMIN— pour les sellers ZCOMMERCE marketplaceVIEWER— lecture seule
localStorage.zc.jwt.04Endpoints principaux
70 endpoints au total. Voici les plus utilisés (le reste est dans le Swagger interactif).
Suppliers
Orders
?source=shopify|stockly, ?supplierId=Dashboard
05Exemples de code
Exemple : lister les commandes Shopify en attente de routage.
curl "http://zc1.tail077eb3.ts.net:4002/api/v1/orders?status=RECEIVED&limit=50" \ -H "Authorization: Bearer $JWT"
const base = "http://zc1.tail077eb3.ts.net:4002/api/v1"; const r = await fetch(`${base}/orders?status=RECEIVED&limit=50`, { headers: { "Authorization": `Bearer ${process.env.ZC_JWT}` } }); const { data, total } = await r.json(); console.log(`${data.length}/${total} commandes`);
import os, requests base = "http://zc1.tail077eb3.ts.net:4002/api/v1" r = requests.get( f"{base}/orders", params={"status": "RECEIVED", "limit": 50}, headers={"Authorization": f"Bearer {os.environ['ZC_JWT']}"} ) data = r.json() print(f"{len(data['data'])}/{data['total']} commandes")
# Method: GET # URL: http://zc1.tail077eb3.ts.net:4002/api/v1/orders # Query: status=RECEIVED, limit=50 # Header: Authorization: Bearer {{ $credentials.zcommerceJwt.token }} # Auth: None (Authorization en header manuel)
💡 Pour la prod, créer une credential n8n custom ZCOMMERCE_JWT qui contient juste token. Les workflows COMLINE actuels (Workflow A v2) appellent /orders/webhook/shopify et héritent du routing serveur.
06Collection Postman
Collection auto-générée depuis le spec OpenAPI : 83 requêtes groupées en 12 dossiers, variables d'environnement {{API_BASE}} et {{JWT}}.
Import dans Postman
- Ouvrir Postman → Import → glisser les deux fichiers téléchargés
- Sélectionner l'environnement ZCOMMERCE - Test & Prod en haut à droite
- Coller ton JWT dans la variable
JWT(Edit Environment) - Switch
API_BASEentre{{API_BASE_TEST}}et{{API_BASE_PROD}}selon le besoin
07Webhooks
Z-Commerce reçoit des webhooks (Shopify, suppliers) et émet des webhooks sortants vers ton n8n/Zapier.
Webhooks entrants
Webhooks sortants (à configurer dans la fiche supplier)
- order.routed — quand une commande Shopify est routée vers un supplier
- order.confirmed — quand le supplier confirme la commande (send_order OK)
- order.shipped — quand un tracking est récupéré
- order.cancelled — annulation côté supplier
- connector.health.degraded — quand un connecteur passe en DEGRADED/UNHEALTHY
Payload signé HMAC-SHA256 avec le secret défini dans la fiche supplier (header X-ZC-Signature).
08Swagger interactif
Spec OpenAPI complète, essai depuis le navigateur (clique sur Authorize en haut à droite et colle ton JWT).
09MCP Z-Commerce
Le MCP server expose les tools d'administration de la plateforme dans Claude Desktop, Cursor, Continue.dev, et autres clients compatibles Model Context Protocol.
Connexion
{
"mcpServers": {
"zcommerce-suppliers": {
"command": "python",
"args": ["-m", "zcommerce_suppliers_mcp.server"],
"env": {
"ZC_API_BASE": "http://zc1.tail077eb3.ts.net:4002/api/v1",
"ZC_EMAIL": "<ton email admin>",
"ZC_PASSWORD": "<ton mot de passe>"
}
}
}
}
Tools exposés
zc_auth_login
Login + persiste le JWT pour les calls suivants
zc_list_suppliers
Liste paginée des fournisseurs
zc_create_supplier
Créer un supplier avec config commerciale
zc_update_supplier
Modifier markup, paiement, KYC, status
zc_list_suppliers_by_type
Filtre SUPPLIER vs SELLER (markup vs commission)
zc_update_supplier_status
Activer / désactiver / suspendre
+ orders, tracking, dashboard, connectors tools en cours d'ajout (chantier #4 séparé).
10Cahier des charges connecteur supplier
Ajouter un nouveau distributeur (ex: Ingram, Tech Data, Also) = implémenter ISupplierConnector + déclarer le code dans la factory. Aucune modif de l'API ni du dashboard.
Architecture (séparation tech / commercial)
Table suppliers
Données commerciales saisies dans l'UI : nom, SIRET, IBAN, markup/commission, paiement, KYC, politiques.
Table supplier_connectors
Brique de développement : connectorCode (sftp, api-rest, comline...), connectorConfig JSONB (credentials, paths, hosts), health status, lastSyncAt.
Étapes pour ajouter un connecteur
Créer le dossier src/modules/connectors/<vendor>/
3 fichiers : <vendor>.config.ts (types config + mapping), <vendor>.connector.ts (implémentation ISupplierConnector), index.ts.
Implémenter les 5 méthodes d'ISupplierConnector
testConnection(), fetchProducts(), fetchStock(skus?), fetchTracking(orderId), sendOrder(order).
Enregistrer dans SupplierConnectorCode enum + ConnectorFactory
Ajouter VENDOR = 'vendor' à l'enum, et un case 'vendor': return this.createVendorConnector(config) dans la factory.
Créer la fiche supplier via POST /suppliers + POST /supplier-connectors
L'admin remplit la fiche commerciale dans l'UI, puis le dev configure connectorConfig avec les credentials du nouveau vendor.
Tester en demo_mode + déployer
Mettre demoMode: true sur le supplier_connector pour faire des envois de test sans vraies commandes. Une fois validé, passer en demoMode: false.
Exemple : interface ISupplierConnector
export interface ISupplierConnector { testConnection(): Promise<boolean>; fetchProducts(): Promise<ProductData[]>; fetchStock(skus?: string[]): Promise<StockData[]>; fetchTracking(orderId: string): Promise<TrackingData | null>; sendOrder(order: OrderData): Promise<OrderConfirmation>; }
Connecteurs disponibles aujourd'hui
sftp— SFTP générique avec CSV/XML parsersapi-rest— API REST générique (Bearer, API key, Basic, OAuth2)comline— COMLINE GmbH (FTPS Preisliste + JSONdirect, 210k SKU, send_order, get_shipping_details)
11Pipelines n8n
9 workflows COMLINE déjà en place sur n8n.srv978465.hstgr.cloud. À répliquer pour chaque nouveau supplier.
A v2 - Shopify → ZC API
Webhook orders/paid → POST /orders/webhook/shopify. Le routing est délégué au backend.
B - Tracking poller
Schedule 15min : poll les commandes COMLINE_SENT non shipped → get_shipping_details → Shopify fulfillment.
ComLine Product Import
Schedule 6h : FTPS Preisliste → mapping par index → Shopify productSet GraphQL.
N2 - MySQL ledger
Webhook après send_order OK → INSERT supplier_orders + ledger_entries.
12Codes d'erreur
| Code | Statut | Signification |
|---|---|---|
| 401 | Unauthorized | JWT manquant, expiré ou invalide |
| 403 | Forbidden | Rôle insuffisant pour cette ressource |
| 404 | Not found | Ressource inexistante (ex: supplierId inconnu) |
| 409 | Conflict | Duplicate (ex: code supplier déjà utilisé) |
| 422 | Unprocessable | Validation DTO échouée (détails dans message[]) |
| 429 | Rate limit | Throttler global activé (voir headers Retry-After) |
| 500 | Server error | Bug serveur — vérifier les logs Docker / Sentry |
Format d'erreur standard
{
"statusCode": 422,
"message": ["email must be an email", "password too short"],
"error": "Bad Request",
"timestamp": "2026-06-07T20:30:00.000Z",
"path": "/api/v1/auth/signup",
"method": "POST",
"requestId": "abc-123"
}