Organisez les échanges entre vos systèmes
Une API permet aux applications d’échanger automatiquement des données. Recevez les commandes, vérifiez-les selon vos règles et envoyez les résultats aux autres systèmes. Vous choisissez les données, le format de réponse et les règles d’accès.
Recevoir · préparer · publier
Un parcours maîtrisé pour recevoir, valider, transformer et livrer
Vos propres adresses avec les champs, paramètres et données à jour attendus
Documentation générée, réponses utiles et accès configurable par consommateur
Montrez l’erreur à l’émetteur. Avant l’écriture.
Définissez un schéma, les valeurs obligatoires et une clé unique. La politique d’erreur choisie détermine le traitement d’une requête invalide.
/api/v1/inbound/orders[
{
"orderId": "ORD-1042",
"amount": "abc",
"orderDate": "2026-10-28"
}
]Un champ doit être corrigé
Dans la première ligne, amount contient du texte au lieu d’un nombre. Le mode de réponse détaillée précise le champ, la ligne et la raison.
code: API_INBOUND_INVALIDSelon cette politique, la requête invalide ne lance pas le flux.Une documentation conforme à votre configuration.
Méthodes, champs, règles d’accès, exemples et réponses : une seule référence pour l’intégrateur.
Recevez les données d’autres systèmes
Commandes du portail, stocks des agences et fichiers des partenaires peuvent entrer directement dans un flux convenu. Créez une connexion API REST avec la direction « Recevoir des données dans Data Bridge », définissez sa version et son adresse, puis ajoutez un bloc d’entrée API. Après publication, chaque livraison acceptée lance le flux Production. Le corps des requêtes accepte JSON, JSON Lines, CSV/TSV et XML ; le mode fichiers lit Excel XLSX/XLSM, CSV, TXT délimité, JSON et XML. Configurez le chemin des enregistrements, la feuille, la plage ou le séparateur. Les partenaires gardent leurs formats habituels ; votre équipe maîtrise le traitement.
- Recevoir un tableau dans le corps de requête ou des fichiers par multipart/form-data
- Réunir les lignes des fichiers d’une requête dans un tableau de traitement
- Versionner l’adresse et exécuter la logique publiée du flux
Contrôlez les données dès leur arrivée
Fournissez des données d’exemple pour générer les champs et suggérer leurs types. Vérifiez les champs texte, entier, décimal, date, date-heure et booléen ; marquez les valeurs obligatoires et les clés uniques simples ou composées. Par exemple, le numéro de commande associé au numéro de ligne ne doit pas se répéter dans une livraison. Ce contrôle vérifie la conformité sans modifier automatiquement les valeurs. Le Mappage des colonnes définit ensuite noms, sélection et ordre ; les jointures de référence enrichissent les fiches ; le Nettoyage et contrôle applique des règles ordonnées. Un montant vide peut devenir un zéro numérique, tandis qu’un montant négatif peut arrêter le traitement avec DATA_QUALITY. Normalisation, rejet de ligne et arrêt sont des décisions explicites adaptées à votre processus.
- Contrôles d’entrée : formats, valeurs obligatoires et clés répétées dans une requête
- Mappage, référentiels, formules et contrôles de qualité avant écriture
- Aperçu et simulation avec des exemples jamais substitués aux livraisons de production
Définissez le contrat métier
Identifiez émetteurs, consommateurs, champs requis, critères de réussite et besoin d’actualité.
Construisez et testez le flux
Configurez le schéma, le mappage et les contrôles. Simulez des exemples valides et invalides.
Accordez les accès adaptés
Attribuez les droits, limites et clé du client, ou activez délibérément la publication publique.
Publiez et connectez le consommateur
Donnez accès à la documentation, vérifiez Production, testez la livraison ou la lecture et surveillez l’audit.
Expliquez ce qu’il faut corriger
Des valeurs d’entrée invalides peuvent renvoyer HTTP 422 API_INBOUND_INVALID avec ligne, colonne, champ, valeur, type d’erreur et raison ; les détails de clés répétées identifient les champs et la ligne d’origine. Choisissez le rejet complet détaillé, un résumé ou l’acceptation des seules lignes valides. Les réponses listent jusqu’à 100 erreurs et les totaux. Le mode asynchrone HTTP 202 fournit un identifiant de livraison et Location pour le suivi. Le mode avec attente renvoie le résultat terminé ou 202 après expiration du délai. Examinez run.status, run.code, run.message et les nombres d’écritures : HTTP 200 et delivery.completed seuls ne garantissent pas la réussite du flux. L’impossibilité de créer une exécution diffère d’un échec de règle métier pendant celle-ci.
- Colonnes manquantes : API_INBOUND_FIELDS ; valeurs invalides : API_INBOUND_INVALID
- Les erreurs du flux comme DATA_QUALITY figurent dans run.code et run.message
- Les rappels signés signalent la fin de livraison ; vérifiez séparément le résultat d’exécution inclus
Lisez et envoyez des données par API
Data Bridge peut appeler un service externe ou lui envoyer le résultat d’un flux. Lisez les commandes d’un outil commercial, enrichissez-les avec les codes de gestion et livrez un lot cohérent à la finance. La lecture accepte GET ou POST, l’analyse des réponses et la pagination par liens suivants, en-têtes Link, numéros de page ou décalages. L’envoi accepte POST, PUT ou PATCH, par ligne ou par lots. Choisissez JSON, XML, les données de formulaire ou CSV selon le contrat du destinataire. L’authentification utilise les identifiants du service : Basic, Bearer, clé API en en-tête ou identifiants client OAuth 2.0. Un service ouvert est accessible sans authentification.
- Configurer chemins, paramètres, en-têtes, format et lots pour le destinataire
- Définir la structure sortante sans réorganiser manuellement les champs
- Atteindre les API internes approuvées via un UBC Agent configuré
Recevoir · préparer · publier
Partagez les données utiles à chaque application
Un portail veut les stocks par entrepôt, une application les taux de change datés et un partenaire l’assortiment disponible. Réunissez les sources, appliquez les règles et reliez le résultat à Publication de données API. Les consommateurs reçoivent les champs convenus en JSON, JSON Lines, CSV ou XML. Configurez les paramètres texte, numériques ou de date : valeurs individuelles, listes, plages, limites autorisées et entrées obligatoires. L’adresse peut servir des résultats enregistrés avec contrôle d’ancienneté ou exécuter le flux à la demande. Les calculs longs renvoient 202 API_RUN_PENDING et une adresse next pour poursuivre l’attente de la même exécution. Les résultats terminés peuvent être réutilisés pendant une durée définie.
- Filtrer les lignes préparées ou alimenter les paramètres d’exécution
- Lire des pages cohérentes ; utiliser ETag et 304 pour des données inchangées
- Échec à la demande : 502 API_RUN_FAILED ; données enregistrées trop anciennes : API_DATA_STALE
Donnez aux développeurs une référence prête à l’emploi
La documentation HTML technique est générée depuis les paramètres enregistrés du point d’accès, la configuration des blocs et les données d’exemple. Elle décrit l’adresse complète, le format, les champs, valeurs obligatoires, clés uniques, paramètres, réponses, erreurs et limites effectives. Les instructions de démarrage et les exemples curl, Postman et Python aident à reproduire la première requête ; les exemples HMAC apparaissent lorsqu’ils s’appliquent. Enregistrez les changements et rouvrez la page pour actualiser le contrat. Vérifiez son état par rapport à Production : un brouillon enregistré n’est pas un changement publié. L’accès nécessite un éditeur du flux ou un utilisateur disposant du droit documentaire approprié et de la visibilité du flux. Les secrets clients ne sont jamais inclus.
- Exemples conformes au format réel et au mode de publication
- Connexion à Data Bridge requise ; une clé API seule n’ouvre pas la documentation HTML
- Une publication de données publique ne rend pas sa documentation publique
Recevoir · préparer · publier
Configurez plusieurs niveaux de protection
Pour les adresses protégées, attribuez une clé API distincte à chaque intégration et utilisez HTTPS. Envoyez les clés dans Authorization: Bearer ou X-API-Key, jamais dans les URL. Une clé appartient à un utilisateur : ses droits Lecture et Écriture sur les flux choisis ne peuvent pas dépasser les droits actuels de ce propriétaire. Configurez l’expiration, les adresses IPv4/IPv6 ou réseaux CIDR autorisés, les limites de requêtes et HMAC-SHA256, activé par défaut. La signature couvre l’heure, la méthode, le chemin avec les paramètres et l’empreinte du corps. L’écart d’horloge est limité à cinq minutes et le rejeu de signature est refusé. La rotation remplace la clé ; désactiver le client arrête l’accès. Adaptez les contrôles à chaque partenaire.
- 401 signale un problème de clé, expiration ou signature ; 403 concerne adresse, état utilisateur ou droits
- Les limites du client et de l’espace renvoient 429 avec Retry-After
- Une IP est temporairement bloquée après 30 échecs d’authentification en 15 minutes
Pour les points d’accès API protégés
Choisissez un accès privé ou public
Protégez les indicateurs internes, stocks par partenaire et résultats personnels par des clés et autorisations. Pour un référentiel ouvert, un catalogue public ou un widget d’information, activez le paramètre distinct de publication publique. Après confirmation explicite, toute personne disposant de l’adresse peut lire sans clé, signature ni vérification des droits du flux. CORS autorise les requêtes d’autres sites ; un widget public n’a donc pas besoin de secret. Les limites par IP et globales, la pagination, les contrôles d’ancienneté configurés et l’audit restent en place. Seule cette adresse devient publique : requêtes entrantes, historique, autres résultats et documentation gardent leurs contrôles. Choisissez délibérément les champs avant ouverture.
- Protéger les échanges métier convenus avec des clés clients gérées
- Utiliser des adresses publiques pour des données librement accessibles
- Alimenter un widget avec des résultats enregistrés actualisés à heure fixe
Recevoir · préparer · publier
Retrouvez la cause d’une erreur dans l’historique
Idempotency-Key empêche une autre exécution lors de la répétition d’une livraison ; un corps modifié avec la même clé produit un conflit. Chaque requête HTTP répétée nécessite une nouvelle signature HMAC. Les écritures sortantes ne sont pas relancées automatiquement si le service a pu déjà agir : une réponse perdue nécessite un rapprochement dans la destination. Configurez la taille, les files, la fréquence, les délais et les reprises de rappels. L’audit API permet de rapprocher adresses, clients, heures, états et exécutions. La conservation des corps est distincte : après effacement des données de livraison, une copie d’audit peut subsister selon ses paramètres.
- Éviter les exécutions de livraison en double sans promettre une transaction entre systèmes externes
- Tester réussite, champs invalides, clés répétées et limites avant déploiement
- Prévoir une nouvelle version d’adresse pour migrer vers un contrat modifié
Les réponses à vos questions.
Comment connecter vos données, gérer les accès et démarrer.
Faut-il programmer un serveur API distinct ?
Configurez les adresses et blocs de traitement dans Data Bridge. Les applications externes envoient des requêtes HTTP selon le contrat convenu.
La validation de type corrige-t-elle les valeurs automatiquement ?
Non. Le schéma d’entrée valide ; des blocs distincts transforment. Les clés uniques détectent les doublons dans une requête, pas dans l’historique des livraisons.
HTTP 202 signifie-t-il que les données sont écrites ?
Non. Vérifiez run.status et le résultat en destination après la fin. delivery.completed indique une fin, pas nécessairement une réussite.
Quelle différence entre HMAC et Idempotency-Key ?
HMAC valide les requêtes individuelles et refuse le rejeu de signature. Idempotency-Key relie les livraisons répétées à la première exécution. Les nouvelles tentatives nécessitent de nouvelles signatures.
Peut-on lire les données sans clé ?
Oui, par une publication publique explicitement activée. Toute personne ayant l’adresse peut lire les données ; la documentation et les autres routes API restent protégées.
Chaque lecture interroge-t-elle à nouveau les sources ?
Non. Choisissez des résultats enregistrés avec contrôle d’ancienneté ou l’exécution à la demande, avec attente et réutilisation configurables.
Commençons par votre besoin.
Indiquez quelles données vous souhaitez relier. Nous expliquerons le fonctionnement et montrerons un exemple.
Présentez votre besoin. Trouvons la suite.
Sources, règles et résultats : parlons de votre processus.