Docs

Odovzdanie faktúry, ktorú klient prijal cez kanál

  • V sandboxe
POST
/received

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.

Autorizácia

apiKey
headerAuthorizationBearer <token>

Kľúč posielajte ako token typu Bearer: Authorization: Bearer <your-api-key>. Stav služby je jediné volanie, ktoré nevyžaduje kľúč.

Parametre dotazu

route*string

Kanál, ktorým dokument prišiel.

Hodnota z"PEPPOL""PL-KSEF""RO-EFACTURA""FR-PA""DE-XRECHNUNG"
rail_id?string

Vlastné id dokumentu v kanáli (id dokumentu prístupového bodu, číslo KSeF, id stiahnutia z ANAF). 1 až 200 písmen, číslic a . _ : / @ + = # -.

Zhoda^[A-Za-z0-9._:/@+=#-]{1,200}$
client?string

Klient, 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.

Zhoda^[A-Za-z0-9][A-Za-z0-9._-]{0,63}$

Parametre hlavičky

Idempotency-Key*string

Jedineč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.

Dĺžka8 <= length <= 100

Telo požiadavky

body*stringapplication/xml

Telo odpovede

Uložené a zaradené do fronty na kontrolu kanála, ak už nezlyhalo; alebo už držané (duplicate_of).

application/json
  1. 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
Zhoda^rcv_[0-9a-f]{24}$
invoice_ref*string

Vlastné číslo faktúry v súbore (BT-1; FA(3) Fa/P_2), inak rail_id, inak id.

invoice_number?string
route*Route

Kanál krajiny. Rovnaké hodnoty ako country_route v stavových udalostiach.

Hodnota z"PEPPOL""PL-KSEF""RO-EFACTURA""FR-PA""DE-XRECHNUNG"
client*string
environment*string
Hodnota z"sandbox""production"
state*string
Hodnota z"received""validated""validation_failed"
direction*"in"
Hodnota z"in"
rail_id?string

Vlastné id dokumentu v kanáli, tak ako bolo uvedené pri POST /received.

document_sha256*string
Zhoda^[a-f0-9]{64}$
duplicate_of?string

Len pri POST /received, keď dokument už bol držaný pre klienta a kanál.

links?
errors?array<>
documents?array<>
created_at*string
Formátdate-time
updated_at*string
Formátdate-time
curl -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"}