1. Créer le point d’entrée
Ouvrez « Connexions → REST API » et choisissez « Recevoir des données dans Data Bridge ». Définissez un nom, une version API v1 et un identifiant tel que orders. Les identifiants comprennent 3 à 64 lettres latines minuscules, chiffres ou tirets et doivent être uniques parmi les points de cette version dans votre section.
Choisissez « Dès l’acceptation » ou « Après traitement par le flux ». Pour ce dernier mode, fixez le délai d’attente : une exécution plus longue renvoie toujours 202. Rendez Idempotency-Key obligatoire pour éviter les soumissions de commandes en double. Ne redéfinissez que les paramètres nécessaires dans « Limites API » ; sans cocher la redéfinition, les valeurs globales actuelles s’appliquent.
2. Définir les données dans le bloc
Ajoutez « Données entrantes API » avec ce point. Pour des tables, choisissez « Recevoir des données » et JSON, JSON Lines, CSV/TSV, XML ou la détection à partir de Content-Type. JSON prend en charge un tableau d’objets et un chemin tel que data.items; les objets imbriqués deviennent des champs a.b .
Fournissez un petit jeu de test et sélectionnez son propre format. Cliquez sur « Actualiser les champs », vérifiez les types proposés et indiquez les valeurs obligatoires. Une commande peut nécessiter orderId, une valeur numérique amount et une date dans orderDate. Ajoutez une clé unique orderId ou la combinaison de champs nécessaire. Les contrôles de format valident les valeurs sans les convertir : effectuez la normalisation dans des blocs distincts.
La référence du bloc « Données entrantes API » décrit toutes les propriétés, le comportement sans livraison et les règles des données simulées.
3. Lorsque la requête contient des fichiers
En mode « Recevoir des fichiers », configurez les extensions autorisées, le nombre de fichiers et les règles de lecture. Les formats pris en charge comprennent Excel XLSX/XLSM, CSV, TXT délimité, JSON et XML. Pour Excel, choisissez la feuille et la plage ; pour CSV, le séparateur et l’en-tête ; pour un fichier JSON, JSON Pointer. Les lignes de tous les fichiers d’une requête forment une table combinée ; vous pouvez ajouter une colonne contenant le nom du fichier.
Envoyez les fichiers en multipart/form-data, ou un seul fichier dans le corps de requête avec son nom dans X-File-Name ou Content-Disposition. Pour HMAC, signez les octets du corps réellement transmis. Les données de test servent aux aperçus et à la simulation et ne remplacent jamais les données d’une requête opérationnelle.
4. Publier et soumettre une requête
Reliez la source aux contrôles et à une destination, simulez puis publiez Production. Accordez au client API le droit « Écriture » sur ce flux ; son propriétaire doit être autorisé à l’exécuter. Copiez l’URL complète depuis le formulaire. La structure de requête ci-dessous montre où remplacer API_KEY, l’horodatage et la signature selon la règle de signature HMAC.
POST /api/v1/inbound/orders?p.Period=2026-10 HTTP/1.1
Host: databridge.example.com
Authorization: Bearer API_KEY
Content-Type: application/json
Idempotency-Key: orders-2026-10-28-batch-001
X-UBC-Timestamp: UNIX_SECONDS
X-UBC-Signature: v1=HMAC_HEX
[{"orderId":"ORD-1042","amount":1250,"orderDate":"2026-10-28"}]Utilisez p.Period uniquement si le flux définit ce paramètre. Si plusieurs flux accessibles utilisent ce point, indiquez flow=identifier. Les paramètres inconnus sont refusés.
5. Suivre la livraison et les nouvelles tentatives
Conservez l’identifiant de livraison et Location. Interrogez GET /api/v1/deliveries/{id} avec le même client ; utilisez le lien renvoyé ou GET /api/v1/runs/{run_id} pour les détails de l’exécution. 202 signifie une acceptation, pas une écriture terminée. HTTP 200 et l’état de livraison completed ne garantissent pas non plus la réussite métier : l’exécution peut s’être terminée avec l’état failed, partial, uncertain ou cancelled. Vérifiez run.status, run.code, run.message et run.written, puis rapprochez les données cibles. L’état de livraison failed indique un échec avant la création d’une exécution ; la cause se trouve dans error, et le POST initial renvoie HTTP 409. Un GET distinct de la livraison ou une répétition idempotente peut renvoyer HTTP 200 pour différents états courants : examinez donc toujours le corps de réponse.
Répéter un corps identique avec la même clé d’idempotence renvoie la livraison initiale et Idempotent-Replayed: true. Des données différentes ou un autre flux avec cette clé produisent 409 IDEMPOTENCY_CONFLICT. Lorsque la signature est activée pour le client, calculez un nouveau HMAC pour une requête HTTP répétée : une même signature ne peut pas être réutilisée. L’idempotence de livraison n’est pas une transaction globale entre écritures externes.
6. Rappel et diagnostic
Vous pouvez configurer une adresse de rappel, ou callback, et un secret distinct d’au moins 32 caractères. Data Bridge envoie un POST avec le JSON de livraison, X-UBC-Delivery, l’événement delivery.completed ou delivery.failed, l’horodatage et le HMAC. Validez l’horodatage et comparez les signatures en temps constant ; traitez les événements répétés à partir de l’identifiant de livraison. L’événement delivery.completed signifie que l’exécution s’est terminée ; déterminez son résultat à partir de run.status, du code, du message et du nombre d’écritures. L’absence de réponse ou une réponse non 2xx déclenche les nouvelles tentatives configurées avec des délais doublés ; les redirections ne sont pas suivies.
Testez volontairement un type invalide et un doublon de clé unique : 422 API_INBOUND_INVALID fournit les raisons dans errors. Une colonne manquante peut produire API_INBOUND_FIELDS; un corps trop volumineux, 413; une file pleine, 429 API_INBOUND_QUEUE_FULL. Les données de livraison sont supprimées après la fin, tandis que l’état et les enregistrements d’audit distincts ont leur propre cycle de vie. Consultez la référence du point de terminaison et le journal des requêtes.