Odovzdanie faktúry, ktorú klient prijal cez kanál
- V sandboxe
Od 0.35.0 (17. okt. 2026). Telo je XML presne tak, ako ho kanál doručil (UBL, CII alebo FA(3)); nič sa
nemení a nič sa neodosiela. Súbor sa najprv uloží, zapečatený dátovým kľúčom klienta, pretože podľa práva je
už prijatý; potom ho skontrolujú validátory kanála, ako pri priamom odovzdaní, a výsledok príde ako
stavová udalosť (received, potom validated alebo validation_failed, s direction: in) na webhook klienta a
na GET /received/{id}/events. Súbor, ktorý nespĺňa pravidlá, sa uchová a má stav validation_failed s chybami;
nikdy sa nezahodí. Súbor, ktorý nie je faktúrou na uchovanie, sa odmietne s 422 a nič sa neuloží, ako pri
POST /invoices/xml: DOCTYPE (EI-XML-DTD, nikdy sa nespracúva), XML, ktoré nie je dobre utvorené (EI-XML-SYNTAX), alebo
dokument, ktorý nie je faktúrou známou kanálu (EI-XML-TYPE). Kontrola, ktorú sa nepodarilo spustiť (validátor nedostupný), sa
zopakuje a po poslednom pokuse faktúra skončí v zozname na riešenie a zostane received. Klient odovzdá najviac
120 dokumentov za minútu a 2 000 za deň, bez ohľadu na kľúč (429, neukladá sa pod Idempotency-Key). Súbor sa
vráti ako stiahnutie (Content-Disposition: attachment).
Jeden dokument kanála je pre klienta jedna prijatá faktúra: podľa rail_id, ak je uvedené, inak podľa SHA-256
súboru. Ten istý dokument znova odpovie 202 s duplicate_of; rovnaké rail_id s inými bajtmi
odpovie 409 received-id-conflict a nič sa neuloží. Prijaté faktúry sú oddelené od faktúr, ktoré
klient odosiela: nie sú v GET /invoices, v číselnom rade, v metrikách ani v mesačnom prehľade a nikdy neblokujú
odoslanie toho istého súboru. Prijatá faktúra sa maže spolu s retenciou klienta, keď na nej nie je nič otvorené (jej
kontrola skončila alebo jej riadok na riešenie vybavila osoba), a je v exporte klienta pod received/. Rozsah submit;
kľúč klienta koná len za vlastného klienta.
apiKeyAuthorizationBearer <token>Kľúč posielajte ako token typu Bearer: Authorization: Bearer <your-api-key>. Stav služby je jediné volanie, ktoré nevyžaduje kľúč.
route*stringKanál, ktorým dokument prišiel.
"PEPPOL""PL-KSEF""RO-EFACTURA""FR-PA""DE-XRECHNUNG"rail_id?stringVlastné id dokumentu v kanáli (id dokumentu prístupového bodu, číslo KSeF, id stiahnutia z ANAF). 1 až 200 písmen, číslic a . _ : / @ + = # -.
^[A-Za-z0-9._:/@+=#-]{1,200}$client?stringKlient, ktorý ho prijal. Kľúč operátora ho uvádza (ak sa vynechá, vlastný klient operátora local); kľúč klienta ho môže vynechať alebo uviesť vlastného klienta a každý iný odpovie 403.
^[A-Za-z0-9][A-Za-z0-9._-]{0,63}$Idempotency-Key*stringJedinečný kľúč pre každú logickú požiadavku (UUID stačí). Kľúč, ktorý začína erp: (erp:{connector}:{scope}:{entity}:{id} transportného receptu ERP, s kľúčom operátora alebo klienta), nemá okno; uchováva sa s prvou odpoveďou, kým sa nezmaže klient alebo faktúra, ktorú vytvoril, takže zmenený dokument odovzdaný znova o týždne stále dostane 409 idempotency-conflict. Taký kľúč sa prijíma len pri exporte konektora ERP (POST /invoices s connector, ktorý táto verzia číta, export, ktorý je neprázdny objekt JSON, a s kľúčom operátora client); pri akejkoľvek inej požiadavke, kanonickom dokumente, POST /invoices/xml alebo zrušení odpovie 400 idempotency-key-not-allowed a nič sa neuloží a export s číslom dlhším ako 40 znakov dostane 422 EI-SCHEMA, aké dostane pod akýmkoľvek iným kľúčom, tiež neuložené pod žiadnym kľúčom. Keď operátor uvoľní dead letter (zruší ho), skoršie odpovede o tej faktúre odídu s ním, odpoveď na odoslanie a od 0.35.0 aj skoršie odmietnuté zrušenie, takže opakovanie toho zrušenia prebehne znova a odpovie 200 so zrušenou faktúrou. Od 0.32.0 sa odpoveď 5xx a 422 connector-settings-missing neukladajú, takže tú istú požiadavku s tým istým kľúčom možno poslať znova. S kľúčom operátora nesmie začínať client: (400), formou, pod ktorou sa ukladajú kľúče klientov.
8 <= length <= 100body*stringapplication/xmlUložené a zaradené do fronty na kontrolu kanála, ak už nezlyhalo; alebo už držané (duplicate_of).
application/json- response
Od 0.35.0. Faktúra, ktorú klient prijal cez kanál, tak ako ju prijal POST /received. Rovnako ako Invoice
nenesie obsah faktúry: žiadneho predávajúceho, kupujúceho ani sumy.
id*string^rcv_[0-9a-f]{24}$invoice_ref*stringVlastné číslo faktúry v súbore (BT-1; FA(3) Fa/P_2), inak rail_id, inak id.
invoice_number?stringroute*RouteKanál krajiny. Rovnaké hodnoty ako country_route v stavových udalostiach.
"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?stringVlastné id dokumentu v kanáli, tak ako bolo uvedené pri POST /received.
document_sha256*string^[a-f0-9]{64}$duplicate_of?stringLen pri POST /received, keď dokument už bol držaný pre klienta a kanál.
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"}Zoznam a vyhľadávanie prijatých faktúr GET
Od 0.35.0. Rovnaké parametre a odpoveď ako GET /invoices, len pre prijaté faktúry; state je received, validated alebo validation_failed. Kľúč klienta vidí faktúry vlastného klienta; operátor všetkých klientov alebo jedného klienta cez client.
Vyhľadanie kódu chyby alebo dôvodu GET
Vráti položku katalógu pre ID pravidla, kód chyby kanála alebo francúzsky kód dôvodu (ID a aliasy).