À retenir
- Envoyez un document en X12 brut ou en JSON à un seul point d’accès. Le JSON est converti en X12 avec les séparateurs de votre partenaire et, dans les deux cas, le document est vérifié selon son guide.
- Les erreurs de validation reviennent sous forme de données structurées dans une réponse
422, avant tout envoi. - Les documents reçus peuvent être transmis à votre URL par webhook, en JSON ou en XML, remodelés par un schéma au besoin.
Pourquoi l’EDI brut est difficile à programmer
Un fichier X12 identifie les données par leur position, pas par un nom : le numéro de bon de commande est simplement le troisième élément de BEG. Chaque partenaire ajoute ensuite ses propres règles à la norme, documentées dans un PDF. Écrire et valider tout cela à la main, pour chaque partenaire, c’est là que les projets d’intégration piétinent. (Le X12 vous est nouveau ? Lisez le format X12 expliqué.)
L’API en un coup d’œil
| Point d’accès | À quoi il sert | Portée |
|---|---|---|
GET /me | Identifie votre compte et les portées de la clé | — |
POST /documents | Envoie un document sortant, en X12 ou en JSON | write:documents |
GET /deliveries | Liste les documents envoyés et reçus, avec leur état | read:deliveries |
GET /partners | Liste vos partenaires commerciaux | read:partners |
GET /guides | Liste les guides selon lesquels vos documents sont vérifiés | read:guides |
Les appels s’authentifient avec une clé d’API dans un en-tête Authorization: Bearer, et chaque clé ne porte que les portées que vous lui donnez. Les clés sont limitées à 600 requêtes par minute.
curl "https://app.weredi.io/api/v1/deliveries?status=failed&direction=outbound" \ -H "Authorization: Bearer $WEREDI_API_KEY"
Envoyer un document
POST /documents accepte un document X12 brut ou sa représentation JSON. Le JSON est converti en X12 avec les séparateurs du guide de votre partenaire, et le résultat est vérifié selon ce guide avant d’aller où que ce soit.
- Les erreurs bloquent l’envoi. La réponse est un
422 validation_failedavec chaque anomalie, que votre code peut afficher ou corriger. - Les avertissements, non. Le document part, et les avertissements reviennent avec la réponse.
- Vous gardez la main. Un indicateur permet de passer outre la validation quand votre partenaire demande une chose que son guide ne dit pas.
Recevoir des documents par webhook
Pour les documents entrants, créez une automatisation avec une action webhook : à l’arrivée d’un document, filtré par type et par partenaire si vous le voulez, Weredi le transmet à votre URL en JSON, en XML ou en champs de formulaire. Un schéma peut lui donner exactement la forme qu’attend votre application. La requête et la réponse de chaque appel sont conservées avec le document : un échec de livraison vers votre point d’accès s’analyse facilement.
Quel forfait ?
L’API REST et les webhooks font partie de Weredi Plus et Entreprise, et sont actifs pendant l’essai gratuit de 14 jours.
Questions
Weredi a-t-elle une API EDI ?
Oui. L’API REST de Weredi permet d’envoyer des documents, de lister les envois avec leur état et de lire vos partenaires et guides, avec des clés d’API à portée limitée.
Puis-je envoyer du JSON au lieu du X12 ?
Oui. POST /documents accepte une représentation JSON du document et la convertit en X12 avec les séparateurs de votre partenaire ; vous pouvez aussi envoyer du X12 brut.
L’API valide-t-elle les documents avant l’envoi ?
Oui. Chaque document est vérifié selon le guide du partenaire ; les erreurs renvoient une réponse 422 détaillée et rien n’est envoyé, alors que les avertissements ne bloquent pas.
Comment recevoir les documents EDI entrants dans mon application ?
Avec une automatisation munie d’une action webhook : Weredi transmet chaque document entrant à votre URL en JSON, en XML ou en champs de formulaire, remodelé par un schéma au besoin.