Stocker un identifiant d’accès, chiffré ; la valeur n’est jamais renvoyée
- Dans le bac à sable
En termes simples
Un processus ne stocke des identifiants d’accès que pour son propre environnement. legal_entity en lie un à l’identifiant du vendeur pour lequel il agit (numéro de TVA, NIP, SIREN ou identifiant d’entreprise) ; un identifiant sans cette étiquette sert les autres factures du client. La clé d’administration d’un client ne stocke que pour son propre client.
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é.
application/json- body
client*stringFacultatif avec une clé de client
^[A-Za-z0-9][A-Za-z0-9._-]{0,63}$route*string"PL-KSEF""RO-EFACTURA""PEPPOL""FR-PA""DE-XRECHNUNG"kind*stringissued_by*stringissued_on*stringdateexpires_on?stringdateenvironment?stringDoit être l’environnement de ce processus ; c’est la valeur par défaut.
"sandbox""production"legal_entity?stringlength <= 64value*stringStocké.
application/json- response
id?stringclient?stringroute?stringkind?stringissued_by?stringissued_on?stringexpires_on?stringenvironment?|sandbox ou production ; null pour un identifiant stocké avant le 3 oct. 2026, que seul un bac à sable utilise.
legal_entity?stringrevoked_at?stringstored?booleancurl -X POST "https://example.com/credentials" \ -H "Authorization: Bearer <your-api-key>" \ -H "Content-Type: application/json" \ -d '{ "client": "string", "route": "PL-KSEF", "kind": "string", "issued_by": "string", "issued_on": "2019-08-24", "value": "string" }'{ "id": "string", "client": "string", "route": "string", "kind": "string", "issued_by": "string", "issued_on": "string", "expires_on": "string", "environment": "string", "legal_entity": "string", "revoked_at": "string", "stored": true}Révoquer un identifiant d’accès ; l’enregistrement reste pour la piste d’audit POST
Précédent
Arrêter une facture qui n’a pas encore été transmise POST
Ne fonctionne que tant que la facture est received, validated ou queued. Depuis la 0.18.3, quand un envoi a été tenté et que sa réponse s’est perdue (délai dépassé ou erreur 5xx), la facture est en submitting et une annulation répond 409 send-in-progress, car le canal peut la détenir ; le traitement la règle ensuite en submitted ou dead_letter. Une fois que le canal l’a, une annulation est un document commercial (un avoir, ou un KOR en Pologne), pas un appel d’API. Depuis la 0.18.5, l’annulation d’une facture déjà annulée répond 200 avec elle, de sorte qu’un nouvel essai après une réponse perdue est sans risque. Depuis la 0.18.6, la clé de l’opérateur peut annuler une facture dead_letter quand aucun appel au canal n’a jamais été fait pour elle : rien ne peut être sur le canal, donc le même document peut être renvoyé ensuite. Quand un appel a été fait, la réponse est 409 dead-letter-reached-rail, car un envoi dont la réponse s’est perdue peut s’y trouver : vérifiez d’abord auprès du canal. Une clé de client reçoit 409 dead-letter ; l’opérateur décide.