La fiche du client
- Dans le bac à sable
Depuis la 0.24.0 (C14). La clé de l’opérateur ou la clé d’opérateur en lecture seule, et depuis la 0.25.0 une clé de partenaire pour un client dont la fiche nomme son partenaire (403 pour tout autre). 404 quand aucune fiche n’est définie.
apiKeyAuthorizationBearer <token>Envoyez votre clé sous forme de jeton bearer : Authorization: Bearer <your-api-key>. L’état du service est le seul appel qui ne nécessite pas de clé.
client*string^[A-Za-z0-9][A-Za-z0-9._-]{0,63}$La fiche.
application/json- response
client*stringname*stringpartner?string|nullstage*string"pilot""production""paused"contact_email?string|nulllegal_entities*array<string>countries*array<string>updated_at*stringdate-timecurl -X GET "https://example.com/clients/string/profile" \ -H "Authorization: Bearer <your-api-key>"{ "client": "string", "name": "string", "partner": "string", "stage": "pilot", "contact_email": "string", "legal_entities": [ "string" ], "countries": [ "string" ], "updated_at": "2019-08-24T14:15:22Z"}Soumettre un document UBL ou CII fini (transmission directe) POST
Pour les ERP qui écrivent déjà de l’UBL ou du CII, ou du FA(3) pour le canal KSeF. Aucun mapping n’a lieu : le service exécute les validateurs officiels du canal (pour FA(3) : le XSD plus les règles de fichier et de date de KSeF) et envoie le fichier tel quel. Un PDF Factur-X ou ZUGFeRD passe par le même point d’accès comme application/pdf. Le XML est analysé sans entités, sans DTD et sans accès réseau, et un fichier avec un DOCTYPE est refusé (EI-XML-DTD) avant qu’un validateur ne le lise, tout comme un fichier mal formé (EI-XML-SYNTAX) ou qui n’est pas une facture connue du canal (EI-XML-TYPE). Depuis la 0.18.4, le même fichier renvoyé pour le client et le canal est la facture déjà détenue (duplicate_of), comme sur POST /invoices ; rien de nouveau n’est envoyé.
Les fiches client, par partenaire GET
Depuis la 0.24.0 (C14). La clé de l’opérateur ou la clé d’opérateur en lecture seule ; depuis la 0.25.0 une clé de partenaire, qui obtient la liste de son propre partenaire (nommer un autre partner répond 403). Les fiches définies avec PUT /clients/{client}/profile, par identifiant de client en ordre d’octets, 500 à la fois. Quand truncated vaut true, next est le dernier identifiant de la page, et after= suivi de cet identifiant lit la page suivante. partner restreint la liste aux clients d’un partenaire. Un client qui a des clés mais pas de fiche n’est pas listé.