Predați o factură primită de client printr-un canal
- În sandbox
De la versiunea 0.35.0 (17 oct. 2026). Corpul este XML-ul exact așa cum l-a livrat canalul (UBL, CII sau FA(3)); nu se
modifică nimic și nu se trimite nimic. Fișierul este stocat mai întâi, sigilat cu cheia de date a clientului, deoarece în drept
este deja primit; apoi validatoarele proprii ale canalului îl verifică, ca la o trimitere directă, iar rezultatul sosește ca
eveniment de stare (received, apoi validated sau validation_failed, cu direction: in) pe webhook-ul clientului și
la GET /received/{id}/events. Un fișier care nu respectă regulile este păstrat și apare ca validation_failed, cu erorile; nu
este abandonat niciodată. Un fișier care nu este o factură de păstrat este refuzat cu 422 și nu se stochează nimic, ca la
POST /invoices/xml: un DOCTYPE (EI-XML-DTD, niciodată analizat), XML care nu este bine format (EI-XML-SYNTAX) sau un
document care nu este o factură cunoscută de canal (EI-XML-TYPE). O verificare care nu a putut rula (un validator indisponibil) este
reluată, iar după ultima reîncercare factura intră în lista de gestionare și rămâne received. Un client predă cel mult
120 de documente pe minut și 2.000 pe zi, indiferent de cheia folosită (429, nepăstrat sub Idempotency-Key). Fișierul este
returnat ca descărcare (Content-Disposition: attachment).
Un document al canalului este o factură primită pentru client: după rail_id, când este dat, după SHA-256 al fișierului
când nu este. Același document din nou primește 202 cu duplicate_of; același rail_id cu alți octeți
primește 409 received-id-conflict, iar nimic nu se stochează. Facturile primite sunt păstrate separat de facturile pe care
clientul le trimite: nu apar în GET /invoices, în serii, în metrici sau în raportul lunar și nu blochează niciodată
o trimitere a aceluiași fișier. O factură primită este ștearsă odată cu retenția clientului, după ce nu mai este nimic deschis pe ea (verificarea
s-a încheiat sau o persoană a rezolvat rândul ei din lista de gestionare), și se află în exportul clientului, sub received/. Domeniul de acces submit;
o cheie de client acționează doar pentru propriul client.
apiKeyAuthorizationBearer <token>Trimiteți cheia ca token de tip bearer: Authorization: Bearer <your-api-key>. Starea serviciului este singurul apel care nu necesită cheie.
route*stringCanalul prin care a sosit documentul.
"PEPPOL""PL-KSEF""RO-EFACTURA""FR-PA""DE-XRECHNUNG"rail_id?stringId-ul propriu al canalului pentru document (id-ul documentului punctului de acces, numărul KSeF, id-ul de descărcare ANAF). De la 1 la 200 de litere, cifre și . _ : / @ + = # -.
^[A-Za-z0-9._:/@+=#-]{1,200}$client?stringClientul care l-a primit. Cheia operatorului îl numește (omis, clientul local propriu al operatorului); o cheie de client îl poate omite sau poate numi propriul client, iar orice alt client primește 403.
^[A-Za-z0-9][A-Za-z0-9._-]{0,63}$Idempotency-Key*stringO cheie unică pentru fiecare cerere logică (un UUID este suficient). O cheie care începe cu erp: (erp:{connector}:{scope}:{entity}:{id} al unei rețete de transport ERP, cu cheia operatorului sau a unui client) nu are fereastră de timp; se păstrează împreună cu primul răspuns până când clientul sau factura pe care a creat-o este ștearsă, astfel încât un document modificat, predat din nou după săptămâni, primește tot 409 idempotency-conflict. O astfel de cheie este acceptată doar la un export de conector ERP (POST /invoices cu un connector pe care această versiune îl citește, un export care este un obiect JSON nevid și cu cheia operatorului client); la orice altă cerere, un document canonic, POST /invoices/xml sau o anulare, răspunde 400 idempotency-key-not-allowed și nu se păstrează nimic, iar un export cu un număr mai lung de 40 de caractere primește 422 EI-SCHEMA pe care îl primește și sub orice altă cheie, de asemenea nepăstrat sub nicio cheie. Când operatorul eliberează un dead letter (îl anulează), răspunsurile anterioare despre acea factură dispar odată cu el, cel al transmiterii și, de la versiunea 0.35.0, cel al unei anulări refuzate anterior, astfel încât o reîncercare a acelei anulări rulează din nou și răspunde 200 cu factura anulată. De la versiunea 0.32.0, un răspuns 5xx și un 422 connector-settings-missing nu se păstrează, deci aceeași cerere cu aceeași cheie poate fi trimisă din nou. Cu cheia operatorului, aceasta nu poate începe cu client: (400), forma sub care sunt stocate cheile clienților.
8 <= length <= 100body*stringapplication/xmlStocat și pus în coadă pentru verificarea canalului, dacă nu a eșuat deja; sau deja existent (duplicate_of).
application/json- response
De la versiunea 0.35.0. O factură primită de client printr-un canal, așa cum a preluat-o POST /received. Ca Invoice, nu
conține conținutul facturii: nici vânzător, nici cumpărător, nici sume.
id*string^rcv_[0-9a-f]{24}$invoice_ref*stringNumărul propriu al facturii din fișier (BT-1; FA(3) Fa/P_2), altfel rail_id, altfel id-ul.
invoice_number?stringroute*RouteCanalul de transmitere. Aceleași valori ca country_route din evenimentele de stare.
"PEPPOL""PL-KSEF""RO-EFACTURA""FR-PA""DE-XRECHNUNG"client*stringenvironment*string"sandbox""production"state*string"received""validated""validation_failed"direction*"in""in"rail_id?stringId-ul propriu al canalului pentru document, așa cum a fost dat la POST /received.
document_sha256*string^[a-f0-9]{64}$duplicate_of?stringDoar la POST /received, când documentul era deja păstrat pentru client și canal.
links?errors?array<>documents?array<>created_at*stringdate-timeupdated_at*stringdate-timecurl -X POST "https://example.com/received?route=PEPPOL" \ -H "Authorization: Bearer <your-api-key>" \ -H "Idempotency-Key: order-2026-0001" \ -H "Content-Type: application/xml" \ -d 'string'{ "id": "string", "invoice_ref": "string", "invoice_number": "string", "route": "PEPPOL", "client": "string", "environment": "sandbox", "state": "received", "direction": "in", "rail_id": "string", "document_sha256": "string", "duplicate_of": "string", "links": { "self": "string", "events": "string" }, "errors": [ { "code": "string" } ], "documents": [ { "kind": "received-xml", "sha256": "string", "href": "string" } ], "created_at": "2019-08-24T14:15:22Z", "updated_at": "2019-08-24T14:15:22Z"}Listați și căutați facturile primite GET
De la versiunea 0.35.0. Aceiași parametri și același răspuns ca la GET /invoices, doar pentru facturile primite; state este received, validated sau validation_failed. O cheie de client le vede pe ale propriului client; operatorul le vede pe ale tuturor clienților sau pe ale unui client, cu client.
Căutați un cod de eroare sau de motiv GET
Returnează intrarea din catalog pentru un ID de regulă, un cod de eroare al canalului sau un cod de motiv francez (ID-uri și alias-uri).