Fișierele generate ale a până la 200 de facturi, într-un singur zip
- În sandbox
De la versiunea 0.33.0 (16 oct. 2026). Corp {"ids": [...]}, de la 1 la 200 de id-uri de factură. Zip-ul conține câte un fișier pentru fiecare
document generat (UBL, CII, FA(3), XRechnung, Factur-X, ZUGFeRD, PDF sau XML-ul primit, pentru o transmitere directă), numit
<invoice_number>.<xml|pdf> (cu tipul adăugat când o factură are două fișiere XML), și manifest.csv cu
invoice_id,invoice_ref,invoice_number,route,state,file,kind,sha256. JSON-ul canonic, raportul de validare
și exportul ERP nu sunt incluse. Un id necunoscut sau al altui client este omis fără a fi numit,
la fel ca o factură care nu are încă un fișier generat; X-Export-Skipped le numără. Domeniul de acces read; 10 exporturi pe minut pe
client, partajate cu GET /exports/{dataset}; un rând de audit data_exported cu SHA-256 al zip-ului.
apiKeyAuthorizationBearer <token>Trimiteți cheia ca token de tip bearer: Authorization: Bearer <your-api-key>. Starea serviciului este singurul apel care nu necesită cheie.
application/json- body
ids*array<>1 <= items <= 200Zip-ul.
response?fileapplication/zipbinarycurl -X POST "https://example.com/invoices/export" \ -H "Authorization: Bearer <your-api-key>" \ -H "Content-Type: application/json" \ -d '{ "ids": [ "string" ] }'"string"Opriți o factură care nu a fost încă transmisă POST
Funcționează doar cât timp factura este received, validated sau queued. Începând cu 0.18.3, după ce s-a încercat o trimitere și răspunsul s-a pierdut (o depășire de timp sau un 5xx), factura apare ca submitting, iar o anulare primește 409 send-in-progress, deoarece canalul o poate avea; procesul de lucru o stabilește ca submitted sau dead_letter. După ce canalul o are, o anulare este un document comercial (o notă de credit sau, în Polonia, un KOR), nu un apel API. Începând cu 0.18.5, anularea unei facturi deja anulate primește 200 cu factura, deci o reîncercare după un răspuns pierdut este sigură. Începând cu 0.18.6, cheia operatorului poate anula o factură dead_letter când nu s-a făcut niciodată un apel către canal pentru ea: nu poate fi nimic pe canal, deci același document poate fi trimis din nou după aceea. Când s-a făcut un apel, răspunsul este 409 dead-letter-reached-rail, deoarece o trimitere al cărei răspuns s-a pierdut poate fi acolo: verificați mai întâi cu canalul. Cheia unui client primește 409 dead-letter; operatorul decide.
Aflați starea curentă a unei facturi GET
Pagina următoare