/ docs
ProduitConnaissancesDéveloppeurs
Plateforme Control
API SOAP : envoyer des factures avec SendDocument

Envoyer des factures et documents via l'endpoint SOAP SendDocument : paramètres, routage et suivi de statut.

Avec l'endpoint SendDocument de l'API SOAP legacy, vous envoyez des factures et d'autres documents via la plateforme eConnect. La plateforme détermine automatiquement le meilleur itinéraire : via la plateforme eConnect elle-même, via Peppol, ou par e-mail en solution de repli.

Important : Ceci est l'API SOAP legacy. Pour les nouvelles intégrations, nous recommandons l'API REST.

Fonctionnement de SendDocument

Lors de l'appel à SendDocument, vous transmettez le document source ainsi que les données de l'expéditeur et du destinataire. La plateforme recherche ensuite le destinataire en trois étapes :

  1. Plateforme eConnect : le destinataire est-il également utilisateur de la plateforme ? Dans ce cas, le document est directement livré dans sa boîte de réception.
  2. Peppol : le destinataire est-il joignable sur le réseau Peppol ? Dans ce cas, le document est routé via Peppol.
  3. E-mail (repli) : si aucune des deux options n'est possible et qu'une adresse e-mail a été fournie, le document est envoyé par e-mail.
Paramètres obligatoires
ParamètreDescriptionVia/ReferenceIdIdentification de l'expéditeur (votre propre EConnectPartyId, numéro XCNL)To/ReferenceIdIdentification du destinataire (EConnectPartyId ou identifiant Peppol tel que 0106:numéro-KVK)To/EmailAddressAdresse e-mail du destinataire (utilisée en repli lorsque le routage via la plateforme et Peppol n'est pas possible)SubjectObjet du documentPayloadLe document lui-même, en UBL-XML. Attention : envoyez le XML sans prologue XML (<?xml ...?>)TemplateIdL'identifiant du template indiquant le type de document
Exemple d'appel
<SendDocument>
  <Document>
    <Via>
      <ReferenceId>XCNL-123456</ReferenceId>
    </Via>
    <To>
      <ReferenceId>0106:12345678</ReferenceId>
      <EmailAddress>facturatie@voorbeeld.nl</EmailAddress>
    </To>
    <Subject>Factuur 2026-001</Subject>
    <Payload><!-- UBL-XML zonder prolog --></Payload>
    <TemplateId>GLDT9223370666504283001RA000000006DTP2000001</TemplateId>
  </Document>
</SendDocument>

Le TemplateId GLDT9223370666504283001RA000000006DTP2000001 est le MasterTemplateId pour une facture standard. Utilisez toujours le MasterTemplateId (et non un code de version), car celui-ci reste stable d'une version de template à l'autre.

Response et ExternalId

Après un appel réussi, l'API retourne un ExternalId. Il s'agit de l'identifiant unique du document envoyé dans la plateforme eConnect. Si la response ne contient pas d'ExternalId, le document n'a pas été envoyé. Vérifiez dans ce cas le message d'erreur dans la response.

Conservez toujours l'ExternalId : vous en aurez besoin pour consulter ultérieurement le statut du document.

DeliveryMethod

L'API retourne également la DeliveryMethod dans la response, afin que vous sachiez par quel canal le document a été livré :

ValeurSignificationToInboxLivré dans la boîte de réception du destinataire sur la plateforme eConnectToPeppolEnvoyé via le réseau PeppolToEmailEnvoyé par e-mailOutboxOnlyUniquement enregistré dans votre propre outbox (non livré)NoneAucune livraison possible
Suivi du statut

Après l'envoi, vous pouvez suivre le statut de votre document avec deux endpoints :

EndpointFonctionGetOutboxDocumentsRécupérer la liste des documents envoyés. Filtrez sur ModifiedOn pour ne voir que les documents récemment modifiés.GetOutboxDocumentConsulter un document spécifique à partir de l'ExternalId.GetOutboxDocumentStatusConsulter uniquement le statut, sans le document complet.
Conseils

UBL-XML sans prologue : le Payload doit contenir du XML UBL sans la déclaration <?xml version="1.0" encoding="UTF-8"?>. Si vous incluez le prologue, le document risque de ne pas être traité correctement.

Utilisez le MasterTemplateId : filtrez toujours sur Template/MasterId plutôt que sur un template-ID spécifique. Le MasterTemplateId ne change pas lors des mises à jour de version du template.

Gestion des erreurs : vérifiez la response pour les codes d'erreur. Les séries de codes d'erreur 400 (validation) et 200 (fonctionnel) sont les plus fréquentes lors d'erreurs d'envoi. Consultez la page d'authentification pour l'aperçu complet des séries de codes d'erreur.

L'API REST offre des fonctionnalités supplémentaires pour l'envoi, comme les webhooks pour les notifications de statut et la relance automatique en cas d'erreur. Consultez psb.econnect.eu pour l'approche moderne.

Migrer vers l'API REST

En relation
PreviousAuthentification SOAP
NextRéception SOAP