AP
Developer Portal
APEX AP Service — REST API & SAPI dokumentace
Peppol Access Point • APEX API v1/v2 • SAPI-SK v1.0

APEX AP Developer Portal — kompletní dokumentace API a SAPI endpointů.

Technická reference všech 37 operací APEX Access Pointu: APEX API pro hlubokou integraci (odesílání včetně hromadného, příjem, validace, precheck, události, odpovědi, webhooky a MQTT, účastníci, reporting, licence) a SAPI pro zjednodušený přístup podle slovenské specifikace SAPI-SK v1.0. Ověřeno vůči zdrojovému kódu APEX 26.4.

APEX API
Odesílání, příjem, dávky
Asynchronní odesílání s idempotencí, hromadné dávky do 5 000 dokumentů, inbox v1/v2, stav, události a odpovědi.
SAPI
SAPI-SK v1.0
Odeslat, přijmout, potvrdit — s vlastní autentizací, refresh tokenem a synchronními kontrolami dokumentu i příjemce.
Účastníci
Lookup DIČ / IČO
Vyhledání partnera v síti Peppol (SML/SMP) včetně AS4 endpointu a ověření certifikátu.
Notifikace & reporting
Webhooky, MQTT, statistiky
Push notifikace o přijatých a odeslaných dokumentech, statistiky provozu, EUSR/TSR a licence.
Navigace portálem
Struktura dokumentace
Dokumentace odpovídá verzi APEX 26.4 (říjen 2026). Závazným strojově čitelným kontraktem je OpenAPI ve Swagger UI — /api-docs/api a /api-docs/sapi.
Integrační cesty

Dvě cesty, jak se napojit na APEX

APEX Access Point nabízí dva rovnocenné způsoby integrace. Výběr závisí na tom, kde běží váš systém a jaký styl komunikace potřebujete. Obě cesty pokrývají plný Peppol tok (odesílání i příjem) a můžete je i kombinovat.

A
Cesta A — přímá REST integrace

APEX REST API a SAPI

REST OAuth 2.0 JSON UBL 2.1 Webhooky / MQTT
👤 Pro koho
Vývojáři ERP, účetních systémů, e-shopů a portálů, kteří si chtějí postavit vlastního klienta a mít plnou kontrolu nad tokem.
⚙️ Jak to funguje
HTTPS volání na APEX s OAuth 2.0 Bearer tokenem (client_credentials). JSON tělo, UBL dokument jako XML text. Odesílání je asynchronní (202 / ACCEPTED), stav sledujete pollingem, webhooky nebo přes MQTT.
✅ Proč zvolit tuto cestu
  • Žádná dodatečná infrastruktura — stačí HTTPS klient
  • Okamžitá zpětná vazba: validace dokumentu a ověření příjemce ještě v rámci requestu
  • Idempotentní odesílání a hromadné dávky do 5 000 dokumentů
  • Jednoduché testování přes Swagger UI, Postman nebo curl na sandboxu
Otevřít API Reference →
B
Cesta B — managed messaging

QHUB (RabbitMQ message bus)

AMQPS RabbitMQ async DLQ Audit
👤 Pro koho
ERP a portály v ekosystému ASOL (např. QASIDA ERP, HOREC) a systémy třetích stran, které už používají messaging (RabbitMQ / AMQP 0-9-1) a chtějí asynchronní integraci bez přímého volání APEX.
⚙️ Jak to funguje
AMQPS připojení k RabbitMQ brokeru QHUB. Dokumenty k odeslání publikujete jako SynchronizationMessage s entitou PeppolDocument (30); přijaté dokumenty i výsledky vašich odeslání (PeppolDocumentEvent, 32) přicházejí do vaší delivery queue. Registraci a přístupové údaje zřizuje ASOL nebo váš partner.
✅ Proč zvolit tuto cestu
  • Asynchronní tok — váš systém nemusí být dostupný non-stop, zprávy čekají ve vaší queue
  • Výsledek každého odeslání jako událost (zařazeno, doručeno, zamítnuto, dead letter, MLS)
  • Jedna integrační vrstva pro více produktů ASOL, zákazníků i provozoven (routing podle tenanta a provozovny)
  • Audit každé zprávy v transakční tabulce QHUB
Otevřít Integrační příručku →
💡
Tip: Obě cesty můžete zkombinovat. Například: odesílání přes REST API (s okamžitou validací z akce v UI) a příjem přes QHUB (asynchronně, z vaší queue).
Prostředí

Prostředí, URL a přístupové údaje

Integraci vyvíjejte a testujte na sandboxu, do produkce přejdete výměnou URL a přístupových údajů. Obě prostředí mají stejné API, stejnou autentizaci a stejné limity.

Testování
Sandbox
API (base URL)
https://api.sandbox.apex.qasida.sk
Swagger UI
OpenAPI
/api-docs/api, /api-docs/sapi
Token (ASOL IAM)
https://iam.qasida.sk/oauth2/token
Síť Peppol
ne — dokumenty se doručují lokálně mezi účastníky sandboxu
🧪Sandbox nic neposílá do sítě Peppol. Odeslaný dokument APEX doručí lokálně příjemci, který musí být účastníkem tenanta ve stejném sandboxu s platnou licencí (i vašeho vlastního): přijde mu do inboxu s notifikací DOCUMENTS_RECEIVED a odesílatel následně dostane MLS. Místo AS4 událostí uvidíte LOOPBACK_DETECTED a LOOPBACK_PROCESSING_COMPLETED. SML/SMP se nevolá: lookup zná jen účastníky sandboxu a precheck hlásí příjemce vždy jako dostupného. SAPI neznámého příjemce odmítne hned (RECEIVER_NOT_FOUND); APEX API a dávky ho přijmou a dokument po vyčerpání pokusů (cca 7,5 min) skončí v DEAD_LETTER.
Ostrý provoz
Produkce
API (base URL)
obdržíte při onboardingu spolu s přístupovými údaji
Swagger UI / OpenAPI
/swagger-ui, /api-docs/api, /api-docs/sapi
Token (ASOL IAM)
/oauth2/token serveru ASOL IAM uvedeného v přístupových údajích
Síť Peppol
ano — produkční síť OpenPeppol (AS4, SML/SMP)
🔐Produkční přístupové údaje vydává ASOL (nebo váš partner) po podpisu smlouvy. Jsou vázané na vaši organizaci (tenanta) a její Peppol účastníky, které ASOL zaregistruje v SMP — odesílat můžete jen za tyto účastníky a při platné licenci. Sandbox a produkce mají oddělená data i přístupové údaje.
Přístupové údaje
Integrační klient v ASOL IAM (clientId + clientSecret), vázaný na jednu organizaci (tenanta). Sandboxový přístup obsahuje i testovacího účastníka 0245:<DIČ> a sandboxovou licenci; vyžádáte si ho přes ASOL nebo svého partnera.
OpenAPI a Swagger UI
Každé prostředí publikuje dva OpenAPI dokumenty — /api-docs/api (APEX API) a /api-docs/sapi (SAPI) — a Swagger UI na /swagger-ui s tlačítkem Authorize (OAuth 2.0 client_credentials). Z OpenAPI si můžete vygenerovat klienta (OpenAPI Generator, NSwag, Kiota…).
Související služby
Integrační příručka QHUB — asynchronní integrace přes RabbitMQ.
Zákaznický portál — aktivace služby, licence a podpora.
Hromadné odesílání, MQTT a webhooky jsou součástí APEX API — nic dalšího není třeba instalovat.
Přehled

Pro koho je tato dokumentace

APEX AP poskytuje dvě skupiny API: APEX API (/api/v1, /api/v2) pro hlubokou integraci a APEX SAPI (/sapi/v1) pro zjednodušené rozhraní podle specifikace SAPI-SK v1.0. Obě běží na stejném serveru a sdílejí data i tokeny.

Integrátor ERP
Potřebuje autentizaci, ověření příjemce, validaci, odeslání faktury a sledování doručení, případně hromadné dávky a příjem dokladů.
Klíčové sekce: Rychlý start, Odesílání, Příjem, Hromadné odesílání, Účastníci.
Backend vývojář
Řeší OAuth 2.0 tok, idempotenci, retry strategii, webhooky a MQTT, parsování SBDH payloadu a chybové kódy.
Klíčové sekce: Autentizace, Webhooky & MQTT, Chyby a limity, SAPI.
Support / provoz
Rychle zjišťuje stav dokumentu, čte události a odpovědi protistrany, sleduje dávky, statistiky a čerpání licence.
Klíčové sekce: Events, Responses, Batches, Reporting & licence.
Rychlý start

První integrace ve 4 krocích

Technická cesta od prvního requestu po odeslání a přijetí faktury přes APEX API. Všechny kroky si vyzkoušíte na sandboxu.

01
Token
Z ASOL IAM získejte access token grantem client_credentials (platnost podle expires_in) a posílejte ho v hlavičce Authorization: Bearer <token>. Před vypršením si vyžádejte nový.
Výsledek: přístup k /api/** i /sapi/**.
02
Odešlete
POST /api/v1/documents/send s hlavičkou Idempotency-Key (např. číslo faktury). Příjemce určuje receiverParticipantId (slovenské firmy 0245:DIČ). Odpověď 202 se stavem QUEUED a documentId. Při timeoutu opakujte se stejným klíčem.
Výsledek: dokument ve frontě na AS4 přenos.
03
Sledujte doručení
Zaregistrujte webhook (POST /api/v1/subscriptions) nebo MQTT, případně pollujte GET /api/v1/documents/{id}/status. Historii ukáže /events, odpovědi protistrany /responses.
Výsledek: DELIVERED, nebo jasný důvod chyby.
04
Přijímejte
Na notifikaci DOCUMENTS_RECEIVED nebo pravidelně volejte GET /api/v2/documents/inbox?status=VALIDATED, stáhněte detail a po uložení potvrďte POST /api/v1/documents/inbox/{id}/acknowledged.
Výsledek: faktura dodavatele ve vašem ERP.
💡
Volitelně před odesláním — k odeslání nejsou potřeba, hodí se hlavně během vývoje:
  • Ověření příjemce: GET /api/v1/participants/lookup/dic?schema=0245&dic=2024000001 (nebo /lookup/ico?ico=…) zjistí, zda je odběratel v síti Peppol a zda má použitelný certifikát.
  • Precheck: POST /api/v1/documents/precheck se stejným tělem jako send ověří dokument (XSD, EN 16931, Peppol BIS), existenci příjemce i podporu typu dokumentu bez odeslání — výsledkem je networkReady: true nebo seznam chyb.
Reference

REST API Reference

Všechny endpointy APEX API a SAPI: účel, kdy je volat, vstupy, výstupy, chování a typické chyby. Cesty jsou relativní k základní URL prostředí (např. https://api.sandbox.apex.qasida.sk); každý request kromě /sapi/v1/auth/token, /renew a /revoke vyžaduje Bearer token.

Odeslání jednoho dokumentu do sítě Peppol a sledování jeho osudu. Odesílání je asynchronní: POST /send dokument zkontroluje, uloží a zařadí do fronty, AS4 přenos proběhne na pozadí. Stav čtěte přes /status, historii přes /events a odpovědi protistrany přes /responses — nebo si nechte posílat notifikace (záložka Webhooky & MQTT).

POST v1 outbound

/api/v1/documents/send

Zkontroluje dokument a příjemce, uloží payload a zařadí dokument do fronty k AS4 odeslání. Odpověď 202 Accepted se stavem QUEUED.
Účel služby
Převezme jeden UBL dokument (faktura, dobropis, objednávka…) a zařadí ho do odesílací fronty. Ještě před odpovědí proběhne validace (XSD, EN 16931 Schematron, pravidla Peppol BIS), vyhledání příjemce přes SML/SMP a uložení payloadu. Samotný AS4 přenos provádí worker na pozadí. 202 znamená převzetí, ne doručení.
Kdy službu volat
  • při odeslání jednotlivé faktury z ERP (akce uživatele nebo plánovaný job)
  • po úspěšném /precheck, pokud chcete chyby zachytit ještě před odesláním
  • pro desítky až tisíce dokumentů najednou raději použijte POST /api/v1/batches
Idempotence — hlavička Idempotency-Key
Volitelná, doporučená. Nejvýše 200 znaků, unikátní pro dokument (např. číslo faktury). Stejný klíč se stejným obsahem do 24 hodin vrátí původní odpověď 202 (původní documentId a submittedAt, status vždy QUEUED) s hlavičkou Idempotent-Replayed: true a nic nového nezařadí — opakování po timeoutu tak fakturu nikdy neodešle dvakrát. Klíče jsou oddělené pro každého tenanta; krátký a kanonický tvar účastníka se považují za stejný obsah. Stejný klíč s jiným obsahem (dokument nebo metadata) → 409 IDEMPOTENCY_CONFLICT; souběžný request se stejným klíčem → 409 IDEMPOTENCY_IN_PROGRESS. Odmítnutý request (400/403/500) klíč nespotřebuje.
Životní cyklus po odeslání
QUEUED → PROCESSING → DELIVERED. Pokud pokus o AS4 přenos selže, dokument přejde do RETRYING a další pokus přijde za 30, 60, 120 a 240 s; páté selhání (nebo trvalá chyba, např. certifikát příjemce nevydaný CA OpenPeppol) → DEAD_LETTER, zpravidla do 8 minut. Negativní Peppol MLS od přijímajícího AP přepne dokument na FAILED — i když už byl DELIVERED. Licence neplatná v době odesílání → REJECTED.
Typické chyby
  • 400 — chybějící pole (např. Receiver participant ID is required), neúspěšná validace dokumentu nebo neshoda stran (tělo s validationErrors[])
  • 401 — chybějící nebo neplatný Bearer token
  • 403 — odesílatel chybí, není registrován nebo nepatří vašemu tenantovi; neplatná licence
  • 409 — IDEMPOTENCY_CONFLICT / IDEMPOTENCY_IN_PROGRESS
  • 500 — dokument se nepodařilo zařadit (Failed to queue document: …); sem patří i příjemce, který není v síti Peppol nebo nepřijímá daný typ dokumentu — proto ho ověřte přes /precheck nebo lookup
Payload a strany
ublDocument je XML text (ne Base64) — holý UBL dokument nebo UBL v obálce SBDH; úvodní UTF-8 BOM APEX odstraní. Typ a proces musí odpovídat obsahu (cbc:CustomizationID, cbc:ProfileID). Odesílatel a příjemce musí odpovídat cbc:EndpointID stran dokladu: dodavatel → odběratel; samofakturu posílá odběratel a objednávku kupující. Neshoda vrátí SENDER_SUPPLIER_MISMATCH / RECEIVER_CUSTOMER_MISMATCH (resp. SENDER_CUSTOMER_MISMATCH / RECEIVER_SUPPLIER_MISMATCH). Schematron se u dokumentů nad 5 MB přeskočí.
Vstupní pole (JSON)
Název
Popis
Stav
senderParticipantId
Peppol ID odesílatele, krátký (0245:2024000001) nebo kanonický tvar (iso6523-actorid-upis::0245:2024000001)
povinné
receiverParticipantId
Peppol ID příjemce; musí být registrován v síti Peppol (SML/SMP)
povinné
documentTypeId
Peppol identifikátor typu dokumentu (příloha v záložce Klíčové pojmy)
povinné
processId
Peppol identifikátor procesu, např. urn:fdc:peppol.eu:2017:poacc:billing:01:1.0
povinné
ublDocument
UBL dokument jako XML řetězec
povinné
Idempotency-Key
HTTP hlavička, 1–200 znaků
volitelné
Výstupní pole (202)
Název
Popis
documentId
UUID dokumentu v APEX — klíč pro /status, /events, /responses a notifikace
status
QUEUED
submittedAt
Čas převzetí (ISO 8601)
GET v1 outbound

/api/v1/documents/{documentId}/status

Aktuální stav odeslaného dokumentu. Vždy vrací aktuální stav — použijte ho pro polling a vždy, když notifikace vypadá mimo pořadí.
Účel služby
Vrátí stav dokumentu odeslaného přes /send, dávku nebo SAPI (SAPI providerDocumentId je stejné UUID). Notifikace nemají zaručené pořadí, proto je tento endpoint autoritativním zdrojem stavu.
Kdy službu volat
  • v polling modelu po odeslání (rozumný interval: sekundy až desítky sekund)
  • po notifikaci, která vypadá starší než poslední známý stav
  • při zobrazení stavu v seznamu dokumentů v ERP
Hodnoty status
QUEUED — čeká ve frontě
PROCESSING — worker právě odesílá přes AS4
DELIVERED — přijímající AP potvrdil přijetí (AS4 receipt)
RETRYING — pokus selhal, další je naplánovaný
DEAD_LETTER — pokusy vyčerpány nebo trvalá chyba; je nutný zásah (podpora ho po nápravě může zařadit znovu)
FAILED — přijímající AP vrátil negativní MLS (může následovat i po DELIVERED)
REJECTED — odmítnuto před odesláním, licence neplatná v době odesílání
SENT — součást číselníku, při odesílání se nepoužívá

Dokument se může dočasně vrátit z PROCESSING do QUEUED (např. při přerušení odesílání na nedostupný cíl) bez notifikace a bez spotřebování pokusu.
Typické chyby
  • 404 (prázdné tělo) — dokument neexistuje, nepatří vašemu tenantovi nebo jde o přijatý dokument (stav je jen pro odeslané)
  • 401 — neplatný token
Parametry
Název
Popis
Stav
documentId
UUID z odpovědi /send (path)
povinné
Výstupní pole
Název
Popis
documentId
UUID dokumentu
status
Aktuální stav (hodnoty vlevo)
submittedAt
Čas původního převzetí
POST v1 validace

/api/v1/documents/validate

Validace UBL dokumentu bez odeslání: XML Schema → EN 16931 Schematron → pravidla Peppol BIS 3.0. Vždy 200 — výsledek je v poli valid.
Účel služby
Ověří syntaktickou a pravidlovou správnost dokumentu dříve, než ho odešlete. /send provádí stejnou validaci (navíc kontroluje strany, licenci a příjemce). Pokud documentTypeId nezadáte, odvodí se z kořenového elementu: CreditNote → BIS 3.0 dobropis, jinak BIS 3.0 faktura. Podporovány jsou faktury a dobropisy BIS Billing 3.0 (včetně samofakturace, PINT a XRechnung), objednávky, odpovědi na objednávky, dodací listy, katalogy, MLR, IMR a MLS; pro neznámý typ vrátí chybu SCHEMATRON_001.
Kdy službu volat
  • při vývoji a ladění XML šablon faktur
  • při generování dokumentu ještě před uložením v ERP
  • při migraci nebo importu dávek dokladů
Výsledek
valid je true, jen pokud projdou všechny tři vrstvy; po vrstvách schemaValid, schematronValid, businessRulesValid. Každá chyba má level (ERROR/WARNING/INFO), code (např. BR-07, PEPPOL-EN16931-R004), message a location (XPath). Při úspěšném parsování vrátí i metadata dokladu.
Typické chyby
  • 400 — chybí tělo nebo je ublDocument prázdný
  • 415 — tělo není application/json
  • nevalidní dokument není HTTP chyba: 200 s valid: false
Vstupní pole
Název
Popis
Stav
ublDocument
UBL dokument jako XML řetězec
povinné
documentTypeId
Peppol typ dokumentu; výchozí BIS 3.0 Invoice
volitelné
Výstupní pole
Název
Popis
valid
Celkový výsledek
schemaValid / schematronValid / businessRulesValid
Výsledek po vrstvách
errors[] / warnings[]
level, code, message, location
documentType, documentId, issueDate
Typ dokladu, jeho číslo, datum vystavení
supplierName, customerName
Dodavatel a odběratel
totalAmount, currencyCode
Částka (řetězec) a měna
POST v1 validace

/api/v1/documents/precheck

Všechny kontroly, které by provedl /send, ale bez uložení a zařazení: validace dokumentu, existence příjemce v síti Peppol a podpora typu dokumentu. Výsledek networkReady.
Tři kontroly v pořadí
1. Dokument → valid (XSD, EN 16931, Peppol BIS)
2. Příjemce existuje → participantExists (SML/DNS najde SMP)
3. Směrování → canSend (SMP příjemce nabízí documentTypeId + processId, AS4 endpoint a platný certifikát)

networkReady = valid && participantExists && canSend
Kdy službu volat
  • za tlačítkem „Zkontrolovat“ před odesláním faktury
  • při onboardingu nového obchodního partnera
  • při hromadném zpracování k odfiltrování problémových dokladů
Kategorie chyb a varování
VALIDATION — chyba dokumentu nebo neshoda stran (kód pravidla, XPath)
PARTICIPANT — příjemce se nepodařilo najít v síti Peppol (PARTICIPANT_NOT_FOUND; hlásí se i při dočasné nedostupnosti SML/SMP)
ROUTING — příjemce nepodporuje typ/proces (DOCTYPE_NOT_SUPPORTED)

Varování neblokují odeslání, např. CERT_EXPIRING_SOON (certifikát příjemce vyprší do 30 dní).
Výkon, cache a chyby
  • kroky 2–3 používají SMP údaje příjemce, které APEX uchovává až 5 dní (bez ohledu na typ dokumentu); při jejich obnově počítejte s +200–800 ms — příjemce, který mezitím změnil registraci, může selhat až při odeslání
  • v sandboxu se SML/SMP nevolá: participantExists a canSend jsou vždy true
  • 200 se vrací vždy, i když kontroly neprojdou; licenci precheck nekontroluje
  • 400 — chybí povinné pole; 403 — chybějící nebo cizí odesílatel
Vstupní pole
Název
Popis
Stav
senderParticipantId, receiverParticipantId, documentTypeId, processId, ublDocument
Stejné tělo jako /send
povinné
Výstupní pole
Název
Popis
networkReady
Dokument lze odeslat
valid / participantExists / canSend
Výsledek tří kontrol
errors[] / warnings[]
category, code, message, location (u PARTICIPANT/ROUTING null)
checkedAt
Čas kontroly
GET v1 audit

/api/v1/documents/{documentId}/events

Kompletní chronologická historie událostí dokumentu (odeslaného i přijatého), nejstarší první.
Účel služby
Zaznamenaná historie zpracování: vznik, validace, zařazení, pokusy o odeslání, doručení, MLS, ukládání, vazby na odpovědi a hlášení SK TDD (C5). Na rozdíl od notifikací je seřazená podle createdAt.
Kdy službu volat
  • při řešení reklamace doručení (časová osa)
  • při analýze opakovaných pokusů: páry QUEUE_PROCESSING_STARTED / QUEUE_PROCESSING_FAILED
  • při auditu přijatého dokladu (MESSAGE_RECEIVED → MESSAGE_VALIDATED → MESSAGE_ACKNOWLEDGED)
Kategorie eventType
Lifecycle — MESSAGE_CREATED, _RECEIVED, _VALIDATED, _DELIVERED, _FAILED, _ACKNOWLEDGED
Validace — VALIDATION_SUCCESS, VALIDATION_SCHEMA_ERROR, VALIDATION_ERROR
Fronta — MESSAGE_QUEUED, QUEUE_PROCESSING_STARTED, QUEUE_PROCESSING_FAILED, QUEUE_DEAD_LETTER, QUEUE_MANUAL_REQUEUE, AS4_SEND_COMPLETED
Self-send — LOOPBACK_DETECTED, LOOPBACK_PROCESSING_COMPLETED/_FAILED (příjemce ve stejném APEX; v sandboxu vždy)
Úložiště — BLOB_STORAGE_INITIATED/_COMPLETED/_FAILED
Odpovědi — RESPONSE_LINKED, RESPONSE_UNLINKED
MLS — MLS_QUEUED, MLS_SENT, MLS_SEND_FAILED, MLS_SKIPPED_BY_TYPE, MLS_SKIPPED_NO_RECEIVER, MLS_RECEIVED, MLS_RECEIVED_NEGATIVE, MLS_RECEIVED_FROM_C5
TDD / C5 — TDD_CONVERSION_*, TDD_SUBMISSION_*, TDD_DEADLINE_*, TDD_SKIPPED_*
Jiné — DUPLICATE_DETECTED, PROCESSING_ERROR, TRANSPORT_ERROR

Neznámé hodnoty (i ze starších verzí) berte jako informativní.
Typické chyby
  • 404 — dokument neexistuje
  • prázdné pole [] — zatím bez událostí
Parametry
Název
Popis
Stav
documentId
UUID odeslaného nebo přijatého dokumentu (path)
povinné
Výstupní pole (každá událost)
Název
Popis
id
UUID události
messageId
documentId dokumentu, ke kterému událost patří
eventType
Kategorie (vlevo)
eventCode
Kód chyby nebo protokolu (např. EBMS-0010, BR-07)
eventMessage
Čitelný popis (neparsujte ho)
technicalDetails
Endpoint, HTTP status, výňatek odpovědi SMP…
stacktrace
Jen při neočekávaných chybách, jinak null
createdAt
Čas události (ISO 8601 s posunem)
GET v1 odpovědi

/api/v1/documents/{documentId}/responses

Aplikační odpovědi vyměněné k dokumentu (MLR, IMR, Order Response, Receipt Advice a Peppol MLS), nejstarší první.
Oba směry
Pro dokument, který jste odeslali: odpovědi protistrany včetně Message Level Status (MLS) od přijímajícího poskytovatele. Pro dokument, který jste přijali: odpovědi, které jste poslali vy, včetně MLS, který APEX vrátil vaším jménem. Jako odpověď dokumentu se hlásí jen první platný MLS od zúčastněného poskytovatele (pravidlo Peppol OP-MLS-02); ostatní se pouze auditují.
Typy a kódy
MLR (BIS 36a / T71; v tomto typu se vrací i Peppol MLS, rozlišíte ho podle documentTypeId …urn:peppol:edec:mls…), IMR (Invoice Response 3.0 / T111), ORDER_RESPONSE (BIS 28a), RECEIPT_ADVICE (BIS 30a)
Kódy: AP přijato, AB přijato bez potvrzení (MLS), RE zamítnuto, CA podmíněně přijato, UQ dotaz, IP ve zpracování, PD zaplaceno (IMR)
Issues
U RE a CA obsahuje issues[] jednotlivé důvody z odpovědi: type (kód důvodu, zpravidla BV business / SV syntax), code, description, severity (FATAL u RE, jinak WARNING) a xpath (zpravidla null). AP s prázdným seznamem = čisté přijetí.
Návratové hodnoty
  • [] — zatím bez odpovědi (běžné hned po odeslání)
  • [] — i když je documentId sám odpovědí
  • 404 — dokument není váš nebo neexistuje
Parametry
Název
Popis
Stav
documentId
UUID odeslaného nebo přijatého dokumentu (path)
povinné
Výstupní pole (každá odpověď)
Název
Popis
responseId
UUID odpovědi (pro stažení XML)
responseType
MLR, IMR, ORDER_RESPONSE, RECEIPT_ADVICE
responseCode / responseCodeDescription
AP/RE/CA/UQ/IP a jeho popis
documentTypeId
Typ dokumentu odpovědi z AS4 hlavičky
senderParticipantId
Kdo odpověď poslal
note
Volný text odpovědi (např. důvod zamítnutí)
issues[]
Seznam problémů (vlevo)
receivedAt
Čas přijetí odpovědi přes AS4
GET v1 odpovědi

/api/v1/documents/{documentId}/responses/{responseId}

Surové XML jedné odpovědi (UBL ApplicationResponse), Content-Type: application/xml.
Účel služby
Stáhne XML odpovědi ze seznamu /responses — obchodní odpovědi protistrany (IMR/MLR), odpovědi, kterou jste poslali vy, nebo MLR, které APEX vygeneroval a poslal AP odesílatele (C2).
Typické chyby
  • 404 — responseId nepatří k danému dokumentu (i když jsou obě ID stejná)

Dokumenty, které vám přišly ze sítě Peppol přes AS4. Pull model: seznam → detail → potvrzení. O novém dokumentu se dozvíte pollingem seznamu nebo notifikací DOCUMENTS_RECEIVED (webhook / MQTT). Endpointy existují ve verzi v1 (identifikátory v kanonickém tvaru iso6523-actorid-upis::0245:…) a v2 (krátké Peppol ID 0245:…). Pro nové integrace doporučujeme v2; potvrzení existuje jen ve v1.

GET v2 inbound

/api/v2/documents/inbox

Stránkovaný seznam přijatých dokumentů, nejnovější první (receivedAt DESC). Odesílatel a příjemce v krátkém tvaru 0245:2024000001.
Účel služby
Integrační plocha pro ERP, které si přijaté doklady stahuje pull modelem. Seznam neobsahuje XML (ublDocument je prázdné) — obsah získáte z detailu. Čtení seznamu nemění stav dokumentů.
Typický polling
  • pravidelně volejte se status=VALIDATED — to jsou dokumenty, které čekají na stažení
  • každý nový dokument stáhněte přes GET /api/v2/documents/inbox/{documentId}
  • po trvalém uložení v ERP zavolejte POST /api/v1/documents/inbox/{documentId}/acknowledged — z dalšího pollingu vypadne
Stavy přijatého dokumentu
VALIDATED — dokument prošel validací a čeká na stažení (posílá se DOCUMENTS_RECEIVED)
ACKNOWLEDGED — váš systém potvrdil převzetí
REJECTED — dokument neprošel validací (je v seznamu, ale bez notifikace)
FAILED — chyba při zpracování
RECEIVED — jen vnitřní mezistav během příjmu, v seznamu ho neuvidíte
Stránkování a filtr
offset / limit (výchozí 0 / 20; doporučujeme nejvýše 100); odpověď nese total — počet záznamů odpovídajících filtru. status rozlišuje velká a malá písmena; neznámá hodnota vrátí 400.
Query parametry
Název
Popis
Stav
status
VALIDATED, ACKNOWLEDGED, REJECTED, FAILED
volitelné
offset
Počet přeskočených záznamů (výchozí 0)
volitelné
limit
Velikost stránky (výchozí 20)
volitelné
Výstupní pole
Název
Popis
items[]
documentId, senderParticipantId, receiverParticipantId, documentTypeId, processId, receivedAt, status
total
Počet dokumentů odpovídajících filtru
offset, limit
Použité hodnoty stránkování
GET v2 inbound

/api/v2/documents/inbox/{documentId}

Detail přijatého dokumentu včetně celého payloadu — StandardBusinessDocument (obálka SBDH s UBL dokumentem uvnitř).
Payload
Pole ublDocument obsahuje kompletní StandardBusinessDocument tak, jak přišel sítí Peppol — kořenem je obálka SBDH, ne faktura. Validace přímo vůči UBL Invoice XSD proto selže; business dokument najděte podle jmenného prostoru kdekoli ve stromu. Identifikátory uvnitř payloadu se nepřepisují, krátký tvar platí jen pro JSON pole.
Parsujte s ohledem na jmenné prostory
Prefixy (cac:, cbc:…) nejsou součástí kontraktu a mohou se měnit mezi verzemi i v rámci jednoho dokumentu. Važte se na URI jmenných prostorů a lokální názvy z UBL 2.1 a Peppol BIS Billing 3.0.
Po stažení
Když je dokument trvale uložen ve vašem systému, potvrďte ho přes POST /api/v1/documents/inbox/{documentId}/acknowledged. Stažení samo o sobě stav nemění. Pokud v odpovědi chybí pole ublDocument, payload se právě nepodařilo načíst — dokument nepotvrzujte a zkuste to později.
Typické chyby
  • 404 (prázdné tělo) — dokument neexistuje, není adresován vašemu tenantovi nebo nejde o přijatý dokument
  • 401 — neplatný token
Parametry
Název
Popis
Stav
documentId
UUID přijatého dokumentu (path)
povinné
Výstupní pole
Název
Popis
documentId
UUID dokumentu
senderParticipantId
Odesílatel, krátký tvar (0245:1234567890)
receiverParticipantId
Příjemce, krátký tvar
documentTypeId, processId
Peppol typ dokumentu a proces
receivedAt
Čas přijetí
status
Stav dokumentu
ublDocument
Celý StandardBusinessDocument (XML řetězec)
GET v1 inbound

/api/v1/documents/inbox  ·  /api/v1/documents/inbox/{documentId}

Původní verze seznamu a detailu. Stejné parametry, stránkování, stavy, payload i HTTP kódy jako v2 — liší se pouze tvar identifikátorů.
Rozdíl v1 a v2
v1: senderParticipantId / receiverParticipantId v plném kanonickém tvaru ISO 6523 — iso6523-actorid-upis::0088:1234567890123.
v2: krátké Peppol ID — 0088:1234567890123, tedy stejný tvar, jaký posíláte v requestech a jaký vrací /participants/lookup.
Kompatibilita
Formát v1 je zmrazený a nezmění se. Obě verze čtou stejná data, můžete je tedy kombinovat. Nová verze API vzniká vždy pod novou cestou, publikovaná verze se nemění zpětně nekompatibilně.
POST v1 inbound

/api/v1/documents/inbox/{documentId}/acknowledged

Potvrzení, že váš systém přijatý dokument stáhl a zpracoval. Stav přejde na ACKNOWLEDGED. Odpověď 204 No Content.
Kdy službu volat
  • až když je dokument trvale uložen (import do ERP, commit v databázi)
  • pokud zpracování selhalo, nepotvrzujte — dokument zůstane v původním stavu pro další pokus
  • platí pro integrace v1 i v2 (potvrzení nenese identifikátor účastníka, proto nemá variantu v2)
Idempotence a chyby
Opakované potvrzení již potvrzeného dokumentu je bez efektu a vrátí znovu 204. Potvrdit lze přijatý dokument v jakémkoli stavu (i REJECTED, pokud ho chcete označit jako vyřízený); potvrzení se zapíše do událostí jako MESSAGE_ACKNOWLEDGED a platí i pro SAPI.
  • 404 — dokument neexistuje nebo nepatří vašemu tenantovi
  • 401 — neplatný token

Desítky až tisíce dokumentů jedním requestem (měsíční fakturace, migrace). Dávka přijme až 5 000 dokumentů a hned odpoví 202. Každý dokument pak na pozadí projde přesně stejnými kontrolami jako POST /api/v1/documents/send a zařadí se samostatně. Dokumenty dávky se odesílají až po dokumentech posílaných jednotlivě a tenanti se ve frontě střídají, takže velká dávka nebrzdí běžný provoz.

POST v1 nové batch

/api/v1/batches

Převzetí dávky dokumentů — JSON s metadaty nebo ZIP archiv UBL souborů. Odpověď 202 s batchId a hlavičkou Location.
Jak to funguje
202 znamená, že APEX dávku převzal, ne že jsou dokumenty platné. Dokumenty jsou nezávislé: neplatný dokument nezastaví ostatní, skončí REJECTED s důvodem. Výsledek sledujte přes GET /api/v1/batches/{batchId} (ne častěji než jednou za 10 s) nebo notifikaci BATCH_PROCESSED.
Limity
  • 1 až 5 000 dokumentů, nejvýše 100 MB na request, 10 MB na dokument
  • ZIP: navíc nejvýše 100 MB po rozbalení a 10 000 položek archivu
  • nejvýše 3 otevřené dávky (RECEIVED/PROCESSING) na tenanta
  • dokumenty se započítávají do měsíčního objemu licence
Idempotence
Vždy posílejte Idempotency-Key (1–200 znaků, např. ID běhu ERP). Stejný klíč a bajtově identické tělo → původní 202 s Idempotent-Replayed: true, nová dávka nevznikne. Jiné tělo → 409 IDEMPOTENCY_CONFLICT. Klíč dávky neexpiruje. Tělo si před odesláním uložte a při opakování pošlete stejné bajty (curl --data-binary).
ZIP dávka
Content-Type: application/zip (i application/x-zip-compressed); každý soubor = jeden dokument v UTF-8 (holý UBL nebo UBL v SBDH). Cesta souboru v archivu je clientReference dokumentu (soubory pojmenujte číslem dokladu). Název dávky a režim notifikací jdou do query parametrů clientReference a notify. Metadata APEX odvodí z dokumentu: typ z kořenového elementu + cbc:CustomizationID, proces z cbc:ProfileID, strany z cbc:EndpointID (dodavatel → odběratel; u samofaktury naopak; u objednávky kupující → prodávající). Soubor bez odvoditelných metadat skončí REJECTED s INVALID_METADATA.
Odmítnutí celé dávky
  • 400 BATCH_INVALID_REQUEST — nejde o JSON objekt/ZIP, chybí documents nebo povinné pole (zpráva uvádí cestu, např. documents[17].processId), duplicitní clientReference, neznámý notify
  • 400 INVALID_IDEMPOTENCY_KEY
  • 403 PARTICIPANT_NOT_AUTHORIZED / LICENCE_INVALID
  • 409 IDEMPOTENCY_CONFLICT / IDEMPOTENCY_IN_PROGRESS
  • 413 BATCH_TOO_LARGE
  • 429 TOO_MANY_OPEN_BATCHES / BATCH_INTAKE_BUSY (zopakujte po Retry-After)
Vstupní pole (JSON)
Název
Popis
Stav
clientReference
Vaše označení dávky (max 200 znaků)
volitelné
notify
BATCH (výchozí), DOCUMENT, BOTH
volitelné
documents[]
1 až 5 000 dokumentů
povinné
documents[].clientReference
Označení dokumentu (např. číslo faktury), v dávce unikátní — doporučujeme vždy
volitelné
documents[].senderParticipantId
Odesílatel; musí patřit vašemu tenantovi
povinné
documents[].receiverParticipantId
Příjemce
povinné
documents[].documentTypeId, processId
Jako u /documents/send
povinné
documents[].ublDocument
UBL dokument jako XML text (max 10 MB)
povinné
Výstupní pole (202)
Název
Popis
batchId
UUID dávky
clientReference
Jak jste poslali
status
Vždy RECEIVED
itemCount
Počet dokumentů
receivedAt
Čas převzetí
💡Pošlete hlavičku Expect: 100-continue — odmítnutí (429, 403, 400) pak přijde ještě před nahráním těla. Dávky jednoho tenanta neposílejte paralelně a stejnou fakturu neposílejte zároveň v dávce i přes /documents/send — odešly by dvě.
GET v1 nové batch

/api/v1/batches/{batchId}

Stav dávky: počty dokumentů podle stavu převzetí (items) a živé počty doručování vzniklých zpráv (messages).
Stav dávky
RECEIVED — převzatá, zpracování nezačalo
PROCESSING — dokumenty se validují a zařazují
PROCESSED — každý dokument je ACCEPTED, REJECTED nebo CANCELLED; doručování přijatých pokračuje (viz messages)
CANCELLED — zrušená klientem
items vs. messages
items = převzetí dokumentů: pending, processing, accepted, rejected, cancelled.
messages = doručování zpráv z přijatých dokumentů, stejné stavy jako /documents/{id}/status: queued, processing, delivered (včetně přechodného SENT), retrying, failed, rejected, deadLetter. Součet messages = accepted.
Typické chyby
  • 404 BATCH_NOT_FOUND — neexistuje nebo patří jinému tenantovi
Výstupní pole
Název
Popis
batchId, clientReference, notify, itemCount
Identita a nastavení dávky
status
Stav dávky (vlevo)
items{}
Počty dokumentů podle stavu převzetí
messages{}
Počty zpráv podle stavu doručování
receivedAt, processedAt, cancelledAt
Časy; processedAt je null, dokud nejsou zpracovány všechny dokumenty
GET v1 nové batch

/api/v1/batches/{batchId}/items

Dokumenty dávky v pořadí z requestu, volitelně jen v jednom stavu — např. status=REJECTED pro to, co je třeba opravit.
Důvody zamítnutí (errorCode)
DOCUMENT_VALIDATION_FAILED — opravte podle errors[]
INVALID_METADATA — metadata (u ZIP co chybí v dokumentu: DOCUMENT_NOT_UTF8, DOCUMENT_NOT_XML, DOCUMENT_TYPE_UNSUPPORTED, CUSTOMIZATION_ID_MISSING, PROFILE_ID_MISSING, SENDER_ENDPOINT_MISSING, RECEIVER_ENDPOINT_MISSING, METADATA_INVALID)
RECEIVER_NOT_FOUND — příjemce není v síti Peppol
RECEIVER_DOCUMENT_TYPE_UNSUPPORTED — příjemce typ nepřijímá
PARTICIPANT_NOT_AUTHORIZED — odesílatel není váš
LICENCE_INVALID — licence mezitím přestala platit
BATCH_ITEM_RETRIES_EXHAUSTED — dočasná chyba trvala déle než cca 45 min (8 pokusů), pošlete znovu
Stavy dokumentu dávky
PENDING — čeká (s vyplněným errorMessage po dočasné chybě čeká na další pokus)
PROCESSING — právě se validuje a zařazuje
ACCEPTED — zařazen; documentId použijte pro /documents/{id}/status, /events, /responses
REJECTED — odmítnut, viz errorCode
CANCELLED — zrušen s dávkou
Parametry
status (volitelné), page od 0, size výchozí 100, nejvýše 1 000. Chyby: 400 neplatný stav/stránkování, 404 BATCH_NOT_FOUND.
Výstupní pole (content[])
Název
Popis
seqNo
Pořadí v requestu (od 1)
clientReference
Vaše označení dokumentu (u ZIP cesta souboru)
receiverParticipantId
Příjemce (chybí, pokud ho ze ZIP souboru nešlo odvodit)
status
Stav dokumentu dávky
documentId
UUID zprávy, pokud ACCEPTED
errorCode, errorMessage, errors[]
Důvod zamítnutí; errors[] = code, message, location
attempts, processedAt
Počet dočasných selhání, čas zpracování
Obálka stránky
Název
Popis
content[]
Dokumenty na stránce
page, size
Číslo stránky (od 0) a velikost
totalElements
Počet dokumentů odpovídajících filtru
GET v1 nové batch

/api/v1/batches

Seznam dávek tenanta, nejnovější první; volitelně jen převzaté v intervalu [from, to) nebo v jednom stavu.
Parametry
from, to (ISO 8601 date-time), status (RECEIVED, PROCESSING, PROCESSED, CANCELLED), page od 0, size výchozí 20, nejvýše 1 000.
Odpověď
content[] s batchId, clientReference, status, notify, itemCount, receivedAt, processedAt, cancelledAt; dále page, size, totalElements. Počty dokumentů jsou v detailu dávky. Chyba 400 při neplatném stavu nebo stránkování.
POST v1 nové batch

/api/v1/batches/{batchId}/cancel

Zruší dokumenty, které ještě nejsou zařazené. Již přijaté (ACCEPTED) dokumenty jsou na cestě a nevolají se zpět.
Chování
Zruší se dokumenty PENDING i dokument, který se právě validuje (za chvíli skončí CANCELLED, proto může být v odpovědi ještě processing > 0). Dávka přejde na CANCELLED, přestane se počítat do limitu 3 otevřených dávek a BATCH_PROCESSED se pro ni nepošle. Odpovědí je stav dávky (jako GET /batches/{batchId}).
Typické chyby
  • 404 BATCH_NOT_FOUND
  • 409 BATCH_NOT_CANCELLABLE — dávka je už PROCESSED nebo CANCELLED
Notifikace dávky
Režim zvolíte polem notify. BATCH_PROCESSED přijde na každý aktivní webhook a MQTT queue tenanta; filtry webhooku se na něj neuplatňují. Nenese seznam dokumentů, pouze počty — dokumenty načtěte přes /items.
notifyBATCH_PROCESSEDNotifikace jednotlivých dokumentů
BATCH (výchozí)anopouze problémy: QUEUE_PROCESSING_FAILED, QUEUE_DEAD_LETTER, MLS_RECEIVED_NEGATIVE
DOCUMENTnevšechny, jako při jednotlivém odeslání
BOTHanovšechny

Vyhledání obchodního partnera v síti Peppol podle DIČ (nebo jiného identifikátoru se schématem) či IČO. Výsledek řekne, zda je partner v síti Peppol registrován, přes který AS4 endpoint přijímá a zda je certifikát jeho přístupového bodu použitelný. Pro slovenské subjekty používejte schéma 0245 (SK:DIČ) — Peppol ID má tvar 0245:2024000001.

GET v1 participants

/api/v1/participants/lookup/dic

Vyhledání podle DIČ nebo libovolného identifikátoru s ICD schématem. Lokální záznam, při starém nebo chybějícím záznamu živá kontrola v SML a SMP.
Složení Peppol ID
Peppol ID = <schema>:<dic>, plný identifikátor iso6523-actorid-upis::<schema>:<dic>. Hodnoty se používají přesně tak, jak je pošlete — bez oříznutí, změny velikosti písmen, odstranění prefixu SK a bez kontroly formátu. 2024000001 a SK2024000001 jsou dva různé identifikátory.
Pořadí vyhodnocení
1. Lokální záznam účastníka.
2. V sandboxu se vrátí lokální záznam (source=LOCAL), bez něj 404; SML/SMP se nevolá.
3. Záznam s SMP metadaty mladšími než TTL (výchozí 5 dní) → source=LOCAL.
4. Starší, nikdy neověřený nebo chybějící záznam → živá kontrola v SML a SMP:
  • SML hlásí, že účastník není registrován → 404 (i když lokální záznam existuje)
  • SML/SMP neodpoví → lokální záznam (LOCAL), bez něj 503
  • SMP publikuje AS4 endpoint pro BIS Billing 3.0 Invoice → source=SMP s endpointem a certifikátem
  • SMP nemá pro účastníka záznam Invoice / AS4 endpoint → source=SMP s uloženým endpointem nebo null
Platnost certifikátu — certificate.valid
true — certifikát publikovaný v SMP prošel během requestu plnou kontrolou: platnost, řetěz vydavatele a stav odvolání, na který CRL nebo OCSP skutečně odpověděl.
false — certifikát je s jistotou nepoužitelný, důvod v invalidReason: EXPIRED, NOT_YET_VALID, REVOKED, UNTRUSTED_ISSUER (nevydala ho CA OpenPeppol). Na takový endpoint nelze doručit.
null — stav se v tomto requestu nezjistil (certifikát z lokálního záznamu nebo soft-fail při nedostupném CRL/OCSP). Soft-fail nikdy nedá true.
valid a invalidReason jsou v JSON vždy, i s hodnotou null.
Typické chyby
  • 400 — chybí schema nebo dic
  • 404 — není registrován v síti Peppol, nebo prázdná hodnota (bez těla)
  • 503 — SML/SMP neodpovídá a lokální záznam neexistuje — zopakujte později
Query parametry
Název
Popis
Stav
schema
ICD kód schématu, např. 0245 (SK DIČ), 9950 (SK IČ DPH), 9929 (CZ VAT), 9914 (AT VAT), 0088 (GLN)
povinné
dic
Hodnota identifikátoru; slovenské DIČ = 10 číslic bez prefixu SK
povinné
Výstupní pole
Název
Popis
source
LOCAL (lokální záznam) nebo SMP (živé vyhledání v tomto requestu)
participantId
Plný identifikátor iso6523-actorid-upis::0245:…
peppolId
Krátký tvar 0245:2024000001
organizationName
Název z lokálního záznamu; u účastníka známého jen z SMP null
countryCode
ISO 3166-1 alpha-2; u SMP odvozeno ze schématu (0245 → SK); ZZ = neznámá
endpointUrl
AS4 endpoint přístupového bodu partnera (BIS Billing 3.0 Invoice)
smpUrl
SMP server partnera
enabled
Příznak lokálního záznamu; null, pokud záznam neexistuje
certificate
subject, issuer, serial, fingerprint (SHA-256), notBefore, notAfter, expired, valid, invalidReason
smpMetadataUpdatedAt
Čas posledního úspěšného ověření v SMP
GET v1 participants

/api/v1/participants/lookup/ico

Vyhledání podle IČO: IČO → DIČ přes slovenský Registr účetních závěrek (registeruz.sk) → dále přesně jako /lookup/dic.
Postup
1. IČO (bez okolních mezer, jinak bez úprav) se pošle do registeruz.sk a získá se DIČ. Výsledek se necachuje — každý request se ptá registru.
2. Registr nezná účetní jednotku, ta nemá DIČ, nebo registr vrátí 4xx (kromě 429) → 404.
3. Registr je nedostupný, neodpoví do 15 s, vrátí 5xx/429 nebo nečitelnou odpověď → 503.
4. Ze získaného DIČ a schema vznikne Peppol ID a vyhodnotí se stejně jako /lookup/dic.
Kdy službu volat
  • v ERP znáte jen IČO obchodního partnera
  • při automatickém doplňování Peppol identity do adresáře partnerů
Typické chyby
  • 400 — chybí ico
  • 404 — IČO se nepodařilo převést na DIČ nebo účastník není v síti Peppol
  • 503 — registeruz.sk nebo SML/SMP nedostupné
Query parametry
Název
Popis
Stav
ico
IČO, zpravidla 8 číslic; bez kontroly formátu
povinné
schema
Schéma pro složení Peppol ID z DIČ; výchozí 0245
volitelné
Výstupní pole
Název
Popis
—
Stejný objekt jako /lookup/dic

Push notifikace místo pollingu: o novém přijatém dokumentu a o událostech vašich odeslaných dokumentů. Dva kanály — HTTPS webhook (filtrovatelný, více odběrů) a MQTT topic (jeden na tenanta, všechny notifikace). Notifikace dokument pouze identifikuje, obsah si stáhnete přes API. Doručení je best-effort, nejvýše jednou a bez zaručeného pořadí: stav dokumentu berte vždy z pole status, nikdy z eventType.

Notifikace — formát a události
Jedna notifikace = jeden dokument a jedna událost (documentIds má vždy právě jeden prvek, tvar pole je zachován kvůli kompatibilitě). Pole s hodnotou null se v JSON vynechávají.
PoleVýznam
eventTypeCo notifikaci vyvolalo — ne stav dokumentu
subscriptionIdOdběr, pro který se doručuje (u MQTT chybí)
documentId / documentIdsUUID dokumentu / totéž jako jednoprvkové pole
receivedCountVždy 1, jen u DOCUMENTS_RECEIVED
directionIN přijatý, OUT odeslaný dokument
statusStav dokumentu v okamžiku odeslání notifikace
messageIdID zprávy; u přijatého dokumentu AS4 Message ID od odesílajícího AP
conversationIdConversation ID dokumentu (pokud existuje)
senderParticipantId, receiverParticipantIdPeppol ID včetně schématu (iso6523-actorid-upis::…)
documentTypeId, processIdPeppol typ dokumentu a proces
eventMessageČitelný detail, neparsujte ho
notifiedAtKdy byla notifikace sestavena. Webhook: číslo, Unix epoch sekundy se zlomkem (1776168005.123456000); MQTT: ISO 8601 řetězec
batchJen u BATCH_PROCESSED: batchId, clientReference, status, itemCount, accepted, rejected, cancelled
eventTypeSměrKdy
DOCUMENTS_RECEIVEDINPřijatý dokument prošel validací a je uložen (VALIDATED); u zamítnutého ani duplicitního dokumentu nepřijde
MESSAGE_QUEUEDOUTVáš dokument byl přijat a zařazen
QUEUE_PROCESSING_STARTEDOUTZačal pokus o odeslání (při každém pokusu; ne při self-send)
MESSAGE_DELIVEREDOUTDoručeno přijímajícímu AP (nebo lokálně při self-send)
QUEUE_PROCESSING_FAILEDOUTPokus selhal, další je naplánovaný
QUEUE_DEAD_LETTEROUTOdesílání vzdáno, dokument je DEAD_LETTER
MLS_RECEIVEDOUTPřišel pozitivní Peppol MLS
MLS_RECEIVED_NEGATIVEOUTPřišel negativní MLS; dokument je FAILED (i po DELIVERED)
BATCH_PROCESSED—Dávka je zpracována (podle notify)
Pořadí a stav dokumentu
Notifikace se odesílají asynchronně a nezávisle, i z různých instancí APEX, proto nemají zaručené pořadí ani pro jeden dokument — MESSAGE_DELIVERED může přijít před MESSAGE_QUEUED. status je stav přečtený při odeslání notifikace, může být novější než událost (např. MESSAGE_QUEUED se stavem DELIVERED) a notifikace se starším stavem může přijít po novější. Poslední přijatou notifikaci tedy neberte jako aktuální stav; v případě pochybnosti zavolejte GET /api/v1/documents/{documentId}/status. Ne každá změna stavu se notifikuje (např. REJECTED kvůli neplatné licenci).
Záruky doručení
Best-effort, at-most-once: každá notifikace se pošle jednou. Odpověď mimo 2xx, timeout nebo chyba spojení se pouze zaloguje — žádný retry ani opětovné doručení. Notifikace čekající na odeslání jsou jen v paměti a při zastavení instance se mohou ztratit. Selhaný webhook nikdy neovlivní odeslání ani příjem dokumentu. Spolehlivost proto stavějte na kombinaci notifikací a periodického pollingu (/inbox, /status).
POST v1 webhooky

/api/v1/subscriptions

Registrace HTTPS webhooku. APEX na něj pošle POST u každého dokumentu a události, které odpovídají filtrům. Odpověď 201 Created.
Požadavky na váš endpoint
URL musí být https:// a dostupná ze serveru APEX (dostupnost se při registraci neověřuje, přesměrování se nenásledují). Timeout spojení 2 s a odpovědi 2 s — vraťte 2xx co nejdříve (ideálně < 500 ms) a náročné zpracování provádějte asynchronně. Odběry tenanta se pro jednu událost volají postupně, pomalý endpoint tedy zdrží ostatní. Request má Content-Type: application/json, Accept: application/json a User-Agent: Apex-Webhook/1.0. Tělo není podepsané — k ověření APEX použijte customHeaders (např. tajný token).
Filtry
documentTypeFilters — seznam typů dokumentů, přesná shoda; platí pro přijaté i odeslané dokumenty.
senderParticipantFilters — seznam odesílatelů, přesná shoda na kanonický identifikátor tak, jak je v senderParticipantId notifikace (např. iso6523-actorid-upis::0245:1234567890; krátký tvar se neshoduje); jen pro přijaté dokumenty.
Prázdný seznam = bez omezení. Filtr podle typu události neexistuje; BATCH_PROCESSED filtry ignoruje.
Limity a customHeaders
Nejvýše 3 webhooky na tenanta (aktivní i pozastavené dohromady). Nejvýše 10 hlaviček; název max 100 znaků jen [A-Za-z0-9-_], hodnota max 1 000 znaků bez zalomení řádků. Host, Content-Length, Content-Type a Transfer-Encoding nelze přepsat (Accept a User-Agent ano). Hlavička, která pravidla nesplní, se tiše vynechá — zkontrolujte customHeaders v odpovědi.
Typické chyby
  • 400 — chybí name/url, URL není https://, příliš mnoho hlaviček (Problem Details s detail: "Invalid request content.")
  • 409 — tenant už má 3 webhooky
  • 401 — neplatný token
Vstupní pole
Název
Popis
Stav
name
Název odběru (max 100 znaků)
povinné
description
Popis (max 500 znaků)
volitelné
url
HTTPS URL (max 2 048 znaků)
povinné
active
Aktivní po uložení (výchozí true)
volitelné
documentTypeFilters[]
Filtr typů dokumentů
volitelné
senderParticipantFilters[]
Filtr odesílatelů (jen přijaté)
volitelné
customHeaders{}
Vlastní HTTP hlavičky
volitelné
Výstupní pole
Název
Popis
subscriptionId
UUID odběru
name, description, url, active
Uložené hodnoty
documentTypeFilters, senderParticipantFilters
Uložené filtry
customHeaders
Uložené hlavičky
createdAt, updatedAt
Časy vytvoření a poslední změny
GET v1 webhooky

/api/v1/subscriptions

Stránkovaný seznam webhooků tenanta, nejnověji vytvořené první.
Parametry
offset (výchozí 0), limit (výchozí 20, 1–100).
Odpověď
items[] (objekty jako při vytvoření), total (všechny odběry tenanta bez ohledu na stránku), offset, limit. Chyby 400 (limit < 1), 401.
GET PUT DELETE v1 webhooky

/api/v1/subscriptions/{subscriptionId}

Detail, úplná náhrada a smazání jednoho webhooku.
GET — detail
Vrátí odběr (stejný objekt jako při vytvoření). 404, pokud neexistuje nebo patří jinému tenantovi.
PUT — úplná náhrada
Tělo jako u POST; přepíší se všechna pole (ne PATCH). Pro dočasné pozastavení bez ztráty nastavení pošlete active: false. Změna platí pro notifikace odeslané po uložení. Odpověď 200 s aktualizovaným odběrem; 400 při neplatném těle, 404.
DELETE — smazání
Nevratně odstraní odběr, další notifikace na jeho URL se neposílají. Odpověď 204; 404, pokud neexistuje. Pokud chcete notifikace jen dočasně zastavit, použijte PUT s active: false.
POST v1 MQTT

/api/v1/subscriptions/queue

Vytvoří MQTT přístup tenanta: uživatele brokeru a topic, na který APEX publikuje všechny notifikace tenanta. Přihlašovací údaje se zobrazí pouze jednou.
Jak to funguje
Jeden MQTT přístup na tenanta. Topic (queueName, např. /apex/inbox/apex-sk2024000001) dostává notifikace přijatých i odeslaných dokumentů, přestože má v názvu inbox. Filtry a příznak active webhooků se na něj neuplatňují. Zpráva má stejný formát jako webhook, bez subscriptionId a s notifiedAt jako ISO 8601 řetězcem.
Připojení
Libovolný klient MQTT 3.1.1 s poli host, port, username, password (nebo mqttUrl, které má vždy schéma mqtt:// — zda broker vyžaduje TLS, určuje prostředí). Přihlaste se k topicu queueName doslovně, včetně úvodního lomítka a bez zástupných znaků (#, +) — uživatel brokeru má oprávnění jen na přesně tento topic. APEX publikuje s QoS 1, bez retain; zda se vám uchovají zprávy publikované během výpadku spojení, závisí na brokeru a nastavení vaší MQTT session (clean / persistent session).
Bezpečnost
password a úplné mqttUrl se vrátí jen v této odpovědi; na serveru je uložen pouze hash hesla. Při ztrátě hesla přístup smažte a vytvořte nový — vznikne nové heslo.
Typické chyby
  • 409 — MQTT přístup pro tenanta už existuje (nejprve ho smažte)
  • 400 — přístup se na brokeru nepodařilo zřídit; zopakujte později
  • 401
Výstupní pole (201)
Název
Popis
queueId
UUID záznamu přístupu
mqttUrl
Úplná MQTT URL s přihlašovacími údaji (jednorázově)
amqpUrl
Zpětně kompatibilní alias mqttUrl — nepoužívejte v nových integracích
host, port
Broker
vhost
Logický jmenný prostor brokeru (pro MQTT jen informativní)
username, password
Přihlašovací údaje (heslo jednorázově)
queueName
MQTT topic tenanta
createdAt, securityWarning
Čas vytvoření, bezpečnostní upozornění
DELETE /api/v1/subscriptions/queue
Smaže MQTT přístup tenanta: uživatel brokeru se okamžitě zruší (aktivní spojení se odpojí) a na topic se přestane publikovat. Poté můžete vytvořit nový přístup s novými údaji. Odpověď 204; 404, pokud přístup neexistuje.

Přehled provozu tenanta (statistiky odeslaných a přijatých dokumentů), historie statistických hlášení EUSR/TSR do OpenPeppol a stav licence s měsíčním čerpáním dokumentů.

🚧Reporting se zavádí. V /reporting/statistics jsou spolehlivé živé počty delivered, failed, topRecipients, topSenders a failedDocuments; agregované total, byDocumentType, byCountry a deliveryRate jsou zatím nulové nebo prázdné. /reporting/submissions zatím nevrací záznamy. Pro přesná čísla o vašich dokumentech použijte /api/v1/licenses/info (měsíční čerpání) a vlastní evidenci stavů.
GET v1 reporting

/api/v1/reporting/statistics

Agregované statistiky za období: odeslané a přijaté dokumenty, úspěšnost doručení, členění podle typu dokumentu a země, top partneři a dokumenty v chybovém stavu.
Období
period=month / quarter / year — aktuální kalendářní měsíc, čtvrtletí, rok.
from + to (oba, YYYY-MM-DD) — vlastní interval, period se ignoruje a v odpovědi je type=custom. Pokud pošlete jen jeden z nich, ignoruje se.
Bez parametrů — aktuální měsíc. Odpověď v period vždy uvádí přesně použitý rozsah.
Kdy službu volat
  • dashboard provozu v ERP nebo portálu
  • pravidelné reporty pro vedení
  • sledování trendů a chybovosti doručení
Význam čísel
sent / received: total, delivered, failed (FAILED + DEAD_LETTER), deliveryRate (0.0–1.0, null při nule), byDocumentType (klíče INVOICE, CREDIT_NOTE, ORDER, ORDER_RESPONSE, DESPATCH_ADVICE…), byCountry (země protistrany).
deliveryRate na nejvyšší úrovni počítá jen odeslané dokumenty.
topRecipients / topSenders — nejvýše 10 partnerů (name, peppolId v kanonickém tvaru, countryCode, count).
failedDocuments — dokumenty, které jsou právě v chybovém stavu (bez ohledu na období, oba směry): total, deadLetters, retrying, rejected.
Typické chyby
  • 400 — from po to nebo neznámé period
  • 401 / 403
GET v1 reporting

/api/v1/reporting/submissions

Historie měsíčních statistických hlášení do OpenPeppol: EUSR (End User Statistics Report) a TSR (Transaction Statistics Report), nejnovější první.
Pozadí
Každý Peppol Access Point musí OpenPeppol měsíčně hlásit statistiky: EUSR počítá transakce koncových uživatelů, TSR transakce podle typu dokumentu a směru. Hlášení generuje a odesílá APEX jako přístupový bod; od vás se nic nevyžaduje. Endpoint je připraven pro audit odeslaných hlášení, zatím však vrací prázdný seznam.
Stavy
PENDING — vygenerováno, neodesláno
SUBMITTED — odesláno, čeká na potvrzení
FAILED — odeslání selhalo (errorMessage), zopakuje se
VALIDATED — OpenPeppol hlášení přijal
Parametry
reportType (EUSR/TSR), status, offset (výchozí 0), limit (výchozí 20, 1–100). Např. ?reportType=EUSR&status=FAILED.
Odpověď
items[]: id, reportType, periodStart, periodEnd, reporterId, status, errorMessage, submittedAt, validatedAt, createdAt; dále total, offset, limit. Chyba 400 při neznámé hodnotě filtru.
GET v1 licence

/api/v1/licenses/info

Licence tenanta a čerpání měsíčního počtu dokumentů.
Počítání dokumentů
Limit maxDocuments je měsíční (-1 = neomezený). Všechny počty v documentUsage se týkají aktuálního kalendářního měsíce v UTC (periodStart–periodEnd). usedDocuments = odeslané + přijaté, každá uložená zpráva bez ohledu na stav (i QUEUED a FAILED).
Překročení limitu
Při limitExceeded: true odesílání i příjem fungují dál — je to signál k navýšení licence. Počítadla se vynulují začátkem dalšího měsíce. Neplatná licence (valid: false) však odesílání blokuje (REJECTED, resp. 403 LICENCE_INVALID).
Odpověď
serialNumber, companyName, branchName, licenseTypeCode, validFrom, validTo (formát 2026-01-01T00:00:00.000+0000), valid, autoProlong a documentUsage: maxDocuments, usedDocuments, remainingDocuments (-1 = neomezeně), usagePercentage (null u neomezené), limitExceeded, sentDocuments, receivedDocuments, periodStart, periodEnd.
Typické chyby
  • 404 (prázdné tělo) — tenant nemá aktivní licenci; licence po platnosti vrátí 200 s valid: false
  • 401

Autentizace podle SAPI-SK v1.0. APEX žádost přepošle do ASOL IAM (OAuth 2.0 client_credentials) a k IAM access tokenu přidá vlastní refresh token (30 dní, rotace při každém použití), takže klient nemusí při každém obnovení posílat client_secret. Access token ze SAPI platí i pro APEX API (/api/**) a naopak. Pole těchto endpointů jsou ve snake_case; /token, /renew a /revoke jsou veřejné (bez Bearer tokenu).

POST v1 SAPI auth

/sapi/v1/auth/token

Výměna client_id + client_secret za access token (JWT RS256 z ASOL IAM) a refresh token APEX.
Účel služby
Přihlášení integračního klienta. Tělo je JSON (Content-Type: application/json; application/x-www-form-urlencoded vrátí 415). APEX přepošle údaje do IAM a vrátí jeho access token spolu s novým refresh tokenem. Platnost access tokenu udává pole expires_in.
Kdy službu volat
  • při startu integračního klienta
  • když refresh token vypršel nebo byl zneplatněn
  • běžné obnovení provádějte přes /renew
Bezpečnost
Údaje klienta jsou vázané na jednu organizaci (tenanta) — nesdílejte je mezi systémy a neukládejte do zdrojového kódu. Tokeny nikdy neposílejte v URL. Parametr scope je volitelný a přepošle se do IAM; o přístupu k dokumentům a účastníkům rozhoduje tenant, ke kterému jsou údaje klienta vázané.
Typické chyby
  • 400/401 SAPI-AUTH-001 — IAM odmítl údaje (stav vrací IAM)
  • 400 — nečitelné JSON tělo (Problem Details)
  • 415 — jiný Content-Type než JSON
  • 500 SAPI-AUTH-999 — IAM nedostupný nebo interní chyba; zopakujte později
Vstupní pole (JSON)
Název
Popis
Stav
client_id
Identifikátor klienta
povinné
client_secret
Tajemství klienta
povinné
grant_type
client_credentials
povinné
scope
Rozsah pro IAM (přístup určuje tenant)
volitelné
Výstupní pole (200)
Název
Popis
access_token
JWT (RS256) z ASOL IAM pro hlavičku Authorization: Bearer
token_type
Bearer
expires_in
Platnost access tokenu v sekundách
scope
Rozsah z IAM nebo null
refresh_token
Refresh token APEX, platný 30 dní; vždy přítomen
GET v1 SAPI auth

/sapi/v1/auth/token/status

Informace o aktuálním access tokenu z hlavičky Authorization: platnost, zbývající čas a doporučení obnovit.
Účel služby
Diagnostika a plánování obnovy tokenu. Vyžaduje platný Bearer token (hlavička X-Peppol-Participant-Id není potřeba). should_refresh je true, když do vypršení zbývají méně než 3 minuty.
Kdy službu volat
  • v health-checku integračního klienta
  • při ladění problémů s autentizací
  • obnovu je jednodušší plánovat přímo z expires_in
Typické chyby
  • 401 SAPI-AUTH-002 — token chybí, je neplatný nebo vypršel
Výstupní pole
Název
Popis
valid
Při 200 vždy true
token_type
access
client_id
Subjekt tokenu (claim sub; u klientského tokenu UUID)
issued_at, expires_at
Čas vydání a vypršení (UTC)
expires_in_seconds
Zbývající sekundy
should_refresh
Méně než 3 minuty do vypršení
refresh_recommended_at
Doporučený čas obnovy (vypršení − 3 min)
POST v1 SAPI auth

/sapi/v1/auth/renew

Nový access token a nový refresh token výměnou za aktuální refresh token. Rotace — použitý refresh token se okamžitě zneplatní.
Rotace a platnost
Každé volání zneplatní předložený refresh token a vydá nový s platností 30 dní od obnovení (klient, který pravidelně obnovuje, se tedy nemusí znovu přihlašovat). Nový refresh token si vždy uložte — starý už nefunguje. Pokud obnovení v IAM selže, předložený refresh token je již spotřebovaný a je třeba se přihlásit přes /token.
Detekce opakovaného použití
Předložení již použitého nebo zneplatněného refresh tokenu vrátí 401 SAPI-AUTH-006 a z bezpečnostních důvodů zneplatní všechny refresh tokeny daného klienta (již vydané access tokeny doběhnou do své expirace). Klient se pak musí přihlásit přes /token. U více instancí klienta proto refresh token sdílejte, nebo ať má každá instance vlastní.
Typické chyby
  • 401 SAPI-AUTH-007 — refresh token je neplatný, poškozený nebo vypršel
  • 401 SAPI-AUTH-006 — refresh token už byl použit nebo zneplatněn
  • SAPI-AUTH-001 — IAM odmítl uložené údaje klienta (např. změněné client_secret)
  • 500 SAPI-AUTH-999 — interní chyba nebo IAM nedostupný
Vstupní pole (JSON)
Název
Popis
Stav
refresh_token
Aktuální refresh token
povinné
Výstupní pole
Název
Popis
access_token, token_type, expires_in, scope, refresh_token
Stejně jako u /token — nová dvojice tokenů
POST v1 SAPI auth

/sapi/v1/auth/revoke

Zneplatnění refresh tokenu (RFC 7009, idempotentní). Na základě vlastnictví tokenu — bez client_id/client_secret.
Chování
Refresh token APEX se zneplatní okamžitě; další /renew s ním vrátí 401. Opakované zneplatnění již neplatného tokenu vrátí také 200 ("Token was already invalid or expired"). Jiný token APEX přepošle k revokaci do IAM.
Access tokeny
APEX ověřuje access token lokálně (podpis a expirace), proto access token zůstane platný do své expirace i po revokaci. Při bezpečnostním incidentu zneplatněte refresh token a nechte v IAM změnit client_secret.
Kdy službu volat
  • při odstavení integračního klienta
  • při podezření na únik refresh tokenu
  • při rotaci přístupových údajů
Typické chyby
  • SAPI-AUTH-001 — IAM odmítl revokaci jiného tokenu
  • 500 SAPI-AUTH-999 — IAM nedostupný
Vstupní pole (JSON)
Název
Popis
Stav
token
Token ke zneplatnění (refresh token APEX)
povinné
token_type_hint
refresh_token
volitelné
Výstupní pole
Název
Popis
success
Při 200 vždy true
message
Např. Refresh token revoked successfully
timestamp
Čas odpovědi (ISO 8601)

Tři operace podle SAPI-SK v1.0: odeslat, přijmout, potvrdit. Každý request nese hlavičku X-Peppol-Participant-Id (organizační kontext — účastník vašeho tenanta; krátký i kanonický tvar). Pole dokumentových endpointů jsou v camelCase; neznámá pole se tiše ignorují, proto dodržte přesné názvy.

POST v1 SAPI outbound

/sapi/v1/document/send

Předání dokumentu k doručení přes Peppol. Kontroly proběhnou synchronně, doručení asynchronně: 200 ACCEPTED = převzetí do úschovy, 4xx/5xx REJECTED = nic se nezařadilo.
Kontroly před ACCEPTED
1. Request — hlavičky, pole metadata, payload, payloadFormat (jen XML), payloadEncoding (jen UTF-8), volitelný checksum.
2. Oprávnění — účastník z hlavičky i metadata.senderParticipantId patří vašemu tenantovi a jsou totožní; tenant má platnou licenci.
3. Dokument — well-formed XML, XSD, Schematron (EN 16931 / Peppol BIS) a business pravidla pro documentTypeId.
4. Strany — odesílatel a příjemce jsou strany uvedené v dokumentu (dodavatel → odběratel; samofakturu posílá odběratel, objednávku kupující).
5. Příjemce — je registrován v síti Peppol (SML/SMP) a nabízí documentTypeId + processId přes AS4.
Doručení
SAPI výsledek doručení nehlásí (SAPI-SK v1.0 §9.5). Uložte si providerDocumentId — je to UUID dokumentu v APEX, takže se stejným tokenem můžete sledovat doručení přes GET /api/v1/documents/{providerDocumentId}/status, /events nebo webhooky.
Idempotence (Idempotency-Key, povinná)
Nový jedinečný klíč (např. UUID, max 200 znaků) pro každý dokument; klíče jsou oddělené pro každého tenanta. Stejný klíč + stejný request (payload, odesílatel, příjemce, typ, proces) do 24 h → původní odpověď ACCEPTED (stejné providerDocumentId a receivedAt), nic se nezařadí podruhé. Jiný request → 409 IDEMPOTENCY_CONFLICT. První request ještě běží → 409 IDEMPOTENCY_IN_PROGRESS (opakujte se stejným klíčem). Odmítnutý request klíč nespotřebuje. Po 24 h se klíč chová jako nový — neopakujte tedy staré requesty po dni.
Opakování
Opakujte, jen pokud je error.retryable true (409 IDEMPOTENCY_IN_PROGRESS, 503, 500, 429), s exponenciálním odstupem a stejným Idempotency-Key. Při kontaktu s podporou uveďte error.correlation_id.
Hlavičky a tělo (JSON)
Název
Popis
Stav
Idempotency-Key
Hlavička, 1–200 znaků
povinné
X-Peppol-Participant-Id
Hlavička; stejný účastník jako metadata.senderParticipantId
povinné
metadata.senderParticipantId
Odesílatel (0245:1234567890 nebo kanonický tvar)
povinné
metadata.receiverParticipantId
Příjemce
povinné
metadata.documentTypeId
Peppol typ dokumentu
povinné
metadata.processId
Peppol proces
povinné
metadata.documentId
Vaše označení, jen informativní
volitelné
metadata.creationDateTime
Informativní; pokud je uvedeno, musí být ISO 8601 s posunem
volitelné
payload
Dokument jako UTF-8 XML text (ne Base64) — holý UBL nebo UBL v SBDH; doporučujeme do 10 MB
povinné
payloadFormat
XML
povinné
payloadEncoding
UTF-8 (výchozí)
volitelné
checksum
SHA-256 z UTF-8 bajtů payload, hex (64 znaků)
volitelné
Výstupní pole (200)
Název
Popis
providerDocumentId
UUID dokumentu v APEX (pro podporu i APEX API)
status
Vždy ACCEPTED — převzetí, ne doručení
receivedAt
Kdy APEX dokument převzal (UTC); při replay původní hodnota
timestamp
Čas vytvoření této odpovědi (UTC)
Odmítnutí (4xx/5xx)
Název
Popis
status
REJECTED
timestamp
Čas odpovědi
errorCode
Důvod (tabulka níže)
errorMessage
Popis důvodu
error
Obálka SAPI chyby: category, code, message, details[], retryable, correlation_id
HTTPerrorCodeerror.coderetryablePříčina
400INVALID_REQUESTSAPI-VAL-001nechybí/prázdná hlavička Idempotency-Key (nebo > 200 znaků) či X-Peppol-Participant-Id; tělo není platný JSON; neplatné creationDateTime
400INVALID_METADATASAPI-VAL-001nechybí metadata nebo některý z identifikátorů, případně obsahuje řídicí znaky
400PAYLOAD_MISSINGSAPI-VAL-001nechybí payload (např. tělo podle specifikace document{content})
400INVALID_DOCUMENT_FORMATSAPI-VAL-001nepayloadFormat není XML, payloadEncoding není UTF-8, nesedí checksum
400INVALID_DOCUMENT_FORMATSAPI-VAL-002nepayload není well-formed XML
400UNSUPPORTED_DOCUMENT_TYPESAPI-VAL-002nepro documentTypeId neexistují validační pravidla
400DOCUMENT_VALIDATION_FAILEDSAPI-VAL-002nechyby XSD, Schematronu, business pravidel nebo stran; seznam v error.details[] (field = umístění, issue = popis, value = kód pravidla)
400RECEIVER_NOT_FOUNDSAPI-VAL-021nepříjemce není v síti Peppol (v sandboxu není účastníkem sandboxu)
400UNSUPPORTED_DOCUMENT_TYPESAPI-VAL-021nepříjemce nenabízí typ dokumentu a proces přes AS4
403AUTHORIZATION_FAILEDSAPI-AUTH-007neúčastník z hlavičky nebo odesílatel nepatří vašemu tenantovi, nebo se navzájem liší
403AUTHORIZATION_FAILEDSAPI-AUTH-008netenant nemá platnou licenci
409IDEMPOTENCY_CONFLICTSAPI-VAL-010neklíč použitý pro jiný request — použijte nový klíč
409IDEMPOTENCY_IN_PROGRESSSAPI-VAL-010anorequest se stejným klíčem se právě zpracovává
503SERVICE_UNAVAILABLESAPI-PROC-002anodočasně nedostupné SML/SMP, validace nebo úložiště
500PROCESSING_ERRORSAPI-PROC-001anoneočekávaná chyba
ℹ️Odchylky od SAPI-SK v1.0: cesta /sapi/v1/document/send (specifikace: /sapi/v1/documents), identifikátor providerDocumentId (specifikace: apDocumentId), dokument v plochých polích payload, payloadFormat, payloadEncoding (specifikace: document{content, format, encoding} — takové tělo skončí PAYLOAD_MISSING), navíc povinné hlavičky X-Peppol-Participant-Id a Idempotency-Key a kontroly 3–5 nad rámec minima specifikace. Odpovědi 401 a 429 mají pouze obálku error (bez status); 415, 405 a 406 mají formát Problem Details (RFC 9457) — rozhodujte podle HTTP kódu.
GET v1 SAPI inbound

/sapi/v1/document/receive

Seznam přijatých dokumentů účastníka z hlavičky, nejstarší první, s kurzorovým stránkováním.
Stránkování kurzorem
První volání bez pageToken. Hodnotu nextPageToken z odpovědi pošlete jako query parametr pageToken dalšího volání; nextPageToken: null = poslední stránka. Kurzor je neprůhledný řetězec — neparsujte ho ani neskládejte. Pro všechny stránky jednoho průchodu zachovejte status, limit a hlavičku. Parametr nextPageToken se přijme jako alias pageToken (pokud pošlete oba, musí být stejné).
Doporučený polling
  • pravidelně (např. každou minutu) začněte od začátku se status=RECEIVED
  • každý dokument stáhněte přes detail, uložte a potvrďte
  • potvrzené dokumenty z dalšího průchodu vypadnou; starý kurzor neodkládejte na později
Stavy
RECEIVED — přijaté a zvalidované, dosud nepotvrzené
ACKNOWLEDGED — potvrzené (přes SAPI i přes APEX API — stav je společný)
Bez filtru oba. Dokumenty odmítnuté při validaci se v seznamu neobjeví. Seznam vrací jen metadata, stav dokumentů nemění.
Typické chyby
  • 400 SAPI-VAL-001 — neplatný pageToken, rozdílné pageToken/nextPageToken, záporný limit
  • 400 (Problem Details) — chybí hlavička nebo limit není číslo
  • 401 SAPI-AUTH-002, 403 SAPI-AUTH-007 — účastník nepatří vašemu tenantovi
  • 429 SAPI-RATE-001
Parametry
Název
Popis
Stav
X-Peppol-Participant-Id
Hlavička — účastník příjemce (krátký nebo kanonický tvar)
povinné
pageToken
Kurzor z nextPageToken předchozí odpovědi
volitelné
limit
Velikost stránky, výchozí 20; doporučujeme nejvýše 100
volitelné
status
RECEIVED nebo ACKNOWLEDGED
volitelné
Výstupní pole
Název
Popis
documents[].documentId
UUID dokumentu v APEX (pro detail a potvrzení) — ne číslo faktury
documents[].documentTypeId, processId
Peppol typ dokumentu a proces
documents[].senderParticipantId, receiverParticipantId
Kanonický tvar iso6523-actorid-upis::…
documents[].creationDateTime
Kdy APEX dokument přijal (ne datum vystavení faktury)
nextPageToken
Kurzor další stránky nebo null
GET v1 SAPI inbound

/sapi/v1/document/receive/{documentId}

Detail přijatého dokumentu: metadata a celý StandardBusinessDocument (obálka SBDH s business dokumentem) jako XML řetězec.
Payload
payload je StandardBusinessDocument tak, jak přišel sítí Peppol, znovu serializovaný — prefixy jmenných prostorů a formátování se mohou lišit od originálu. Business dokument najděte podle jmenného prostoru, parsujte s ohledem na jmenné prostory a nevalidujte kořen přímo vůči UBL XSD. Stažení stav nemění.
Typické chyby
  • 404 (prázdné tělo) — ID není UUID nebo dokument neexistuje
  • 403 SAPI-AUTH-009 — dokument není adresován účastníkovi z hlavičky
  • 400 SAPI-DOC-002 — nejde o přijatý dokument vašeho tenanta
  • 401 SAPI-AUTH-002, 429 SAPI-RATE-001
Výstupní pole
Název
Popis
receivedAt
Kdy APEX dokument přijal
metadata
Stejný objekt jako v seznamu (documentId, documentTypeId, processId, senderParticipantId, receiverParticipantId, creationDateTime)
payload
StandardBusinessDocument jako UTF-8 XML řetězec
payloadFormat
XML
POST v1 SAPI inbound

/sapi/v1/document/receive/{documentId}/acknowledge

Potvrzení, že váš systém dokument bezpečně převzal. Stav přejde na ACKNOWLEDGED. Idempotentní.
Kdy službu volat
  • až po stažení detailu, zpracování XML a trvalém uložení dokumentu
  • pokud některý krok selhal, nepotvrzujte — dokument zůstane v status=RECEIVED
  • opakované potvrzení vrátí 200 s původním časem potvrzení
Typické chyby
  • 404 (prázdné tělo) — dokument neexistuje nebo není váš
  • 403 SAPI-AUTH-009 — dokument není adresován účastníkovi z hlavičky
  • 409 SAPI-DOC-002 — jde o odeslaný, ne přijatý dokument
Parametry
Název
Popis
Stav
documentId
documentId ze seznamu (path); tělo se neposílá
povinné
X-Peppol-Participant-Id
Hlavička — příjemce dokumentu
povinné
Výstupní pole
Název
Popis
documentId
Potvrzený dokument
status
ACKNOWLEDGED
acknowledgedDateTime
Čas (prvního) potvrzení, ISO 8601 s posunem
Klíčové pojmy, stavy a identifikátory
Základní pojmy, které potřebujete při každé integraci: rozdíl mezi rozhraními, tvary identifikátorů, životní cykly dokumentů, validace a odpovědi v síti Peppol.
APEX API (/api/v1, /api/v2) je plné REST API: odesílání (i hromadné), příjem, validace, precheck, stav, události, odpovědi (MLR/IMR/MLS), webhooky a MQTT, vyhledání účastníků, statistiky a licence. Token z ASOL IAM (client_credentials).

APEX SAPI (/sapi/v1) je zjednodušené rozhraní podle slovenské specifikace SAPI-SK v1.0: odeslat, přijmout, potvrdit. Odesílání je také asynchronní — ACCEPTED znamená převzetí, ne doručení — ale všechny kontroly (dokument, příjemce v síti Peppol) proběhnou synchronně v rámci requestu. Vlastní auth endpointy s refresh tokenem; stejný access token funguje i na APEX API.

QHUB je asynchronní integrace přes RabbitMQ pro systémy v ekosystému ASOL a ERP s messaging vrstvou — viz Integrační příručku.

Rozhraní lze kombinovat: např. odesílání přes SAPI a sledování doručení přes /api/v1/documents/{id}/status nebo webhooky.
Peppol participant ID jednoznačně určuje účastníka sítě. Krátký tvar <ICD>:<hodnota> (např. 0245:2024000001) a kanonický tvar iso6523-actorid-upis::0245:2024000001 jsou v requestech zaměnitelné. Odpovědi v1 inboxu a notifikace používají kanonický tvar, v2 inbox a lookup krátký.

Slovensko: schéma 0245 (SK:DIČ) — slovenské DIČ má 10 číslic bez prefixu SK. Další běžná schémata: 9950 SK IČ DPH, 9929 CZ VAT, 9914 AT VAT, 9919 AT register, 9930 DE VAT, 9910 HU VAT, 0088 GLN, 0007 SE org. číslo, 0200 LT kód.

IČO (identifikační číslo organizace) není Peppol identifikátor; /participants/lookup/ico ho přes slovenský Registr účetních závěrek převede na DIČ.
QUEUED → PROCESSING → DELIVERED (→ případně FAILED po negativním MLS)
při chybě přenosu: PROCESSING → RETRYING → PROCESSING → … → DELIVERED nebo DEAD_LETTER

QUEUED — převzatý, čeká ve frontě • PROCESSING — probíhá AS4 přenos • DELIVERED — přijímající AP potvrdil přijetí (AS4 receipt) • RETRYING — čeká na další pokus • DEAD_LETTER — pokusy vyčerpány nebo trvalá chyba, je nutný zásah • FAILED — negativní Peppol MLS od přijímajícího AP • REJECTED — licence neplatná v době odesílání. Hodnota SENT je v číselníku, při odesílání se však nepoužívá.

Chybu validace, neznámého příjemce či cizího odesílatele API vrátí hned v odpovědi — takový dokument vůbec nevznikne.

DELIVERED znamená doručení do přístupového bodu příjemce (Peppol corner 3), ne zpracování v jeho ERP — to signalizují až aplikační odpovědi (IMR) a MLS.
APEX API: VALIDATED (validace prošla, čeká na stažení, notifikace DOCUMENTS_RECEIVED) → ACKNOWLEDGED (váš systém potvrdil). REJECTED = dokument neprošel validací (je v seznamu, notifikace nepřijde), FAILED = chyba zpracování. RECEIVED je jen vnitřní mezistav během příjmu.

SAPI: zjednodušený model RECEIVED (přijaté a zvalidované, čeká na potvrzení) → ACKNOWLEDGED; zamítnuté dokumenty SAPI nezobrazuje. Potvrzení je společné pro APEX API i SAPI.

Duplicitně doručenou AS4 zprávu APEX rozpozná a podruhé ji neuloží.

Technický stav převzetí (Peppol MLS, Message Level Status) posílá odesílajícímu poskytovateli APEX vaším jménem — negativní vždy, pozitivní, pokud o něj odesílatel požádal. Vy se staráte jen o obchodní odpověď (např. IMR), pokud ji váš proces vyžaduje.
1. XML Schema (XSD) — struktura podle UBL 2.1
2. EN 16931 Schematron — evropská norma e-fakturace (povinná pole, číselníky, výpočty)
3. Pravidla Peppol BIS — pravidla Peppol nad rámec EN 16931 (např. PEPPOL-EN16931-R*)

Validační sada se vybírá podle documentTypeId a cbc:CustomizationID: Peppol BIS Billing 3.0 (faktura, dobropis, samofakturace), národní varianty PINT, německá XRechnung, objednávky (Order, Order Response) a další Peppol BIS dokumenty. Při více verzích stejné sady se použije nejvyšší. Stejná validace běží v /validate, /precheck, /send, dávkách i SAPI.
MLS (Message Level Status, urn:peppol:edec:mls) — technický stav zprávy, který posílá přijímající přístupový bod odesílajícímu. APEX při odesílání žádá MLS pro každý dokument; pozitivní (AP/AB) → notifikace MLS_RECEIVED, negativní (RE) → dokument přejde na FAILED a přijde MLS_RECEIVED_NEGATIVE. Příjem MLS je v síti Peppol povinný od 28. 2. 2027 a odesílání od 31. 3. 2027 — do té doby ho některé přístupové body ještě nevracejí, chybějící MLS tedy není chyba.
MLR (Message Level Response, BIS 36a / T71) — starší aplikační odpověď přijetí/zamítnutí.
IMR (Invoice Response 3.0 / T111) — obchodní rozhodnutí odběratele o faktuře.
ORDER_RESPONSE (BIS 28a), RECEIPT_ADVICE (BIS 30a).

Kódy: AP přijato, RE zamítnuto, CA podmíněně přijato, UQ dotaz, IP ve zpracování. Všechny najdete přes GET /api/v1/documents/{id}/responses.
Přijatý dokument (APEX API ublDocument, SAPI payload) je celý StandardBusinessDocument — obálka SBDH (http://www.unece.org/cefact/namespaces/StandardBusinessDocumentHeader) s UBL dokumentem uvnitř, přesně jak přišel sítí. Business dokument hledejte podle jmenného prostoru (např. urn:oasis:names:specification:ubl:schema:xsd:Invoice-2), ne jako kořen.

Prefixy nejsou kontrakt. cac:, cbc: ani jiné prefixy se nemusí shodovat mezi verzemi ani v rámci jednoho dokumentu — používejte namespace-aware parser (XPath s registrovanými jmennými prostory, JAXB, XmlReader s NamespaceURI…).
POST /api/v1/documents/send — hlavička Idempotency-Key volitelná; klíč platí 24 h; porovnává se obsah (dokument a směrovací metadata).
POST /api/v1/batches — volitelná, doporučená; klíč neexpiruje; porovnávají se bajty těla (SHA-256).
POST /sapi/v1/document/send — povinná; klíč platí 24 h; porovnává se payload a metadata (odesílatel, příjemce, typ, proces).

Společná pravidla: stejný klíč + stejný request → původní odpověď (bez nového odeslání); stejný klíč + jiný request → 409 IDEMPOTENCY_CONFLICT; souběžně běžící request se stejným klíčem → 409 IDEMPOTENCY_IN_PROGRESS (zopakujte později). Odmítnutý request klíč nespotřebuje. Při timeoutu vždy opakujte se stejným klíčem.
Pokud AS4 přenos selže (síť, timeout, chyba přijímajícího AP), dokument přejde do RETRYING a worker ho zkusí znovu. Dokument má 5 pokusů; po 1. až 4. selhání přijde další pokus za 30, 60, 120 a 240 s, páté selhání znamená DEAD_LETTER — celkem zhruba 7,5 minuty plus čas přenosů (AS4 timeout je 120 s). Trvalé chyby (např. certifikát příjemce nevydaný CA OpenPeppol) jdou do DEAD_LETTER hned. Každý pokus vytvoří události QUEUE_PROCESSING_STARTED a při selhání QUEUE_PROCESSING_FAILED (Attempt n/5 failed, retry in …s: <příčina>). Dokument v DEAD_LETTER vyžaduje zásah — kontaktujte podporu s documentId; po nápravě ho může zařadit znovu (událost QUEUE_MANUAL_REQUEUE, bez notifikace).

APEX navíc chrání přijímající přístupové body: když cíl opakovaně selhává, odesílání na něj se na 30 s přeruší (circuit breaker) a dokumenty se přeplánují bez spotřebování pokusu. Tenanti se ve frontě střídají, takže jeden velký odesílatel nezablokuje ostatní.
SML (Service Metadata Locator) je DNS registr sítě Peppol: z Peppol ID určí, který SMP spravuje údaje účastníka.
SMP (Service Metadata Publisher) publikuje, jaké typy dokumentů a procesy účastník přijímá, URL jeho AS4 endpointu a certifikát přístupového bodu.

APEX výsledek lookupu příjemce ukládá a obnovuje po uplynutí TTL (výchozí 5 dní) nebo po neúspěšném přenosu. Uložený výsledek se nevztahuje ke konkrétnímu typu dokumentu — pokud příjemce mezitím změnil registraci, chyba se může projevit až při přenosu. Před odesláním APEX ověřuje, že certifikát přístupového bodu příjemce vydala CA OpenPeppol a je platný.
Verze je součástí cesty (/api/v1, /api/v2). Publikovaná verze se nikdy nemění zpětně nekompatibilně — nový formát vzniká pod novou verzí a předchozí funguje dál. Dnes má verzi v2 jen příjem (GET /api/v2/documents/inbox a detail) — liší se pouze krátkým tvarem identifikátorů. Všechny ostatní endpointy jsou jen ve v1. Klienti mají ignorovat neznámá pole v odpovědích a neznámé hodnoty eventType.
Nejčastější Peppol identifikátory typů dokumentů a procesů
DokumentdocumentTypeIdprocessId
Faktura (BIS Billing 3.0)urn:oasis:names:specification:ubl:schema:xsd:Invoice-2::Invoice##urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0::2.1urn:fdc:peppol.eu:2017:poacc:billing:01:1.0
Dobropis (BIS Billing 3.0)urn:oasis:names:specification:ubl:schema:xsd:CreditNote-2::CreditNote##urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0::2.1urn:fdc:peppol.eu:2017:poacc:billing:01:1.0
Samofaktura (Self-billing 3.0)urn:oasis:names:specification:ubl:schema:xsd:Invoice-2::Invoice##urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:selfbilling:3.0::2.1urn:fdc:peppol.eu:2017:poacc:selfbilling:01:1.0
Objednávka (BIS Order Only 3)urn:oasis:names:specification:ubl:schema:xsd:Order-2::Order##urn:fdc:peppol.eu:poacc:trns:order:3::2.1urn:fdc:peppol.eu:poacc:bis:order_only:3
Odpověď na objednávku (BIS Ordering 3)urn:oasis:names:specification:ubl:schema:xsd:OrderResponse-2::OrderResponse##urn:fdc:peppol.eu:poacc:trns:order_response:3::2.1urn:fdc:peppol.eu:poacc:bis:ordering:3
Odpověď na fakturu (IMR, Invoice Response 3)urn:oasis:names:specification:ubl:schema:xsd:ApplicationResponse-2::ApplicationResponse##urn:fdc:peppol.eu:poacc:trns:invoice_response:3::2.1urn:fdc:peppol.eu:poacc:bis:invoice_response:3
MLR (Message Level Response 3)urn:oasis:names:specification:ubl:schema:xsd:ApplicationResponse-2::ApplicationResponse##urn:fdc:peppol.eu:poacc:trns:mlr:3::2.1urn:fdc:peppol.eu:poacc:bis:mlr:3
MLS (Message Level Status) — posílá APEXurn:oasis:names:specification:ubl:schema:xsd:ApplicationResponse-2::ApplicationResponse##urn:peppol:edec:mls:1.0::2.1urn:peppol:edec:mls
Autentizace

OAuth 2.0 — Bearer token

Všechny endpointy kromě /sapi/v1/auth/token, /renew a /revoke vyžadují hlavičku Authorization: Bearer <access_token>. Access token je JWT podepsaný (RS256) serverem ASOL IAM a získáte ho grantem client_credentials (server-to-server, bez přihlášení uživatele) — přímo z IAM, nebo přes SAPI endpoint, který navíc vydá refresh token. Výsledný token je stejný a platí pro APEX API i SAPI.

Dva způsoby získání tokenu
A) Přímo z ASOL IAMB) Přes SAPI
EndpointPOST https://iam.qasida.sk/oauth2/tokenPOST /sapi/v1/auth/token
Formátapplication/x-www-form-urlencodedapplication/json
Access tokenJWT, platnost podle expires_instejný JWT z IAM
Refresh tokenne — nový token vždy přes client_credentialsano, 30 dní, rotace přes /sapi/v1/auth/renew
Doporučeno proAPEX API, Swagger UI (Authorize)SAPI integrace podle SAPI-SK v1.0

1. Token

client_credentials z IAM nebo /sapi/v1/auth/token

2. Použití

Authorization: Bearer <token> v každém requestu

3. Obnovení

před vypršením nový client_credentials nebo /renew

4. Revoke

/sapi/v1/auth/revoke pro refresh token

🔑Důležité: přístupové údaje (clientId, clientSecret) jsou vázané na jednu organizaci (tenanta) v APEX — token určuje, ke kterým dokumentům a účastníkům máte přístup. Access token obnovujte s rezervou (např. 1–3 min před expires_in), jeden token používejte pro všechny requesty po dobu jeho platnosti a při 401 si vyžádejte nový. APEX ověřuje token lokálně (podpis a platnost), revokace access tokenu ho proto před vypršením nezruší. Parametr scope není potřeba — přístup určuje tenant.
Příklad autentizace
Token request a použití
A) Token přímo z ASOL IAM
POST https://iam.qasida.sk/oauth2/token
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials
&client_id=your-client-id
&client_secret=your-client-secret

HTTP/1.1 200 OK
{
  "access_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...",
  "token_type": "Bearer",
  "expires_in": 900
}
B) Token přes SAPI (s refresh tokenem)
POST /sapi/v1/auth/token
Content-Type: application/json

{
  "client_id": "your-client-id",
  "client_secret": "your-client-secret",
  "grant_type": "client_credentials"
}

HTTP/1.1 200 OK
{
  "access_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...",
  "token_type": "Bearer",
  "expires_in": 900,
  "scope": null,
  "refresh_token": "eyJhbGciOiJIUzI1NiJ9..."
}
Obnovení přes SAPI
POST /sapi/v1/auth/renew
Content-Type: application/json

{ "refresh_token": "eyJhbGciOiJIUzI1NiJ9..." }
Použití tokenu
GET /api/v2/documents/inbox?status=VALIDATED
Authorization: Bearer eyJhbGciOiJSUzI1NiIs...
Accept: application/json
Chyby a limity

Chyby, limity a bezpečnost

Jak vypadají chybové odpovědi, které chyby má smysl opakovat, jaké limity platí a na co si dát pozor při návrhu klienta. Rozhodujte vždy podle HTTP kódu a strojového kódu chyby, ne podle textu zprávy.

APEX API — /api/**
Formát chyby
JSON objekt s poli timestamp, status, error, message a zpravidla path. Strojový code mají dávky a idempotence (INVALID_IDEMPOTENCY_KEY, IDEMPOTENCY_CONFLICT, IDEMPOTENCY_IN_PROGRESS, BATCH_*, PARTICIPANT_NOT_AUTHORIZED, LICENCE_INVALID, TOO_MANY_OPEN_BATCHES); u ostatních chyb je message jen informativní text. /documents/send při neúspěšné validaci vrací error: "Validation Error" s validationErrors[] a validationWarnings[] (code, message, location). Chyby frameworku (nečitelný JSON, špatný typ parametru, chybějící parametr, 405/415) mají formát Problem Details (type, title, status, detail, instance). 404 pro neexistující nebo cizí zdroj má prázdné tělo. timestamp je bez časové zóny (UTC).
{
  "timestamp": "2026-10-09T10:15:00.123",
  "status": 409,
  "error": "Conflict",
  "code": "IDEMPOTENCY_CONFLICT",
  "message": "Idempotency-Key 'FA2026-0001' was already used for a different request (document or routing metadata)",
  "path": "/api/v1/documents/send"
}
401 bez tokenu
{
  "timestamp": "2026-10-09T19:31:24.544",
  "status": 401,
  "error": "Unauthorized",
  "message": "Missing or malformed Authorization: Bearer header",
  "path": "/api/v1/documents/send"
}
SAPI — /sapi/**
Obálka chyby
Objekt error: category (AUTH, VALIDATION, PROCESSING, TEMPORARY), code (SAPI-…), message, details[] (nebo null), retryable a correlation_id (uveďte ho podpoře). Odmítnutí odeslání ho obaluje do status: REJECTED s errorCode. Odpovědi 415, 405, 406 a chybějící hlavička při příjmu mají formát Problem Details (RFC 9457); 404 u detailu a potvrzení má prázdné tělo.
{
  "error": {
    "category": "AUTH",
    "code": "SAPI-AUTH-002",
    "message": "Access token is invalid or has expired",
    "details": null,
    "retryable": false,
    "correlation_id": "c3d4e5f6-a7b8-9012-cdef-345678901234"
  }
}
HTTP kódy a co s nimi
HTTPVýznamCo udělat
200 / 201 / 202 / 204Úspěch; 202 = převzato k asynchronnímu zpracováníU 202 sledujte stav (/status, notifikace)
400Neplatný request nebo dokument. Zvláštní případ: Invalid UUID string: anonymousUser znamená token bez tenanta (např. token uživatele místo integračního klienta)Opravte request; neopakujte bez změny
401Chybějící, neplatný nebo expirovaný token (hlavička musí začínat přesně Bearer )Získejte nový token a request zopakujte jednou
403Účastník nepatří vašemu tenantovi, neplatná licence, tenant z tokenu není v APEX založen (Authenticated tenant not found)Zkontrolujte Peppol ID, licenci (/api/v1/licenses/info) a přístupové údaje
404Zdroj neexistuje nebo patří jinému tenantovi (záměrně nerozlišeno)Zkontrolujte ID a prostředí
409Konflikt idempotence, stav neumožňuje operaciIDEMPOTENCY_IN_PROGRESS zopakujte později; ostatní řešte
413Příliš velká dávkaRozdělte dávku
415Nesprávný Content-TypePosílejte application/json (ZIP dávka application/zip)
429Překročený rate limit nebo kapacita příjmu dávekPočkejte podle Retry-After, pak exponenciální odstup
500 / 503Neočekávaná nebo dočasná chybaOpakujte s exponenciálním odstupem a stejným Idempotency-Key
Rate limiting
EndpointyLimit
POST /sapi/v1/document/send100 requestů / min / IP (vlastní limit)
všechny ostatní /api/** a /sapi/** (včetně /sapi/v1/auth/*)200 requestů / min / IP (společný limit)
Limit se počítá pro zdrojovou IP adresu (token bucket s průběžným doplňováním — krátký nárazový burst je povolen, pak cca limit/60 za sekundu). Každá odpověď nese hlavičky X-RateLimit-Limit a X-RateLimit-Remaining; při 429 i Retry-After (sekundy do dalšího volného requestu). Rate limit se vyhodnocuje před autentizací, takže se počítají i neúspěšné requesty. Hromadné odesílání má navíc vlastní limity (3 otevřené dávky, BATCH_INTAKE_BUSY).
HTTP 429
Odpověď při překročení limitu
HTTP/1.1 429 Too Many Requests
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 0
Retry-After: 1

{
  "error": {
    "category": "TEMPORARY",
    "code": "SAPI-RATE-001",
    "message": "Rate limit exceeded. Maximum 100 requests per minute per IP address.",
    "retryable": true,
    "correlation_id": "f1a2b3c4-d5e6-7890-abcd-ef1234567890"
  }
}
U /api/** má tělo 429 tvar chyby APEX API: {"timestamp", "status": 429, "error": "Too Many Requests", "message", "path"}. Limity se uplatňují pro každou instanci služby samostatně — berte je jako horní orientační limit, ne jako garantovanou kapacitu.
Doporučení pro robustního klienta
Opakování a idempotence
Při 429, 500, 503 a timeoutu opakujte s exponenciálním odstupem (např. 2, 4, 8, 16 s + náhodný jitter). Odesílací requesty posílejte vždy s Idempotency-Key a při opakování se stejným klíčem — tak fakturu nikdy neodešlete dvakrát.
Tolerantní parsování
Ignorujte neznámá pole v JSON a neznámé hodnoty eventType či stavů — API se rozšiřuje zpětně kompatibilně. Časy parsujte jako ISO 8601 s posunem a porovnávejte okamžiky, ne řetězce (počet desetinných míst se liší). XML payload parsujte s ohledem na jmenné prostory.
Bezpečnost
Jen HTTPS. clientSecret, refresh token a MQTT heslo ukládejte v trezoru tajemství, ne v kódu ani v lozích. Webhooky nejsou podepsané — ověřujte je tajemstvím v customHeaders a obsah si vždy načtěte z API podle documentId. Notifikace berte jako signál, ne jako zdroj pravdy.
Příklady

Request / Response příklady

Konkrétní requesty a odpovědi pro klíčové scénáře. $APEX je základní URL prostředí (např. https://api.sandbox.apex.qasida.sk), $TOKEN access token. XML dokumenty jsou v příkladech zkrácené.

POST /api/v1/documents/send
Odeslání faktury
Request
curl -X POST "$APEX/api/v1/documents/send" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: FA2026-0001" \
  -d @faktura.json

{
  "senderParticipantId": "0245:2024000001",
  "receiverParticipantId": "0245:1234567890",
  "documentTypeId": "urn:oasis:names:specification:ubl:schema:xsd:Invoice-2::Invoice##urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0::2.1",
  "processId": "urn:fdc:peppol.eu:2017:poacc:billing:01:1.0",
  "ublDocument": "<?xml version=\"1.0\" encoding=\"UTF-8\"?><Invoice xmlns=\"urn:oasis:names:specification:ubl:schema:xsd:Invoice-2\" ...>...</Invoice>"
}
Response (HTTP 202)
{
  "documentId": "550e8400-e29b-41d4-a716-446655440000",
  "status": "QUEUED",
  "submittedAt": "2026-10-09T10:30:00"
}
Response (HTTP 400 — nevalidní dokument)
{
  "timestamp": "2026-10-09T10:30:00",
  "status": 400,
  "error": "Validation Error",
  "message": "Document validation failed: 1 error(s)",
  "validationErrors": [
    {
      "code": "BR-02",
      "message": "An Invoice shall have an Invoice number (BT-1).",
      "location": "/Invoice/cbc:ID"
    }
  ],
  "validationWarnings": []
}
POST /api/v1/documents/precheck
Precheck před odesláním
Response — připraveno k odeslání
{
  "networkReady": true,
  "valid": true,
  "participantExists": true,
  "canSend": true,
  "errors": [],
  "warnings": [
    {
      "category": "ROUTING",
      "code": "CERT_EXPIRING_SOON",
      "message": "Recipient AP certificate expires in 18 days (2026-10-27). Sending is still possible.",
      "location": null
    }
  ],
  "checkedAt": "2026-10-09T11:00:00+02:00"
}
Response — příjemce není v síti Peppol
{
  "networkReady": false,
  "valid": true,
  "participantExists": false,
  "canSend": false,
  "errors": [
    {
      "category": "PARTICIPANT",
      "code": "PARTICIPANT_NOT_FOUND",
      "message": "Participant '0245:9999999999' was not found in the Peppol network.",
      "location": null
    }
  ],
  "warnings": [],
  "checkedAt": "2026-10-09T11:00:00+02:00"
}
GET /api/v1/participants/lookup/dic?schema=0245&dic=2024000001
Vyhledání účastníka
Response
{
  "source": "SMP",
  "participantId": "iso6523-actorid-upis::0245:2024000001",
  "peppolId": "0245:2024000001",
  "organizationName": null,
  "countryCode": "SK",
  "endpointUrl": "https://ap.partner.example.com/as4/receive",
  "smpUrl": "https://smp.partner.example.com/",
  "enabled": true,
  "certificate": {
    "subject": "CN=PSK000202,OU=PEPPOL PRODUCTION AP,O=Partner SK s.r.o.,C=SK",
    "issuer": "CN=PEPPOL ACCESS POINT CA - G2,O=OpenPEPPOL AISBL,C=BE",
    "serial": "7f3a1b2c9d0e4f56",
    "fingerprint": "FF:EE:DD:CC:...:00",
    "notBefore": "2025-03-01T00:00:00Z",
    "notAfter": "2027-03-01T23:59:59Z",
    "expired": false,
    "valid": true,
    "invalidReason": null
  },
  "smpMetadataUpdatedAt": "2026-10-09T10:15:30Z"
}
GET /api/v1/documents/{documentId}/events
Historie dokumentu
Response (zkráceno)
[
  {
    "id": "d3a1e2f0-11aa-42bb-9c3d-000000000003",
    "messageId": "550e8400-e29b-41d4-a716-446655440000",
    "eventType": "MESSAGE_QUEUED",
    "eventCode": null,
    "eventMessage": "Document queued for async AS4 sending to https://receiver.example.com/as4",
    "technicalDetails": null,
    "stacktrace": null,
    "createdAt": "2026-10-09T10:30:01+02:00"
  },
  {
    "id": "d3a1e2f0-11aa-42bb-9c3d-000000000004",
    "messageId": "550e8400-e29b-41d4-a716-446655440000",
    "eventType": "QUEUE_PROCESSING_FAILED",
    "eventCode": null,
    "eventMessage": "Attempt 1/5 failed, retry in 30s: AS4 send returned failure",
    "technicalDetails": null,
    "stacktrace": null,
    "createdAt": "2026-10-09T10:30:04+02:00"
  },
  {
    "id": "d3a1e2f0-11aa-42bb-9c3d-000000000006",
    "messageId": "550e8400-e29b-41d4-a716-446655440000",
    "eventType": "MESSAGE_DELIVERED",
    "eventCode": null,
    "eventMessage": "Message delivered successfully",
    "technicalDetails": null,
    "stacktrace": null,
    "createdAt": "2026-10-09T10:30:40+02:00"
  }
]
POST /api/v1/subscriptions
Webhook a notifikace
Request
{
  "name": "ERP Invoice Inbox",
  "description": "Notifikace o nových fakturách",
  "url": "https://erp.example.com/webhooks/peppol",
  "active": true,
  "documentTypeFilters": [
    "urn:oasis:names:specification:ubl:schema:xsd:Invoice-2::Invoice##urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0::2.1"
  ],
  "senderParticipantFilters": [],
  "customHeaders": { "X-Webhook-Secret": "sdilene-tajemstvi" }
}
Notifikace, kterou APEX pošle na URL
POST https://erp.example.com/webhooks/peppol
Content-Type: application/json
User-Agent: Apex-Webhook/1.0
X-Webhook-Secret: sdilene-tajemstvi

{
  "eventType": "DOCUMENTS_RECEIVED",
  "subscriptionId": "f47ac10b-58cc-4372-a567-0e02b2c3d479",
  "documentId": "550e8400-e29b-41d4-a716-446655440001",
  "documentIds": ["550e8400-e29b-41d4-a716-446655440001"],
  "receivedCount": 1,
  "direction": "IN",
  "status": "VALIDATED",
  "messageId": "c3a1e7f2-5b9d-4d2e-8f41-2a6b9e0d7c15@sender-ap.example.com",
  "senderParticipantId": "iso6523-actorid-upis::0245:1234567890",
  "receiverParticipantId": "iso6523-actorid-upis::0245:2024000001",
  "documentTypeId": "urn:oasis:names:specification:ubl:schema:xsd:Invoice-2::Invoice##...::2.1",
  "processId": "urn:fdc:peppol.eu:2017:poacc:billing:01:1.0",
  "eventMessage": "Incoming Peppol document received",
  "notifiedAt": 1791282005.123456000
}
GET /api/v2/documents/inbox/{documentId}
Stažení přijaté faktury
Response
{
  "documentId": "550e8400-e29b-41d4-a716-446655440001",
  "senderParticipantId": "0245:1234567890",
  "receiverParticipantId": "0245:2024000001",
  "documentTypeId": "urn:oasis:names:specification:ubl:schema:xsd:Invoice-2::Invoice##...::2.1",
  "processId": "urn:fdc:peppol.eu:2017:poacc:billing:01:1.0",
  "receivedAt": "2026-10-09T09:15:00",
  "status": "VALIDATED",
  "ublDocument": "<StandardBusinessDocument xmlns=\"http://www.unece.org/cefact/namespaces/StandardBusinessDocumentHeader\"><StandardBusinessDocumentHeader>...</StandardBusinessDocumentHeader><Invoice xmlns=\"urn:oasis:names:specification:ubl:schema:xsd:Invoice-2\">...</Invoice></StandardBusinessDocument>"
}
Potvrzení po uložení v ERP
curl -X POST "$APEX/api/v1/documents/inbox/550e8400-e29b-41d4-a716-446655440001/acknowledged" \
  -H "Authorization: Bearer $TOKEN"

HTTP/1.1 204 No Content
POST /api/v1/batches
Hromadná dávka
Request (JSON)
curl -X POST "$APEX/api/v1/batches" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: ERP-run-2026-10-09-17" \
  -H "Expect: 100-continue" \
  --data-binary @davka.json

{
  "clientReference": "ERP-run-2026-10-09-17",
  "notify": "BATCH",
  "documents": [
    {
      "clientReference": "FA2026-0001",
      "senderParticipantId": "0245:2024000001",
      "receiverParticipantId": "0245:1234567890",
      "documentTypeId": "urn:oasis:names:specification:ubl:schema:xsd:Invoice-2::Invoice##...::2.1",
      "processId": "urn:fdc:peppol.eu:2017:poacc:billing:01:1.0",
      "ublDocument": "<Invoice xmlns=\"urn:oasis:names:specification:ubl:schema:xsd:Invoice-2\">...</Invoice>"
    }
  ]
}
Response (HTTP 202) a notifikace BATCH_PROCESSED
{
  "batchId": "6f1c2a9e-0b7d-4f3a-9c55-2b8e1f0d4a11",
  "clientReference": "ERP-run-2026-10-09-17",
  "status": "RECEIVED",
  "itemCount": 1000,
  "receivedAt": "2026-10-09T10:15:00Z"
}

{
  "eventType": "BATCH_PROCESSED",
  "subscriptionId": "f47ac10b-58cc-4372-a567-0e02b2c3d479",
  "eventMessage": "Batch processed: 990 accepted, 10 rejected, 0 cancelled",
  "notifiedAt": 1791281700.482913000,
  "batch": {
    "batchId": "6f1c2a9e-0b7d-4f3a-9c55-2b8e1f0d4a11",
    "clientReference": "ERP-run-2026-10-09-17",
    "status": "PROCESSED",
    "itemCount": 1000,
    "accepted": 990,
    "rejected": 10,
    "cancelled": 0
  }
}
POST /sapi/v1/document/send
SAPI odeslání
Request
POST /sapi/v1/document/send
Authorization: Bearer eyJhbGciOiJSUzI1NiIs...
Content-Type: application/json
Idempotency-Key: 3f6c1d2e-8a4b-4c5d-9e0f-112233445566
X-Peppol-Participant-Id: 0245:2024000001

{
  "metadata": {
    "documentId": "FA2026-0001",
    "documentTypeId": "urn:oasis:names:specification:ubl:schema:xsd:Invoice-2::Invoice##urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0::2.1",
    "processId": "urn:fdc:peppol.eu:2017:poacc:billing:01:1.0",
    "senderParticipantId": "0245:2024000001",
    "receiverParticipantId": "0245:1234567890",
    "creationDateTime": "2026-10-09T10:30:00Z"
  },
  "payload": "<?xml version=\"1.0\" encoding=\"UTF-8\"?><Invoice xmlns=\"urn:oasis:names:specification:ubl:schema:xsd:Invoice-2\" ...>...</Invoice>",
  "payloadFormat": "XML",
  "payloadEncoding": "UTF-8",
  "checksum": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"
}
Response (HTTP 200)
{
  "providerDocumentId": "7c9d0e1f-2a3b-4c5d-8e6f-0a1b2c3d4e5f",
  "status": "ACCEPTED",
  "receivedAt": "2026-10-09T08:30:05.123456Z",
  "timestamp": "2026-10-09T08:30:05.130Z"
}
Response (HTTP 400 — příjemce není v síti Peppol)
{
  "status": "REJECTED",
  "timestamp": "2026-10-09T08:30:05Z",
  "errorCode": "RECEIVER_NOT_FOUND",
  "errorMessage": "The receiver is not registered in the Peppol network for this document type (The SML has no SMP address for the participant)",
  "error": {
    "category": "VALIDATION",
    "code": "SAPI-VAL-021",
    "message": "The receiver is not registered in the Peppol network for this document type (The SML has no SMP address for the participant)",
    "details": null,
    "retryable": false,
    "correlation_id": "e5f6a7b8-c9d0-1234-ef01-567890123456"
  }
}