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

APEX AP Developer Portal — kompletná dokumentácia API a SAPI endpointov.

Technická referencia všetkých 37 operácií APEX Access Pointu: APEX API pre hlbokú integráciu (odosielanie aj hromadné, príjem, validácia, precheck, udalosti, odpovede, webhooky a MQTT, participanti, reporting, licencia) a SAPI pre zjednodušený prístup podľa slovenskej špecifikácie SAPI-SK v1.0. Overené voči zdrojovému kódu APEX 26.4.

APEX API
Odosielanie, príjem, dávky
Asynchrónne odosielanie s idempotenciou, hromadné dávky do 5 000 dokumentov, inbox v1/v2, stav, udalosti a odpovede.
SAPI
SAPI-SK v1.0
Odoslať, prijať, potvrdiť — s vlastnou autentifikáciou, refresh tokenom a synchrónnymi kontrolami dokumentu aj príjemcu.
Participanti
Lookup DIČ / IČO
Vyhľadanie partnera v Peppol (SML/SMP) vrátane AS4 endpointu a overenia certifikátu.
Notifikácie & reporting
Webhooky, MQTT, štatistiky
Push notifikácie o prijatých a odoslaných dokumentoch, štatistiky prevádzky, EUSR/TSR a licencia.
Navigácia portálom
Štruktúra dokumentácie
Dokumentácia zodpovedá verzii APEX 26.4 (október 2026). Záväzným strojovo čitateľným kontraktom je OpenAPI v Swagger UI — /api-docs/api a /api-docs/sapi.
Integračné cesty

Dve cesty, ako sa napojiť na APEX

APEX Access Point ponúka dva rovnocenné spôsoby integrácie. Výber závisí od toho, kde beží váš systém a aký štýl komunikácie potrebujete. Obe cesty pokrývajú plný Peppol tok (odosielanie aj prijímanie) a môžete ich aj kombinovať.

A
Cesta A — priama REST integrácia

APEX REST API a SAPI

REST OAuth 2.0 JSON UBL 2.1 Webhooky / MQTT
👤 Pre koho
Vývojári ERP, účtovných systémov, e-shopov a portálov, ktorí si chcú postaviť vlastného klienta a mať plnú kontrolu nad tokom.
⚙️ Ako to funguje
HTTPS volania na APEX s OAuth 2.0 Bearer tokenom (client_credentials). JSON telo, UBL dokument ako XML text. Odosielanie je asynchrónne (202 / ACCEPTED), stav sledujete pollingom, webhookmi alebo MQTT.
✅ Prečo si vybrať túto cestu
  • Žiadna dodatočná infraštruktúra — stačí HTTPS klient
  • Okamžitá spätná väzba: validácia dokumentu a overenie príjemcu ešte v rámci requestu
  • Idempotentné odosielanie a hromadné dávky do 5 000 dokumentov
  • Jednoduché testovanie cez Swagger UI, Postman alebo curl na sandboxe
Otvoriť API Reference →
B
Cesta B — managed messaging

QHUB (RabbitMQ message bus)

AMQPS RabbitMQ async DLQ Audit
👤 Pre koho
ERP a portály v ekosystéme ASOL (napr. QASIDA ERP, HOREC) a systémy tretích strán, ktoré už používajú messaging (RabbitMQ / AMQP 0-9-1) a chcú asynchrónnu integráciu bez priameho volania APEX.
⚙️ Ako to funguje
AMQPS pripojenie na RabbitMQ broker QHUB. Dokumenty na odoslanie publikujete ako SynchronizationMessage s entitou PeppolDocument (30); prijaté dokumenty aj výsledky vašich odoslaní (PeppolDocumentEvent, 32) prichádzajú do vašej delivery queue. Registráciu a prístupové údaje zriaďuje ASOL alebo váš partner.
✅ Prečo si vybrať túto cestu
  • Asynchrónny tok — váš systém nemusí byť dostupný non-stop, správy čakajú vo vašej queue
  • Výsledok každého odoslania ako udalosť (zaradené, doručené, zamietnuté, dead letter, MLS)
  • Jedna integračná vrstva pre viac produktov ASOL, zákazníkov aj prevádzok (routing podľa tenanta a prevádzky)
  • Audit každej správy v transakčnej tabuľke QHUB
Otvoriť Integračnú príručku →
💡
Tip: Obe cesty môžete skombinovať. Napríklad: odosielanie cez REST API (s okamžitou validáciou z UI akcie) a prijímanie cez QHUB (asynchrónne, z vašej queue).
Prostredia

Prostredia, URL a prístupové údaje

Integráciu vyvíjajte a testujte na sandboxe, do produkcie prejdete výmenou URL a prístupových údajov. Obe prostredia majú rovnaké API, rovnakú autentifikáciu a rovnaké limity.

Testovanie
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
Sieť Peppol
nie — dokumenty sa doručujú lokálne medzi účastníkmi sandboxu
🧪Sandbox nič neposiela do siete Peppol. Odoslaný dokument APEX doručí lokálne príjemcovi, ktorý musí byť participantom tenanta v tom istom sandboxe s platnou licenciou (aj vášho vlastného): príde mu do inboxu s notifikáciou DOCUMENTS_RECEIVED a odosielateľ následne dostane MLS. Namiesto AS4 udalostí uvidíte LOOPBACK_DETECTED a LOOPBACK_PROCESSING_COMPLETED. SML/SMP sa nevolá: lookup pozná len participantov sandboxu a precheck hlási príjemcu vždy ako dostupného. SAPI neznámeho príjemcu odmietne hneď (RECEIVER_NOT_FOUND); APEX API a dávky ho prijmú a dokument po vyčerpaní pokusov (cca 7,5 min) skončí v DEAD_LETTER.
Ostrá prevádzka
Produkcia
API (base URL)
dostanete pri onboardingu spolu s prístupovými údajmi
Swagger UI / OpenAPI
/swagger-ui, /api-docs/api, /api-docs/sapi
Token (ASOL IAM)
/oauth2/token servera ASOL IAM uvedeného v prístupových údajoch
Sieť Peppol
áno — produkčná sieť OpenPeppol (AS4, SML/SMP)
🔐Produkčné prístupové údaje vydáva ASOL (alebo váš partner) po podpise zmluvy. Sú viazané na vašu organizáciu (tenanta) a jej Peppol participantov, ktorých ASOL zaregistruje v SMP — odosielať môžete len za týchto participantov a pri platnej licencii. Sandbox a produkcia majú oddelené dáta aj prístupové údaje.
Prístupové údaje
Integračný klient v ASOL IAM (clientId + clientSecret), viazaný na jednu organizáciu (tenanta). Sandbox prístup obsahuje aj testovacieho participanta 0245:<DIČ> a sandbox licenciu; vyžiadate si ho cez ASOL alebo svojho partnera.
OpenAPI a Swagger UI
Každé prostredie publikuje dva OpenAPI dokumenty — /api-docs/api (APEX API) a /api-docs/sapi (SAPI) — a Swagger UI na /swagger-ui s tlačidlom Authorize (OAuth 2.0 client_credentials). Z OpenAPI si môžete vygenerovať klienta (OpenAPI Generator, NSwag, Kiota…).
Súvisiace služby
Integračná príručka QHUB — asynchrónna integrácia cez RabbitMQ.
Zákaznícky portál — aktivácia služby, licencie a podpora.
Hromadné odosielanie, MQTT a webhooky sú súčasťou APEX API — nič ďalšie netreba inštalovať.
Overview

Pre koho je táto dokumentácia

APEX AP poskytuje dve API skupiny: APEX API (/api/v1, /api/v2) pre hlbokú integráciu a APEX SAPI (/sapi/v1) pre zjednodušené rozhranie podľa špecifikácie SAPI-SK v1.0. Obe bežia na tom istom serveri a zdieľajú dáta aj tokeny.

Integrátor ERP
Potrebuje autentifikáciu, overenie príjemcu, validáciu, odoslanie faktúry a sledovanie doručenia, prípadne hromadné dávky a príjem dokladov.
Kľúčové sekcie: Quickstart, Odosielanie, Príjem, Hromadné odosielanie, Participanti.
Backend vývojár
Rieši OAuth 2.0 tok, idempotenciu, retry stratégiu, webhooky a MQTT, parsovanie SBDH payloadu a chybové kódy.
Kľúčové sekcie: Autentifikácia, Webhooky & MQTT, Chyby a limity, SAPI.
Support / prevádzka
Rýchlo zisťuje stav dokumentu, číta udalosti a odpovede protistrany, sleduje dávky, štatistiky a čerpanie licencie.
Kľúčové sekcie: Events, Responses, Batches, Reporting & licencia.
Quickstart

Prvá integrácia v 4 krokoch

Technická cesta od prvého requestu po odoslanie a prijatie faktúry cez APEX API. Všetky kroky si vyskúšate na sandboxe.

01
Token
Z ASOL IAM získajte access token grantom client_credentials (platnosť podľa expires_in) a posielajte ho v hlavičke Authorization: Bearer <token>. Pred vypršaním si vyžiadajte nový.
Výsledok: prístup k /api/** aj /sapi/**.
02
Odošlite
POST /api/v1/documents/send s hlavičkou Idempotency-Key (napr. číslo faktúry). Príjemcu určuje receiverParticipantId (slovenské firmy 0245:DIČ). Odpoveď 202 so stavom QUEUED a documentId. Pri timeoute opakujte s tým istým kľúčom.
Výsledok: dokument vo fronte na AS4 prenos.
03
Sledujte doručenie
Zaregistrujte webhook (POST /api/v1/subscriptions) alebo MQTT, prípadne pollujte GET /api/v1/documents/{id}/status. Históriu ukáže /events, odpovede protistrany /responses.
Výsledok: DELIVERED, alebo jasný dôvod chyby.
04
Prijímajte
Na notifikáciu DOCUMENTS_RECEIVED alebo pravidelne volajte GET /api/v2/documents/inbox?status=VALIDATED, stiahnite detail a po uložení potvrďte POST /api/v1/documents/inbox/{id}/acknowledged.
Výsledok: faktúra dodávateľa vo vašom ERP.
💡
Voliteľne pred odoslaním — na odoslanie nie sú potrebné, hodia sa najmä počas vývoja:
  • Overenie príjemcu: GET /api/v1/participants/lookup/dic?schema=0245&dic=2024000001 (alebo /lookup/ico?ico=…) zistí, či je odberateľ v sieti Peppol a či má použiteľný certifikát.
  • Precheck: POST /api/v1/documents/precheck s rovnakým telom ako send overí dokument (XSD, EN 16931, Peppol BIS), existenciu príjemcu aj podporu typu dokumentu bez odoslania — výsledkom je networkReady: true alebo zoznam chýb.
Reference

REST API Reference

Všetky endpointy APEX API a SAPI: účel, kedy ich volať, vstupy, výstupy, správanie a typické chyby. Cesty sú relatívne k základnej URL prostredia (napr. https://api.sandbox.apex.qasida.sk); každý request okrem /sapi/v1/auth/token, /renew a /revoke vyžaduje Bearer token.

Odoslanie jedného dokumentu do siete Peppol a sledovanie jeho osudu. Odosielanie je asynchrónne: POST /send dokument skontroluje, uloží a zaradí do frontu, AS4 prenos prebehne na pozadí. Stav čítajte cez /status, históriu cez /events a odpovede protistrany cez /responses — alebo si nechajte posielať notifikácie (záložka Webhooky & MQTT).

POST v1 outbound

/api/v1/documents/send

Skontroluje dokument a príjemcu, uloží payload a zaradí dokument do frontu na AS4 odoslanie. Odpoveď 202 Accepted so stavom QUEUED.
Účel služby
Prevezme jeden UBL dokument (faktúra, dobropis, objednávka…) a zaradí ho do odosielacieho frontu. Ešte pred odpoveďou prebehne validácia (XSD, EN 16931 Schematron, Peppol BIS pravidlá), vyhľadanie príjemcu cez SML/SMP a uloženie payloadu. Samotný AS4 prenos robí worker na pozadí. 202 znamená prevzatie, nie doručenie.
Kedy službu volať
  • pri odoslaní jednotlivej faktúry z ERP (akcia používateľa alebo plánovaný job)
  • po úspešnom /precheck, ak chcete chyby zachytiť ešte pred odoslaním
  • pre desiatky až tisíce dokumentov naraz radšej použite POST /api/v1/batches
Idempotencia — hlavička Idempotency-Key
Voliteľná, odporúčaná. Najviac 200 znakov, unikátna pre dokument (napr. číslo faktúry). Ten istý kľúč s rovnakým obsahom do 24 hodín vráti pôvodnú odpoveď 202 (pôvodné documentId a submittedAt, status vždy QUEUED) s hlavičkou Idempotent-Replayed: true a nič nové nezaradí — opakovanie po timeoute tak faktúru nikdy neodošle dvakrát. Kľúče sú oddelené pre každého tenanta; krátky a kanonický tvar participanta sa považujú za rovnaký obsah. Rovnaký kľúč s iným obsahom (dokument alebo metadáta) → 409 IDEMPOTENCY_CONFLICT; súbežný request s tým istým kľúčom → 409 IDEMPOTENCY_IN_PROGRESS. Odmietnutý request (400/403/500) kľúč nespotrebuje.
Životný cyklus po odoslaní
QUEUED → PROCESSING → DELIVERED. Ak pokus o AS4 prenos zlyhá, dokument prejde do RETRYING a ďalší pokus príde o 30, 60, 120 a 240 s; piate zlyhanie (alebo trvalá chyba, napr. certifikát príjemcu nevydaný CA OpenPeppol) → DEAD_LETTER, spravidla do 8 minút. Negatívny Peppol MLS od prijímajúceho AP prepne dokument na FAILED — aj keď už bol DELIVERED. Licencia neplatná v čase odosielania → REJECTED.
Typické chyby
  • 400 — chýbajúce pole (napr. Receiver participant ID is required), zlyhaná validácia dokumentu alebo nezhoda strán (telo s validationErrors[])
  • 401 — chýbajúci alebo neplatný Bearer token
  • 403 — odosielateľ chýba, nie je registrovaný alebo nepatrí vášmu tenantovi; neplatná licencia
  • 409 — IDEMPOTENCY_CONFLICT / IDEMPOTENCY_IN_PROGRESS
  • 500 — dokument sa nepodarilo zaradiť (Failed to queue document: …); sem patrí aj príjemca, ktorý nie je v Peppol alebo neprijíma daný typ dokumentu — preto ho overte cez /precheck alebo lookup
Payload a strany
ublDocument je XML text (nie Base64) — holý UBL dokument alebo UBL v obálke SBDH; úvodný UTF-8 BOM APEX odstráni. Typ a proces musia zodpovedať obsahu (cbc:CustomizationID, cbc:ProfileID). Odosielateľ a príjemca musia sedieť s cbc:EndpointID strán dokladu: dodávateľ → odberateľ; samofaktúru posiela odberateľ a objednávku kupujúci. Nezhoda vráti SENDER_SUPPLIER_MISMATCH / RECEIVER_CUSTOMER_MISMATCH (resp. SENDER_CUSTOMER_MISMATCH / RECEIVER_SUPPLIER_MISMATCH). Schematron sa pri dokumentoch nad 5 MB preskočí.
Vstupné polia (JSON)
Názov
Popis
Stav
senderParticipantId
Peppol ID odosielateľa, krátky (0245:2024000001) alebo kanonický tvar (iso6523-actorid-upis::0245:2024000001)
povinné
receiverParticipantId
Peppol ID príjemcu; musí byť registrovaný v Peppol (SML/SMP)
povinné
documentTypeId
Peppol identifikátor typu dokumentu (príloha v záložke Kľúčové pojmy)
povinné
processId
Peppol identifikátor procesu, napr. urn:fdc:peppol.eu:2017:poacc:billing:01:1.0
povinné
ublDocument
UBL dokument ako XML reťazec
povinné
Idempotency-Key
HTTP hlavička, 1–200 znakov
voliteľné
Výstupné polia (202)
Názov
Popis
documentId
UUID dokumentu v APEX — kľúč pre /status, /events, /responses a notifikácie
status
QUEUED
submittedAt
Čas prevzatia (ISO 8601)
GET v1 outbound

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

Aktuálny stav odoslaného dokumentu. Vždy vracia aktuálny stav — použite ho na polling a vždy, keď notifikácia vyzerá mimo poradia.
Účel služby
Vráti stav dokumentu odoslaného cez /send, dávku alebo SAPI (SAPI providerDocumentId je ten istý UUID). Notifikácie nemajú zaručené poradie, preto je tento endpoint autoritatívnym zdrojom stavu.
Kedy službu volať
  • pri polling modeli po odoslaní (rozumný interval: sekundy až desiatky sekúnd)
  • po notifikácii, ktorá vyzerá staršia ako posledný známy stav
  • pri zobrazení stavu v zozname dokumentov v ERP
Hodnoty status
QUEUED — čaká vo fronte
PROCESSING — worker práve odosiela cez AS4
DELIVERED — prijímajúci AP potvrdil prijatie (AS4 receipt)
RETRYING — pokus zlyhal, ďalší je naplánovaný
DEAD_LETTER — pokusy vyčerpané alebo trvalá chyba; treba zásah (podpora ho po náprave môže zaradiť znova)
FAILED — prijímajúci AP vrátil negatívny MLS (môže nasledovať aj po DELIVERED)
REJECTED — odmietnuté pred odoslaním, licencia neplatná v čase odosielania
SENT — súčasť číselníka, pri odosielaní sa nepoužíva

Dokument sa môže dočasne vrátiť z PROCESSING do QUEUED (napr. pri prerušení odosielania na nedostupný cieľ) bez notifikácie a bez spotrebovania pokusu.
Typické chyby
  • 404 (prázdne telo) — dokument neexistuje, nepatrí vášmu tenantovi alebo ide o prijatý dokument (stav je len pre odoslané)
  • 401 — neplatný token
Parametre
Názov
Popis
Stav
documentId
UUID z odpovede /send (path)
povinné
Výstupné polia
Názov
Popis
documentId
UUID dokumentu
status
Aktuálny stav (hodnoty vľavo)
submittedAt
Čas pôvodného prevzatia
POST v1 validácia

/api/v1/documents/validate

Validácia UBL dokumentu bez odoslania: XML Schema → EN 16931 Schematron → Peppol BIS 3.0 pravidlá. Vždy 200 — výsledok je v poli valid.
Účel služby
Overí syntaktickú a pravidlovú správnosť dokumentu skôr, než ho pošlete. /send robí tú istú validáciu (navyše kontroluje strany, licenciu a príjemcu). Ak documentTypeId nezadáte, odvodí sa z koreňového elementu: CreditNote → BIS 3.0 dobropis, inak BIS 3.0 faktúra. Podporované sú faktúry a dobropisy BIS Billing 3.0 (vrátane samofakturácie, PINT a XRechnung), objednávky, odpovede na objednávky, dodacie listy, katalógy, MLR, IMR a MLS; pre neznámy typ vráti chybu SCHEMATRON_001.
Kedy službu volať
  • pri vývoji a ladení XML šablón faktúr
  • pri generovaní dokumentu ešte pred uložením v ERP
  • pri migrácii alebo importe dávok dokladov
Výsledok
valid je true, len ak prejdú všetky tri vrstvy; po vrstvách schemaValid, schematronValid, businessRulesValid. Každá chyba má level (ERROR/WARNING/INFO), code (napr. BR-07, PEPPOL-EN16931-R004), message a location (XPath). Pri úspešnom parsovaní vráti aj metadáta dokladu.
Typické chyby
  • 400 — chýba telo alebo ublDocument je prázdny
  • 415 — telo nie je application/json
  • nevalidný dokument nie je HTTP chyba: 200 s valid: false
Vstupné polia
Názov
Popis
Stav
ublDocument
UBL dokument ako XML reťazec
povinné
documentTypeId
Peppol typ dokumentu; predvolene BIS 3.0 Invoice
voliteľné
Výstupné polia
Názov
Popis
valid
Celkový výsledok
schemaValid / schematronValid / businessRulesValid
Výsledok po vrstvách
errors[] / warnings[]
level, code, message, location
documentType, documentId, issueDate
Typ dokladu, jeho číslo, dátum vystavenia
supplierName, customerName
Dodávateľ a odberateľ
totalAmount, currencyCode
Suma (reťazec) a mena
POST v1 validácia

/api/v1/documents/precheck

Všetky kontroly, ktoré by urobil /send, ale bez uloženia a zaradenia: validácia dokumentu, existencia príjemcu v Peppol a podpora typu dokumentu. Výsledok networkReady.
Tri kontroly v poradí
1. Dokument → valid (XSD, EN 16931, Peppol BIS)
2. Príjemca existuje → participantExists (SML/DNS nájde SMP)
3. Smerovanie → canSend (SMP príjemcu ponúka documentTypeId + processId, AS4 endpoint a platný certifikát)

networkReady = valid && participantExists && canSend
Kedy službu volať
  • za tlačidlom „Skontrolovať“ pred odoslaním faktúry
  • pri onboardingu nového obchodného partnera
  • pri hromadnom spracovaní na odfiltrovanie problémových dokladov
Kategórie chýb a varovania
VALIDATION — chyba dokumentu alebo nezhoda strán (kód pravidla, XPath)
PARTICIPANT — príjemcu sa nepodarilo nájsť v Peppol (PARTICIPANT_NOT_FOUND; hlási sa aj pri dočasnej nedostupnosti SML/SMP)
ROUTING — príjemca nepodporuje typ/proces (DOCTYPE_NOT_SUPPORTED)

Varovania neblokujú odoslanie, napr. CERT_EXPIRING_SOON (certifikát príjemcu vyprší do 30 dní).
Výkon, cache a chyby
  • kroky 2–3 používajú SMP údaje príjemcu, ktoré APEX uchováva až 5 dní (bez ohľadu na typ dokumentu); pri ich obnove počítajte s +200–800 ms — príjemca, ktorý medzitým zmenil registráciu, môže zlyhať až pri odoslaní
  • v sandboxe sa SML/SMP nevolá: participantExists a canSend sú vždy true
  • 200 sa vracia vždy, aj keď kontroly neprejdú; licenciu precheck nekontroluje
  • 400 — chýba povinné pole; 403 — chýbajúci alebo cudzí odosielateľ
Vstupné polia
Názov
Popis
Stav
senderParticipantId, receiverParticipantId, documentTypeId, processId, ublDocument
Rovnaké telo ako /send
povinné
Výstupné polia
Názov
Popis
networkReady
Dokument možno odoslať
valid / participantExists / canSend
Výsledok troch kontrol
errors[] / warnings[]
category, code, message, location (pri PARTICIPANT/ROUTING null)
checkedAt
Čas kontroly
GET v1 audit

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

Kompletná chronologická história udalostí dokumentu (odoslaného aj prijatého), najstaršie prvé.
Účel služby
Zaznamenaná história spracovania: vznik, validácia, zaradenie, pokusy o odoslanie, doručenie, MLS, ukladanie, väzby na odpovede a hlásenia SK TDD (C5). Na rozdiel od notifikácií je zoradená podľa createdAt.
Kedy službu volať
  • pri riešení reklamácie doručenia (časová os)
  • pri analýze opakovaných pokusov: páry QUEUE_PROCESSING_STARTED / QUEUE_PROCESSING_FAILED
  • pri audite prijatého dokladu (MESSAGE_RECEIVED → MESSAGE_VALIDATED → MESSAGE_ACKNOWLEDGED)
Kategórie eventType
Lifecycle — MESSAGE_CREATED, _RECEIVED, _VALIDATED, _DELIVERED, _FAILED, _ACKNOWLEDGED
Validácia — VALIDATION_SUCCESS, VALIDATION_SCHEMA_ERROR, VALIDATION_ERROR
Front — 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 (príjemca v tom istom APEX; v sandboxe vždy)
Úložisko — BLOB_STORAGE_INITIATED/_COMPLETED/_FAILED
Odpovede — 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_*
Iné — DUPLICATE_DETECTED, PROCESSING_ERROR, TRANSPORT_ERROR

Neznáme hodnoty (aj zo starších verzií) berte ako informatívne.
Typické chyby
  • 404 — dokument neexistuje
  • prázdne pole [] — zatiaľ bez udalostí
Parametre
Názov
Popis
Stav
documentId
UUID odoslaného alebo prijatého dokumentu (path)
povinné
Výstupné polia (každá udalosť)
Názov
Popis
id
UUID udalosti
messageId
documentId dokumentu, ku ktorému udalosť patrí
eventType
Kategória (vľavo)
eventCode
Kód chyby alebo protokolu (napr. EBMS-0010, BR-07)
eventMessage
Čitateľný popis (neparsujte ho)
technicalDetails
Endpoint, HTTP status, výňatok odpovede SMP…
stacktrace
Len pri neočakávaných chybách, inak null
createdAt
Čas udalosti (ISO 8601 s posunom)
GET v1 odpovede

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

Aplikačné odpovede vymenené k dokumentu (MLR, IMR, Order Response, Receipt Advice a Peppol MLS), najstaršie prvé.
Oba smery
Pre dokument, ktorý ste odoslali: odpovede protistrany vrátane Message Level Status (MLS) od prijímajúceho poskytovateľa. Pre dokument, ktorý ste prijali: odpovede, ktoré ste poslali vy, vrátane MLS, ktorý APEX vrátil vo vašom mene. Ako odpoveď dokumentu sa hlási len prvý platný MLS od zúčastneného poskytovateľa (pravidlo Peppol OP-MLS-02); ostatné sa iba auditujú.
Typy a kódy
MLR (BIS 36a / T71; v tomto type sa vracia aj Peppol MLS, rozlíšite ho podľa documentTypeId …urn:peppol:edec:mls…), IMR (Invoice Response 3.0 / T111), ORDER_RESPONSE (BIS 28a), RECEIPT_ADVICE (BIS 30a)
Kódy: AP prijaté, AB prijaté bez potvrdenia (MLS), RE zamietnuté, CA podmienečne prijaté, UQ otázka, IP v spracovaní, PD zaplatené (IMR)
Issues
Pri RE a CA obsahuje issues[] jednotlivé dôvody z odpovede: type (kód dôvodu, spravidla BV biznis / SV syntax), code, description, severity (FATAL pri RE, inak WARNING) a xpath (spravidla null). AP s prázdnym zoznamom = čisté prijatie.
Návratové hodnoty
  • [] — zatiaľ bez odpovede (bežné hneď po odoslaní)
  • [] — aj keď documentId je sám odpoveďou
  • 404 — dokument nie je váš alebo neexistuje
Parametre
Názov
Popis
Stav
documentId
UUID odoslaného alebo prijatého dokumentu (path)
povinné
Výstupné polia (každá odpoveď)
Názov
Popis
responseId
UUID odpovede (pre stiahnutie XML)
responseType
MLR, IMR, ORDER_RESPONSE, RECEIPT_ADVICE
responseCode / responseCodeDescription
AP/RE/CA/UQ/IP a jeho popis
documentTypeId
Typ dokumentu odpovede z AS4 hlavičky
senderParticipantId
Kto odpoveď poslal
note
Voľný text odpovede (napr. dôvod zamietnutia)
issues[]
Zoznam problémov (vľavo)
receivedAt
Čas prijatia odpovede cez AS4
GET v1 odpovede

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

Surové XML jednej odpovede (UBL ApplicationResponse), Content-Type: application/xml.
Účel služby
Stiahne XML odpovede zo zoznamu /responses — obchodnej odpovede protistrany (IMR/MLR), odpovede, ktorú ste poslali vy, alebo MLR, ktoré APEX vygeneroval a poslal AP odosielateľa (C2).
Typické chyby
  • 404 — responseId nepatrí k danému dokumentu (aj keď sú obe ID rovnaké)

Dokumenty, ktoré vám prišli zo siete Peppol cez AS4. Pull model: zoznam → detail → potvrdenie. O novom dokumente sa dozviete pollingom zoznamu alebo notifikáciou DOCUMENTS_RECEIVED (webhook / MQTT). Endpointy existujú vo verzii v1 (identifikátory v kanonickom tvare iso6523-actorid-upis::0245:…) a v2 (krátke Peppol ID 0245:…). Pre nové integrácie odporúčame v2; potvrdenie existuje len vo v1.

GET v2 inbound

/api/v2/documents/inbox

Stránkovaný zoznam prijatých dokumentov, najnovšie prvé (receivedAt DESC). Odosielateľ a príjemca v krátkom tvare 0245:2024000001.
Účel služby
Integračná plocha pre ERP, ktoré si prijaté doklady sťahuje pull modelom. Zoznam neobsahuje XML (ublDocument je prázdne) — obsah získate z detailu. Čítanie zoznamu nemení stav dokumentov.
Typický polling
  • pravidelne volajte so status=VALIDATED — to sú dokumenty, ktoré čakajú na stiahnutie
  • každý nový dokument stiahnite cez GET /api/v2/documents/inbox/{documentId}
  • po trvalom uložení v ERP zavolajte POST /api/v1/documents/inbox/{documentId}/acknowledged — z ďalšieho pollingu vypadne
Stavy prijatého dokumentu
VALIDATED — dokument prešiel validáciou a čaká na stiahnutie (posiela sa DOCUMENTS_RECEIVED)
ACKNOWLEDGED — váš systém potvrdil prevzatie
REJECTED — dokument neprešiel validáciou (je v zozname, ale bez notifikácie)
FAILED — chyba pri spracovaní
RECEIVED — len vnútorný medzistav počas príjmu, v zozname ho neuvidíte
Stránkovanie a filter
offset / limit (predvolene 0 / 20; odporúčame najviac 100); odpoveď nesie total — počet záznamov zodpovedajúcich filtru. status rozlišuje veľké a malé písmená; neznáma hodnota vráti 400.
Query parametre
Názov
Popis
Stav
status
VALIDATED, ACKNOWLEDGED, REJECTED, FAILED
voliteľné
offset
Počet preskočených záznamov (predvolene 0)
voliteľné
limit
Veľkosť stránky (predvolene 20)
voliteľné
Výstupné polia
Názov
Popis
items[]
documentId, senderParticipantId, receiverParticipantId, documentTypeId, processId, receivedAt, status
total
Počet dokumentov zodpovedajúcich filtru
offset, limit
Použité hodnoty stránkovania
GET v2 inbound

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

Detail prijatého dokumentu vrátane celého payloadu — StandardBusinessDocument (SBDH obálka s UBL dokumentom vnútri).
Payload
Pole ublDocument obsahuje kompletný StandardBusinessDocument tak, ako prišiel sieťou Peppol — koreňom je obálka SBDH, nie faktúra. Validácia priamo voči UBL Invoice XSD preto zlyhá; biznis dokument nájdite podľa menného priestoru kdekoľvek v strome. Identifikátory vnútri payloadu sa neprepisujú, krátky tvar platí len pre JSON polia.
Parsujte s ohľadom na menné priestory
Prefixy (cac:, cbc:…) nie sú súčasťou kontraktu a môžu sa meniť medzi verziami aj v rámci jedného dokumentu. Viažte sa na URI menných priestorov a lokálne názvy z UBL 2.1 a Peppol BIS Billing 3.0.
Po stiahnutí
Keď je dokument trvalo uložený vo vašom systéme, potvrďte ho cez POST /api/v1/documents/inbox/{documentId}/acknowledged. Stiahnutie samo o sebe stav nemení. Ak v odpovedi chýba pole ublDocument, payload sa práve nepodarilo načítať — dokument nepotvrdzujte a skúste to neskôr.
Typické chyby
  • 404 (prázdne telo) — dokument neexistuje, nie je adresovaný vášmu tenantovi alebo nejde o prijatý dokument
  • 401 — neplatný token
Parametre
Názov
Popis
Stav
documentId
UUID prijatého dokumentu (path)
povinné
Výstupné polia
Názov
Popis
documentId
UUID dokumentu
senderParticipantId
Odosielateľ, krátky tvar (0245:1234567890)
receiverParticipantId
Príjemca, krátky tvar
documentTypeId, processId
Peppol typ dokumentu a proces
receivedAt
Čas prijatia
status
Stav dokumentu
ublDocument
Celý StandardBusinessDocument (XML reťazec)
GET v1 inbound

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

Pôvodná verzia zoznamu a detailu. Rovnaké parametre, stránkovanie, stavy, payload aj HTTP kódy ako v2 — líši sa iba tvar identifikátorov.
Rozdiel v1 a v2
v1: senderParticipantId / receiverParticipantId v plnom kanonickom tvare ISO 6523 — iso6523-actorid-upis::0088:1234567890123.
v2: krátke Peppol ID — 0088:1234567890123, teda rovnaký tvar, aký posielate v requestoch a aký vracia /participants/lookup.
Kompatibilita
Formát v1 je zmrazený a nezmení sa. Obe verzie čítajú tie isté dáta, môžete ich teda kombinovať. Nová verzia API vzniká vždy pod novou cestou, publikovaná verzia sa nemení spätne nekompatibilne.
POST v1 inbound

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

Potvrdenie, že váš systém prijatý dokument stiahol a spracoval. Stav prejde na ACKNOWLEDGED. Odpoveď 204 No Content.
Kedy službu volať
  • až keď je dokument trvalo uložený (import do ERP, commit v databáze)
  • ak spracovanie zlyhalo, nepotvrdzujte — dokument zostane v pôvodnom stave na ďalší pokus
  • platí pre v1 aj v2 integrácie (potvrdenie nenesie identifikátor účastníka, preto nemá v2 variant)
Idempotencia a chyby
Opakované potvrdenie už potvrdeného dokumentu je bez efektu a vráti znova 204. Potvrdiť možno prijatý dokument v akomkoľvek stave (aj REJECTED, ak ho chcete označiť ako vybavený); potvrdenie sa zapíše do udalostí ako MESSAGE_ACKNOWLEDGED a platí aj pre SAPI.
  • 404 — dokument neexistuje alebo nepatrí vášmu tenantovi
  • 401 — neplatný token

Desiatky až tisíce dokumentov jedným requestom (mesačná fakturácia, migrácia). Dávka prijme až 5 000 dokumentov a hneď odpovie 202. Každý dokument potom na pozadí prejde presne tými istými kontrolami ako POST /api/v1/documents/send a zaradí sa samostatne. Dokumenty dávky sa odosielajú až po dokumentoch posielaných jednotlivo a tenanti sa vo fronte striedajú, takže veľká dávka nebrzdí bežnú prevádzku.

POST v1 nové batch

/api/v1/batches

Prevzatie dávky dokumentov — JSON s metadátami alebo ZIP archív UBL súborov. Odpoveď 202 s batchId a hlavičkou Location.
Ako to funguje
202 znamená, že APEX dávku prevzal, nie že sú dokumenty platné. Dokumenty sú nezávislé: neplatný dokument nezastaví ostatné, skončí REJECTED s dôvodom. Výsledok sledujte cez GET /api/v1/batches/{batchId} (nie častejšie ako raz za 10 s) alebo notifikáciu BATCH_PROCESSED.
Limity
  • 1 až 5 000 dokumentov, najviac 100 MB na request, 10 MB na dokument
  • ZIP: navyše najviac 100 MB po rozbalení a 10 000 položiek archívu
  • najviac 3 otvorené dávky (RECEIVED/PROCESSING) na tenanta
  • dokumenty sa započítavajú do mesačného objemu licencie
Idempotencia
Vždy posielajte Idempotency-Key (1–200 znakov, napr. ID behu ERP). Ten istý kľúč a bajtovo identické telo → pôvodná 202 s Idempotent-Replayed: true, nová dávka nevznikne. Iné telo → 409 IDEMPOTENCY_CONFLICT. Kľúč dávky neexpiruje. Telo si pred odoslaním uložte a pri opakovaní pošlite tie isté bajty (curl --data-binary).
ZIP dávka
Content-Type: application/zip (aj application/x-zip-compressed); každý súbor = jeden dokument v UTF-8 (holý UBL alebo UBL v SBDH). Cesta súboru v archíve je clientReference dokumentu (súbory pomenujte číslom dokladu). Názov dávky a režim notifikácií idú do query parametrov clientReference a notify. Metadáta APEX odvodí z dokumentu: typ z koreňového elementu + cbc:CustomizationID, proces z cbc:ProfileID, strany z cbc:EndpointID (dodávateľ → odberateľ; pri samofaktúre naopak; pri objednávke kupujúci → predávajúci). Súbor bez odvoditeľných metadát skončí REJECTED s INVALID_METADATA.
Odmietnutie celej dávky
  • 400 BATCH_INVALID_REQUEST — nie je to JSON objekt/ZIP, chýba documents alebo povinné pole (správa uvádza cestu, napr. documents[17].processId), duplicitný clientReference, neznámy 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é polia (JSON)
Názov
Popis
Stav
clientReference
Vaše označenie dávky (max 200 znakov)
voliteľné
notify
BATCH (predvolené), DOCUMENT, BOTH
voliteľné
documents[]
1 až 5 000 dokumentov
povinné
documents[].clientReference
Označenie dokumentu (napr. číslo faktúry), v dávke unikátne — odporúčame vždy
voliteľné
documents[].senderParticipantId
Odosielateľ; musí patriť vášmu tenantovi
povinné
documents[].receiverParticipantId
Príjemca
povinné
documents[].documentTypeId, processId
Ako pri /documents/send
povinné
documents[].ublDocument
UBL dokument ako XML text (max 10 MB)
povinné
Výstupné polia (202)
Názov
Popis
batchId
UUID dávky
clientReference
Ako ste poslali
status
Vždy RECEIVED
itemCount
Počet dokumentov
receivedAt
Čas prevzatia
💡Pošlite hlavičku Expect: 100-continue — odmietnutie (429, 403, 400) potom príde ešte pred nahraním tela. Dávky jedného tenanta neposielajte paralelne a tú istú faktúru neposielajte zároveň v dávke aj cez /documents/send — odišli by dve.
GET v1 nové batch

/api/v1/batches/{batchId}

Stav dávky: počty dokumentov podľa stavu prevzatia (items) a živé počty doručovania vzniknutých správ (messages).
Stav dávky
RECEIVED — prevzatá, spracovanie nezačalo
PROCESSING — dokumenty sa validujú a zaraďujú
PROCESSED — každý dokument je ACCEPTED, REJECTED alebo CANCELLED; doručovanie prijatých pokračuje (pozri messages)
CANCELLED — zrušená klientom
items vs. messages
items = prevzatie dokumentov: pending, processing, accepted, rejected, cancelled.
messages = doručovanie správ z prijatých dokumentov, rovnaké stavy ako /documents/{id}/status: queued, processing, delivered (vrátane prechodného SENT), retrying, failed, rejected, deadLetter. Súčet messages = accepted.
Typické chyby
  • 404 BATCH_NOT_FOUND — neexistuje alebo patrí inému tenantovi
Výstupné polia
Názov
Popis
batchId, clientReference, notify, itemCount
Identita a nastavenie dávky
status
Stav dávky (vľavo)
items{}
Počty dokumentov podľa stavu prevzatia
messages{}
Počty správ podľa stavu doručovania
receivedAt, processedAt, cancelledAt
Časy; processedAt je null, kým nie sú spracované všetky dokumenty
GET v1 nové batch

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

Dokumenty dávky v poradí z requestu, voliteľne len v jednom stave — napr. status=REJECTED pre to, čo treba opraviť.
Dôvody zamietnutia (errorCode)
DOCUMENT_VALIDATION_FAILED — opravte podľa errors[]
INVALID_METADATA — metadáta (pri ZIP čo chýba v dokumente: 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 — príjemca nie je v Peppol
RECEIVER_DOCUMENT_TYPE_UNSUPPORTED — príjemca typ neprijíma
PARTICIPANT_NOT_AUTHORIZED — odosielateľ nie je váš
LICENCE_INVALID — licencia medzitým prestala platiť
BATCH_ITEM_RETRIES_EXHAUSTED — dočasná chyba trvala dlhšie ako cca 45 min (8 pokusov), pošlite znova
Stavy dokumentu dávky
PENDING — čaká (s vyplneným errorMessage po dočasnej chybe čaká na ďalší pokus)
PROCESSING — práve sa validuje a zaraďuje
ACCEPTED — zaradený; documentId použite pre /documents/{id}/status, /events, /responses
REJECTED — odmietnutý, pozri errorCode
CANCELLED — zrušený s dávkou
Parametre
status (voliteľné), page od 0, size predvolene 100, najviac 1 000. Chyby: 400 neplatný stav/stránkovanie, 404 BATCH_NOT_FOUND.
Výstupné polia (content[])
Názov
Popis
seqNo
Poradie v requeste (od 1)
clientReference
Vaše označenie dokumentu (pri ZIP cesta súboru)
receiverParticipantId
Príjemca (chýba, ak sa z ZIP súboru nedal odvodiť)
status
Stav dokumentu dávky
documentId
UUID správy, ak ACCEPTED
errorCode, errorMessage, errors[]
Dôvod zamietnutia; errors[] = code, message, location
attempts, processedAt
Počet dočasných zlyhaní, čas spracovania
Obálka stránky
Názov
Popis
content[]
Dokumenty na stránke
page, size
Číslo stránky (od 0) a veľkosť
totalElements
Počet dokumentov zodpovedajúcich filtru
GET v1 nové batch

/api/v1/batches

Zoznam dávok tenanta, najnovšie prvé; voliteľne len prevzaté v intervale [from, to) alebo v jednom stave.
Parametre
from, to (ISO 8601 date-time), status (RECEIVED, PROCESSING, PROCESSED, CANCELLED), page od 0, size predvolene 20, najviac 1 000.
Odpoveď
content[] s batchId, clientReference, status, notify, itemCount, receivedAt, processedAt, cancelledAt; ďalej page, size, totalElements. Počty dokumentov sú v detaile dávky. Chyba 400 pri neplatnom stave alebo stránkovaní.
POST v1 nové batch

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

Zruší dokumenty, ktoré ešte nie sú zaradené. Už prijaté (ACCEPTED) dokumenty sú na ceste a nevolajú sa späť.
Správanie
Zrušia sa dokumenty PENDING aj dokument, ktorý sa práve validuje (o chvíľu skončí CANCELLED, preto môže byť v odpovedi ešte processing > 0). Dávka prejde na CANCELLED, prestane sa počítať do limitu 3 otvorených dávok a BATCH_PROCESSED sa pre ňu nepošle. Odpoveďou je stav dávky (ako GET /batches/{batchId}).
Typické chyby
  • 404 BATCH_NOT_FOUND
  • 409 BATCH_NOT_CANCELLABLE — dávka je už PROCESSED alebo CANCELLED
Notifikácie dávky
Režim zvolíte poľom notify. BATCH_PROCESSED príde na každý aktívny webhook a MQTT queue tenanta; filtre webhooku sa naň neuplatňujú. Nenesie zoznam dokumentov, iba počty — dokumenty načítajte cez /items.
notifyBATCH_PROCESSEDNotifikácie jednotlivých dokumentov
BATCH (predvolené)ánoiba problémy: QUEUE_PROCESSING_FAILED, QUEUE_DEAD_LETTER, MLS_RECEIVED_NEGATIVE
DOCUMENTnievšetky, ako pri jednotlivom odoslaní
BOTHánovšetky

Vyhľadanie obchodného partnera v sieti Peppol podľa DIČ (alebo iného identifikátora so schémou) či IČO. Výsledok povie, či je partner v Peppol registrovaný, cez ktorý AS4 endpoint prijíma a či je certifikát jeho prístupového bodu použiteľný. Pre slovenské subjekty používajte schému 0245 (SK:DIČ) — Peppol ID má tvar 0245:2024000001.

GET v1 participants

/api/v1/participants/lookup/dic

Vyhľadanie podľa DIČ alebo ľubovoľného identifikátora s ICD schémou. Lokálny záznam, pri starom alebo chýbajúcom zázname živá kontrola v SML a SMP.
Zloženie Peppol ID
Peppol ID = <schema>:<dic>, plný identifikátor iso6523-actorid-upis::<schema>:<dic>. Hodnoty sa používajú presne tak, ako ich pošlete — bez orezania, zmeny veľkosti písmen, odstránenia prefixu SK a bez kontroly formátu. 2024000001 a SK2024000001 sú dva rôzne identifikátory.
Poradie vyhodnotenia
1. Lokálny záznam participanta.
2. V sandboxe sa vráti lokálny záznam (source=LOCAL), bez neho 404; SML/SMP sa nevolá.
3. Záznam s SMP metadátami mladšími ako TTL (predvolene 5 dní) → source=LOCAL.
4. Starší, nikdy neoverený alebo chýbajúci záznam → živá kontrola v SML a SMP:
  • SML hlási, že participant nie je registrovaný → 404 (aj keď lokálny záznam existuje)
  • SML/SMP neodpovie → lokálny záznam (LOCAL), bez neho 503
  • SMP publikuje AS4 endpoint pre BIS Billing 3.0 Invoice → source=SMP s endpointom a certifikátom
  • SMP nemá pre participanta záznam Invoice / AS4 endpoint → source=SMP s uloženým endpointom alebo null
Platnosť certifikátu — certificate.valid
true — certifikát publikovaný v SMP prešiel počas requestu plnou kontrolou: platnosť, reťaz vydavateľa a stav odvolania, na ktorý CRL alebo OCSP skutočne odpovedal.
false — certifikát je s istotou nepoužiteľný, dôvod v invalidReason: EXPIRED, NOT_YET_VALID, REVOKED, UNTRUSTED_ISSUER (nevydala ho CA OpenPeppol). Na taký endpoint nemožno doručiť.
null — stav sa v tomto requeste nezistil (certifikát z lokálneho záznamu, alebo soft-fail pri nedostupnom CRL/OCSP). Soft-fail nikdy nedá true.
valid a invalidReason sú v JSON vždy, aj s hodnotou null.
Typické chyby
  • 400 — chýba schema alebo dic
  • 404 — nie je registrovaný v Peppol, alebo prázdna hodnota (bez tela)
  • 503 — SML/SMP neodpovedá a lokálny záznam neexistuje — zopakujte neskôr
Query parametre
Názov
Popis
Stav
schema
ICD kód schémy, napr. 0245 (SK DIČ), 9950 (SK IČ DPH), 9929 (CZ VAT), 9914 (AT VAT), 0088 (GLN)
povinné
dic
Hodnota identifikátora; slovenské DIČ = 10 číslic bez prefixu SK
povinné
Výstupné polia
Názov
Popis
source
LOCAL (lokálny záznam) alebo SMP (živé vyhľadanie v tomto requeste)
participantId
Plný identifikátor iso6523-actorid-upis::0245:…
peppolId
Krátky tvar 0245:2024000001
organizationName
Názov z lokálneho záznamu; pri participantovi známom len z SMP null
countryCode
ISO 3166-1 alpha-2; pri SMP odvodené zo schémy (0245 → SK); ZZ = neznáma
endpointUrl
AS4 endpoint prístupového bodu partnera (BIS Billing 3.0 Invoice)
smpUrl
SMP server partnera
enabled
Príznak lokálneho záznamu; null, ak záznam neexistuje
certificate
subject, issuer, serial, fingerprint (SHA-256), notBefore, notAfter, expired, valid, invalidReason
smpMetadataUpdatedAt
Čas posledného úspešného overenia v SMP
GET v1 participants

/api/v1/participants/lookup/ico

Vyhľadanie podľa IČO: IČO → DIČ cez Register účtovných závierok (registeruz.sk) → ďalej presne ako /lookup/dic.
Postup
1. IČO (bez okolitých medzier, inak bez úprav) sa pošle do registeruz.sk a získa sa DIČ. Výsledok sa necacheuje — každý request sa pýta registra.
2. Register nepozná účtovnú jednotku, tá nemá DIČ, alebo register vráti 4xx (okrem 429) → 404.
3. Register je nedostupný, neodpovie do 15 s, vráti 5xx/429 alebo nečitateľnú odpoveď → 503.
4. Zo získaného DIČ a schema vznikne Peppol ID a vyhodnotí sa rovnako ako /lookup/dic.
Kedy službu volať
  • v ERP poznáte len IČO obchodného partnera
  • pri automatickom dopĺňaní Peppol identity do adresára partnerov
Typické chyby
  • 400 — chýba ico
  • 404 — IČO sa nepodarilo preložiť na DIČ alebo participant nie je v Peppol
  • 503 — registeruz.sk alebo SML/SMP nedostupné
Query parametre
Názov
Popis
Stav
ico
IČO, spravidla 8 číslic; bez kontroly formátu
povinné
schema
Schéma pre zloženie Peppol ID z DIČ; predvolene 0245
voliteľné
Výstupné polia
Názov
Popis
—
Rovnaký objekt ako /lookup/dic

Push notifikácie namiesto pollingu: o novom prijatom dokumente a o udalostiach vašich odoslaných dokumentov. Dva kanály — HTTPS webhook (filtrovateľný, viac odberov) a MQTT topic (jeden na tenanta, všetky notifikácie). Notifikácia dokument iba identifikuje, obsah si stiahnete cez API. Doručenie je best-effort, najviac raz a bez zaručeného poradia: stav dokumentu berte vždy z poľa status, nikdy z eventType.

Notifikácia — formát a udalosti
Jedna notifikácia = jeden dokument a jedna udalosť (documentIds má vždy práve jeden prvok, tvar poľa je zachovaný kvôli kompatibilite). Polia s hodnotou null sa v JSON vynechávajú.
PoleVýznam
eventTypeČo notifikáciu vyvolalo — nie stav dokumentu
subscriptionIdOdber, pre ktorý sa doručuje (pri MQTT chýba)
documentId / documentIdsUUID dokumentu / to isté ako jednoprvkové pole
receivedCountVždy 1, len pri DOCUMENTS_RECEIVED
directionIN prijatý, OUT odoslaný dokument
statusStav dokumentu v čase odoslania notifikácie
messageIdID správy; pri prijatom dokumente AS4 Message ID od odosielajúceho AP
conversationIdConversation ID dokumentu (ak existuje)
senderParticipantId, receiverParticipantIdPeppol ID vrátane schémy (iso6523-actorid-upis::…)
documentTypeId, processIdPeppol typ dokumentu a proces
eventMessageČitateľný detail, neparsujte ho
notifiedAtKedy bola notifikácia zostavená. Webhook: číslo, Unix epoch sekundy so zlomkom (1776168005.123456000); MQTT: ISO 8601 reťazec
batchLen pri BATCH_PROCESSED: batchId, clientReference, status, itemCount, accepted, rejected, cancelled
eventTypeSmerKedy
DOCUMENTS_RECEIVEDINPrijatý dokument prešiel validáciou a je uložený (VALIDATED); pri zamietnutom ani duplicitnom dokumente nepríde
MESSAGE_QUEUEDOUTVáš dokument bol prijatý a zaradený
QUEUE_PROCESSING_STARTEDOUTZačal sa pokus o odoslanie (pri každom pokuse; nie pri self-send)
MESSAGE_DELIVEREDOUTDoručené prijímajúcemu AP (alebo lokálne pri self-send)
QUEUE_PROCESSING_FAILEDOUTPokus zlyhal, ďalší je naplánovaný
QUEUE_DEAD_LETTEROUTOdosielanie vzdané, dokument je DEAD_LETTER
MLS_RECEIVEDOUTPrišiel pozitívny Peppol MLS
MLS_RECEIVED_NEGATIVEOUTPrišiel negatívny MLS; dokument je FAILED (aj po DELIVERED)
BATCH_PROCESSED—Dávka je spracovaná (podľa notify)
Poradie a stav dokumentu
Notifikácie sa odosielajú asynchrónne a nezávisle, aj z rôznych inštancií APEX, preto nemajú zaručené poradie ani pre jeden dokument — MESSAGE_DELIVERED môže prísť pred MESSAGE_QUEUED. status je stav prečítaný pri odoslaní notifikácie, môže byť novší ako udalosť (napr. MESSAGE_QUEUED so stavom DELIVERED) a notifikácia so starším stavom môže prísť po novšej. Poslednú prijatú notifikáciu teda neberte ako aktuálny stav; pri pochybnosti zavolajte GET /api/v1/documents/{documentId}/status. Nie každá zmena stavu sa notifikuje (napr. REJECTED pre neplatnú licenciu).
Záruky doručenia
Best-effort, at-most-once: každá notifikácia sa pošle raz. Odpoveď mimo 2xx, timeout alebo chyba spojenia sa iba zaloguje — žiadny retry ani opätovné doručenie. Notifikácie čakajúce na odoslanie sú len v pamäti a pri zastavení inštancie sa môžu stratiť. Zlyhaný webhook nikdy neovplyvní odoslanie ani príjem dokumentu. Spoľahlivosť preto stavajte na kombinácii notifikácií a periodického pollingu (/inbox, /status).
POST v1 webhooky

/api/v1/subscriptions

Registrácia HTTPS webhooku. APEX naň pošle POST pri každom dokumente a udalosti, ktoré zodpovedajú filtrom. Odpoveď 201 Created.
Požiadavky na váš endpoint
URL musí byť https:// a dostupná zo servera APEX (dostupnosť sa pri registrácii neoveruje, presmerovania sa nenasledujú). Timeout spojenia 2 s a odpovede 2 s — vráťte 2xx čo najskôr (ideálne < 500 ms) a ťažké spracovanie robte asynchrónne. Odbery tenanta sa pre jednu udalosť volajú postupne, pomalý endpoint teda zdrží ostatné. Request má Content-Type: application/json, Accept: application/json a User-Agent: Apex-Webhook/1.0. Telo nie je podpísané — na overenie APEX použite customHeaders (napr. tajný token).
Filtre
documentTypeFilters — zoznam typov dokumentov, presná zhoda; platí pre prijaté aj odoslané dokumenty.
senderParticipantFilters — zoznam odosielateľov, presná zhoda na kanonický identifikátor tak, ako je v senderParticipantId notifikácie (napr. iso6523-actorid-upis::0245:1234567890; krátky tvar sa nezhoduje); len pre prijaté dokumenty.
Prázdny zoznam = bez obmedzenia. Filter podľa typu udalosti neexistuje; BATCH_PROCESSED filtre ignoruje.
Limity a customHeaders
Najviac 3 webhooky na tenanta (aktívne aj pozastavené spolu). Najviac 10 hlavičiek; názov max 100 znakov len [A-Za-z0-9-_], hodnota max 1 000 znakov bez zalomení riadkov. Host, Content-Length, Content-Type a Transfer-Encoding nemožno prepísať (Accept a User-Agent áno). Hlavička, ktorá pravidlá nesplní, sa ticho vynechá — skontrolujte customHeaders v odpovedi.
Typické chyby
  • 400 — chýba name/url, URL nie je https://, priveľa hlavičiek (Problem Details s detail: "Invalid request content.")
  • 409 — tenant už má 3 webhooky
  • 401 — neplatný token
Vstupné polia
Názov
Popis
Stav
name
Názov odberu (max 100 znakov)
povinné
description
Popis (max 500 znakov)
voliteľné
url
HTTPS URL (max 2 048 znakov)
povinné
active
Aktívny po uložení (predvolene true)
voliteľné
documentTypeFilters[]
Filter typov dokumentov
voliteľné
senderParticipantFilters[]
Filter odosielateľov (len prijaté)
voliteľné
customHeaders{}
Vlastné HTTP hlavičky
voliteľné
Výstupné polia
Názov
Popis
subscriptionId
UUID odberu
name, description, url, active
Uložené hodnoty
documentTypeFilters, senderParticipantFilters
Uložené filtre
customHeaders
Uložené hlavičky
createdAt, updatedAt
Časy vytvorenia a poslednej zmeny
GET v1 webhooky

/api/v1/subscriptions

Stránkovaný zoznam webhookov tenanta, najnovšie vytvorené prvé.
Parametre
offset (predvolene 0), limit (predvolene 20, 1–100).
Odpoveď
items[] (objekty ako pri vytvorení), total (všetky odbery tenanta bez ohľadu na stránku), offset, limit. Chyby 400 (limit < 1), 401.
GET PUT DELETE v1 webhooky

/api/v1/subscriptions/{subscriptionId}

Detail, úplná náhrada a zmazanie jedného webhooku.
GET — detail
Vráti odber (rovnaký objekt ako pri vytvorení). 404, ak neexistuje alebo patrí inému tenantovi.
PUT — úplná náhrada
Telo ako pri POST; prepíšu sa všetky polia (nie PATCH). Na dočasné pozastavenie bez straty nastavenia pošlite active: false. Zmena platí pre notifikácie odoslané po uložení. Odpoveď 200 s aktualizovaným odberom; 400 pri neplatnom tele, 404.
DELETE — zmazanie
Nevratne odstráni odber, ďalšie notifikácie na jeho URL sa neposielajú. Odpoveď 204; 404, ak neexistuje. Ak chcete len prestať dočasne, použite PUT s active: false.
POST v1 MQTT

/api/v1/subscriptions/queue

Vytvorí MQTT prístup tenanta: používateľa brokera a topic, na ktorý APEX publikuje všetky notifikácie tenanta. Prihlasovacie údaje sa zobrazia iba raz.
Ako to funguje
Jeden MQTT prístup na tenanta. Topic (queueName, napr. /apex/inbox/apex-sk2024000001) dostáva notifikácie prijatých aj odoslaných dokumentov, hoci má v názve inbox. Filtre a príznak active webhookov sa naň neuplatňujú. Správa má rovnaký formát ako webhook, bez subscriptionId a s notifiedAt ako ISO 8601 reťazcom.
Pripojenie
Ľubovoľný klient MQTT 3.1.1 s poľami host, port, username, password (alebo mqttUrl, ktoré má vždy schému mqtt:// — či broker vyžaduje TLS, určuje prostredie). Prihláste sa na topic queueName doslovne, vrátane úvodnej lomky a bez zástupných znakov (#, +) — používateľ brokera má oprávnenie len na presne tento topic. APEX publikuje s QoS 1, bez retain; či sa vám uchovajú správy publikované počas výpadku spojenia, závisí od brokera a nastavení vašej MQTT session (clean / persistent session).
Bezpečnosť
password a úplné mqttUrl sa vrátia len v tejto odpovedi; na serveri je uložený iba hash hesla. Pri strate hesla prístup zmažte a vytvorte nový — vznikne nové heslo.
Typické chyby
  • 409 — MQTT prístup pre tenanta už existuje (najprv ho zmažte)
  • 400 — prístup sa na brokeri nepodarilo zriadiť; zopakujte neskôr
  • 401
Výstupné polia (201)
Názov
Popis
queueId
UUID záznamu prístupu
mqttUrl
Úplná MQTT URL s prihlasovacími údajmi (jednorazovo)
amqpUrl
Spätne kompatibilný alias mqttUrl — nepoužívajte v nových integráciách
host, port
Broker
vhost
Logický menný priestor brokera (pre MQTT len informatívne)
username, password
Prihlasovacie údaje (heslo jednorazovo)
queueName
MQTT topic tenanta
createdAt, securityWarning
Čas vytvorenia, bezpečnostné upozornenie
DELETE /api/v1/subscriptions/queue
Zmaže MQTT prístup tenanta: používateľ brokera sa okamžite zruší (aktívne spojenia sa odpoja) a na topic sa prestane publikovať. Potom môžete vytvoriť nový prístup s novými údajmi. Odpoveď 204; 404, ak prístup neexistuje.

Prehľad prevádzky tenanta (štatistiky odoslaných a prijatých dokumentov), história štatistických hlásení EUSR/TSR do OpenPeppol a stav licencie s mesačným čerpaním dokumentov.

🚧Reporting je v zavádzaní. V /reporting/statistics sú spoľahlivé živé počty delivered, failed, topRecipients, topSenders a failedDocuments; agregované total, byDocumentType, byCountry a deliveryRate sú zatiaľ nulové alebo prázdne. /reporting/submissions zatiaľ nevracia záznamy. Pre presné čísla o vašich dokumentoch použite /api/v1/licenses/info (mesačné čerpanie) a vlastnú evidenciu stavov.
GET v1 reporting

/api/v1/reporting/statistics

Agregované štatistiky za obdobie: odoslané a prijaté dokumenty, úspešnosť doručenia, členenie podľa typu dokumentu a krajiny, top partneri a dokumenty v chybovom stave.
Obdobie
period=month / quarter / year — aktuálny kalendárny mesiac, štvrťrok, rok.
from + to (obidva, YYYY-MM-DD) — vlastný interval, period sa ignoruje a v odpovedi je type=custom. Ak pošlete len jeden z nich, ignoruje sa.
Bez parametrov — aktuálny mesiac. Odpoveď v period vždy uvádza presne použitý rozsah.
Kedy službu volať
  • dashboard prevádzky v ERP alebo portáli
  • pravidelné reporty pre vedenie
  • sledovanie trendov a chybovosti doručenia
Význam čísel
sent / received: total, delivered, failed (FAILED + DEAD_LETTER), deliveryRate (0.0–1.0, null pri nule), byDocumentType (kľúče INVOICE, CREDIT_NOTE, ORDER, ORDER_RESPONSE, DESPATCH_ADVICE…), byCountry (krajina protistrany).
deliveryRate na najvyššej úrovni počíta len odoslané dokumenty.
topRecipients / topSenders — najviac 10 partnerov (name, peppolId v kanonickom tvare, countryCode, count).
failedDocuments — dokumenty, ktoré sú práve v chybovom stave (bez ohľadu na obdobie, oba smery): total, deadLetters, retrying, rejected.
Typické chyby
  • 400 — from po to alebo neznáme period
  • 401 / 403
GET v1 reporting

/api/v1/reporting/submissions

História mesačných štatistických hlásení do OpenPeppol: EUSR (End User Statistics Report) a TSR (Transaction Statistics Report), najnovšie prvé.
Pozadie
Každý Peppol Access Point musí OpenPeppol mesačne hlásiť štatistiky: EUSR počíta transakcie koncových používateľov, TSR transakcie podľa typu dokumentu a smeru. Hlásenia generuje a odosiela APEX ako prístupový bod; od vás sa nič nevyžaduje. Endpoint je pripravený na audit odoslaných hlásení, zatiaľ však vracia prázdny zoznam.
Stavy
PENDING — vygenerované, neodoslané
SUBMITTED — odoslané, čaká na potvrdenie
FAILED — odoslanie zlyhalo (errorMessage), zopakuje sa
VALIDATED — OpenPeppol hlásenie prijal
Parametre
reportType (EUSR/TSR), status, offset (predvolene 0), limit (predvolene 20, 1–100). Napr. ?reportType=EUSR&status=FAILED.
Odpoveď
items[]: id, reportType, periodStart, periodEnd, reporterId, status, errorMessage, submittedAt, validatedAt, createdAt; ďalej total, offset, limit. Chyba 400 pri neznámej hodnote filtra.
GET v1 licencia

/api/v1/licenses/info

Licencia tenanta a čerpanie mesačného počtu dokumentov.
Počítanie dokumentov
Limit maxDocuments je mesačný (-1 = neobmedzený). Všetky počty v documentUsage sa týkajú aktuálneho kalendárneho mesiaca v UTC (periodStart–periodEnd). usedDocuments = odoslané + prijaté, každá uložená správa bez ohľadu na stav (aj QUEUED a FAILED).
Prekročenie limitu
Pri limitExceeded: true odosielanie aj príjem fungujú ďalej — je to signál na navýšenie licencie. Počítadlá sa vynulujú začiatkom ďalšieho mesiaca. Neplatná licencia (valid: false) však odosielanie blokuje (REJECTED, resp. 403 LICENCE_INVALID).
Odpoveď
serialNumber, companyName, branchName, licenseTypeCode, validFrom, validTo (formát 2026-01-01T00:00:00.000+0000), valid, autoProlong a documentUsage: maxDocuments, usedDocuments, remainingDocuments (-1 = neobmedzene), usagePercentage (null pri neobmedzenej), limitExceeded, sentDocuments, receivedDocuments, periodStart, periodEnd.
Typické chyby
  • 404 (prázdne telo) — tenant nemá aktívnu licenciu; licencia po platnosti vráti 200 s valid: false
  • 401

Autentifikácia podľa SAPI-SK v1.0. APEX žiadosť prepošle do ASOL IAM (OAuth 2.0 client_credentials) a k IAM access tokenu pridá vlastný refresh token (30 dní, rotácia pri každom použití), takže klient nemusí pri každom obnovení posielať client_secret. Access token zo SAPI platí aj pre APEX API (/api/**) a naopak. Polia týchto endpointov sú v snake_case; /token, /renew a /revoke sú verejné (bez Bearer tokenu).

POST v1 SAPI auth

/sapi/v1/auth/token

Výmena client_id + client_secret za access token (JWT RS256 z ASOL IAM) a refresh token APEX.
Účel služby
Prihlásenie integračného klienta. Telo je JSON (Content-Type: application/json; application/x-www-form-urlencoded vráti 415). APEX prepošle údaje do IAM a vráti jeho access token spolu s novým refresh tokenom. Platnosť access tokenu udáva pole expires_in.
Kedy službu volať
  • pri štarte integračného klienta
  • keď refresh token vypršal alebo bol zneplatnený
  • bežné obnovenie robte cez /renew
Bezpečnosť
Údaje klienta sú viazané na jednu organizáciu (tenanta) — nezdieľajte ich medzi systémami a neukladajte do zdrojového kódu. Tokeny nikdy neposielajte v URL. Parameter scope je voliteľný a prepošle sa do IAM; o prístupe k dokumentom a participantom rozhoduje tenant, ku ktorému sú údaje klienta viazané.
Typické chyby
  • 400/401 SAPI-AUTH-001 — IAM odmietol údaje (stav vracia IAM)
  • 400 — nečitateľné JSON telo (Problem Details)
  • 415 — iný Content-Type ako JSON
  • 500 SAPI-AUTH-999 — IAM nedostupný alebo interná chyba; zopakujte neskôr
Vstupné polia (JSON)
Názov
Popis
Stav
client_id
Identifikátor klienta
povinné
client_secret
Tajomstvo klienta
povinné
grant_type
client_credentials
povinné
scope
Rozsah pre IAM (prístup určuje tenant)
voliteľné
Výstupné polia (200)
Názov
Popis
access_token
JWT (RS256) z ASOL IAM pre hlavičku Authorization: Bearer
token_type
Bearer
expires_in
Platnosť access tokenu v sekundách
scope
Rozsah z IAM alebo null
refresh_token
Refresh token APEX, platný 30 dní; vždy prítomný
GET v1 SAPI auth

/sapi/v1/auth/token/status

Informácie o aktuálnom access tokene z hlavičky Authorization: platnosť, zostávajúci čas a odporúčanie obnoviť.
Účel služby
Diagnostika a plánovanie obnovy tokenu. Vyžaduje platný Bearer token (hlavička X-Peppol-Participant-Id nie je potrebná). should_refresh je true, keď do vypršania zostávajú menej ako 3 minúty.
Kedy službu volať
  • v health-checku integračného klienta
  • pri ladení problémov s autentifikáciou
  • obnovu je jednoduchšie plánovať priamo z expires_in
Typické chyby
  • 401 SAPI-AUTH-002 — token chýba, je neplatný alebo vypršal
Výstupné polia
Názov
Popis
valid
Pri 200 vždy true
token_type
access
client_id
Subjekt tokenu (claim sub; pri klientskom tokene UUID)
issued_at, expires_at
Čas vydania a vypršania (UTC)
expires_in_seconds
Zostávajúce sekundy
should_refresh
Menej ako 3 minúty do vypršania
refresh_recommended_at
Odporúčaný čas obnovy (vypršanie − 3 min)
POST v1 SAPI auth

/sapi/v1/auth/renew

Nový access token a nový refresh token výmenou za aktuálny refresh token. Rotácia — použitý refresh token sa okamžite zneplatní.
Rotácia a platnosť
Každé volanie zneplatní predložený refresh token a vydá nový s platnosťou 30 dní od obnovenia (klient, ktorý pravidelne obnovuje, sa teda nemusí znova prihlasovať). Nový refresh token si vždy uložte — starý už nefunguje. Ak obnovenie v IAM zlyhá, predložený refresh token je už spotrebovaný a treba sa prihlásiť cez /token.
Detekcia opakovaného použitia
Predloženie už použitého alebo zneplatneného refresh tokenu vráti 401 SAPI-AUTH-006 a z bezpečnostných dôvodov zneplatní všetky refresh tokeny daného klienta (už vydané access tokeny dobehnú do svojej expirácie). Klient sa potom musí prihlásiť cez /token. Pri viacerých inštanciách klienta preto refresh token zdieľajte, alebo každá inštancia nech má vlastný.
Typické chyby
  • 401 SAPI-AUTH-007 — refresh token je neplatný, poškodený alebo vypršal
  • 401 SAPI-AUTH-006 — refresh token už bol použitý alebo zneplatnený
  • SAPI-AUTH-001 — IAM odmietol uložené údaje klienta (napr. zmenené client_secret)
  • 500 SAPI-AUTH-999 — interná chyba alebo IAM nedostupný
Vstupné polia (JSON)
Názov
Popis
Stav
refresh_token
Aktuálny refresh token
povinné
Výstupné polia
Názov
Popis
access_token, token_type, expires_in, scope, refresh_token
Rovnako ako pri /token — nová dvojica tokenov
POST v1 SAPI auth

/sapi/v1/auth/revoke

Zneplatnenie refresh tokenu (RFC 7009, idempotentné). Na základe vlastníctva tokenu — bez client_id/client_secret.
Správanie
Refresh token APEX sa zneplatní okamžite; ďalší /renew s ním vráti 401. Opakované zneplatnenie už neplatného tokenu vráti tiež 200 ("Token was already invalid or expired"). Iný token APEX prepošle na revokáciu do IAM.
Access tokeny
APEX overuje access token lokálne (podpis a expirácia), preto access token zostane platný do svojej expirácie aj po revokácii. Pri bezpečnostnom incidente zneplatnite refresh token a nechajte v IAM zmeniť client_secret.
Kedy službu volať
  • pri odstavení integračného klienta
  • pri podozrení na únik refresh tokenu
  • pri rotácii prístupových údajov
Typické chyby
  • SAPI-AUTH-001 — IAM odmietol revokáciu iného tokenu
  • 500 SAPI-AUTH-999 — IAM nedostupný
Vstupné polia (JSON)
Názov
Popis
Stav
token
Token na zneplatnenie (refresh token APEX)
povinné
token_type_hint
refresh_token
voliteľné
Výstupné polia
Názov
Popis
success
Pri 200 vždy true
message
Napr. Refresh token revoked successfully
timestamp
Čas odpovede (ISO 8601)

Tri operácie podľa SAPI-SK v1.0: odoslať, prijať, potvrdiť. Každý request nesie hlavičku X-Peppol-Participant-Id (organizačný kontext — participant vášho tenanta; krátky aj kanonický tvar). Polia dokumentových endpointov sú v camelCase; neznáme polia sa ticho ignorujú, preto dodržte presné názvy.

POST v1 SAPI outbound

/sapi/v1/document/send

Odovzdanie dokumentu na doručenie cez Peppol. Kontroly prebehnú synchrónne, doručenie asynchrónne: 200 ACCEPTED = prevzatie do úschovy, 4xx/5xx REJECTED = nič sa nezaradilo.
Kontroly pred ACCEPTED
1. Request — hlavičky, polia metadata, payload, payloadFormat (len XML), payloadEncoding (len UTF-8), voliteľný checksum.
2. Oprávnenie — participant z hlavičky aj metadata.senderParticipantId patria vášmu tenantovi a sú totožné; tenant má platnú licenciu.
3. Dokument — well-formed XML, XSD, Schematron (EN 16931 / Peppol BIS) a biznis pravidlá pre documentTypeId.
4. Strany — odosielateľ a príjemca sú strany uvedené v dokumente (dodávateľ → odberateľ; samofaktúru posiela odberateľ, objednávku kupujúci).
5. Príjemca — je registrovaný v Peppol (SML/SMP) a ponúka documentTypeId + processId cez AS4.
Doručenie
SAPI výsledok doručenia nehlási (SAPI-SK v1.0 §9.5). Uložte si providerDocumentId — je to UUID dokumentu v APEX, takže s tým istým tokenom môžete sledovať doručenie cez GET /api/v1/documents/{providerDocumentId}/status, /events alebo webhooky.
Idempotencia (Idempotency-Key, povinná)
Nový jedinečný kľúč (napr. UUID, max 200 znakov) pre každý dokument; kľúče sú oddelené pre každého tenanta. Rovnaký kľúč + rovnaký request (payload, odosielateľ, príjemca, typ, proces) do 24 h → pôvodná odpoveď ACCEPTED (rovnaké providerDocumentId a receivedAt), nič sa nezaradí druhýkrát. Iný request → 409 IDEMPOTENCY_CONFLICT. Prvý request ešte beží → 409 IDEMPOTENCY_IN_PROGRESS (opakujte s tým istým kľúčom). Odmietnutý request kľúč nespotrebuje. Po 24 h sa kľúč správa ako nový — neopakujte teda staré requesty po dni.
Opakovanie
Opakujte, len ak error.retryable je true (409 IDEMPOTENCY_IN_PROGRESS, 503, 500, 429), s exponenciálnym odstupom a tým istým Idempotency-Key. Pri kontakte s podporou uveďte error.correlation_id.
Hlavičky a telo (JSON)
Názov
Popis
Stav
Idempotency-Key
Hlavička, 1–200 znakov
povinné
X-Peppol-Participant-Id
Hlavička; ten istý participant ako metadata.senderParticipantId
povinné
metadata.senderParticipantId
Odosielateľ (0245:1234567890 alebo kanonický tvar)
povinné
metadata.receiverParticipantId
Príjemca
povinné
metadata.documentTypeId
Peppol typ dokumentu
povinné
metadata.processId
Peppol proces
povinné
metadata.documentId
Vaše označenie, len informatívne
voliteľné
metadata.creationDateTime
Informatívne; ak je uvedené, musí byť ISO 8601 s posunom
voliteľné
payload
Dokument ako UTF-8 XML text (nie Base64) — holý UBL alebo UBL v SBDH; odporúčame do 10 MB
povinné
payloadFormat
XML
povinné
payloadEncoding
UTF-8 (predvolené)
voliteľné
checksum
SHA-256 z UTF-8 bajtov payload, hex (64 znakov)
voliteľné
Výstupné polia (200)
Názov
Popis
providerDocumentId
UUID dokumentu v APEX (pre podporu aj APEX API)
status
Vždy ACCEPTED — prevzatie, nie doručenie
receivedAt
Kedy APEX dokument prevzal (UTC); pri replay pôvodná hodnota
timestamp
Čas vytvorenia tejto odpovede (UTC)
Odmietnutie (4xx/5xx)
Názov
Popis
status
REJECTED
timestamp
Čas odpovede
errorCode
Dôvod (tabuľka nižšie)
errorMessage
Popis dôvodu
error
Obálka SAPI chyby: category, code, message, details[], retryable, correlation_id
HTTPerrorCodeerror.coderetryablePríčina
400INVALID_REQUESTSAPI-VAL-001niechýba/prázdna hlavička Idempotency-Key (alebo > 200 znakov) či X-Peppol-Participant-Id; telo nie je platný JSON; neplatné creationDateTime
400INVALID_METADATASAPI-VAL-001niechýba metadata alebo niektorý z identifikátorov, prípadne obsahuje riadiace znaky
400PAYLOAD_MISSINGSAPI-VAL-001niechýba payload (napr. telo podľa špecifikácie document{content})
400INVALID_DOCUMENT_FORMATSAPI-VAL-001niepayloadFormat nie je XML, payloadEncoding nie je UTF-8, nesedí checksum
400INVALID_DOCUMENT_FORMATSAPI-VAL-002niepayload nie je well-formed XML
400UNSUPPORTED_DOCUMENT_TYPESAPI-VAL-002niepre documentTypeId neexistujú validačné pravidlá
400DOCUMENT_VALIDATION_FAILEDSAPI-VAL-002niechyby XSD, Schematron, biznis pravidiel alebo strán; zoznam v error.details[] (field = umiestnenie, issue = popis, value = kód pravidla)
400RECEIVER_NOT_FOUNDSAPI-VAL-021niepríjemca nie je v Peppol (v sandboxe nie je sandbox participantom)
400UNSUPPORTED_DOCUMENT_TYPESAPI-VAL-021niepríjemca neponúka typ dokumentu a proces cez AS4
403AUTHORIZATION_FAILEDSAPI-AUTH-007nieparticipant z hlavičky alebo odosielateľ nepatrí vášmu tenantovi, alebo sa navzájom líšia
403AUTHORIZATION_FAILEDSAPI-AUTH-008nietenant nemá platnú licenciu
409IDEMPOTENCY_CONFLICTSAPI-VAL-010niekľúč použitý pre iný request — použite nový kľúč
409IDEMPOTENCY_IN_PROGRESSSAPI-VAL-010ánorequest s rovnakým kľúčom sa práve spracúva
503SERVICE_UNAVAILABLESAPI-PROC-002ánodočasne nedostupné SML/SMP, validácia alebo úložisko
500PROCESSING_ERRORSAPI-PROC-001ánoneočakávaná chyba
ℹ️Odchýlky od SAPI-SK v1.0: cesta /sapi/v1/document/send (špecifikácia: /sapi/v1/documents), identifikátor providerDocumentId (špecifikácia: apDocumentId), dokument v plochých poliach payload, payloadFormat, payloadEncoding (špecifikácia: document{content, format, encoding} — také telo skončí PAYLOAD_MISSING), navyše povinné hlavičky X-Peppol-Participant-Id a Idempotency-Key a kontroly 3–5 nad rámec minima špecifikácie. Odpovede 401 a 429 majú iba obálku error (bez status); 415, 405 a 406 majú formát Problem Details (RFC 9457) — rozhodujte podľa HTTP kódu.
GET v1 SAPI inbound

/sapi/v1/document/receive

Zoznam prijatých dokumentov participanta z hlavičky, najstaršie prvé, s kurzorovým stránkovaním.
Stránkovanie kurzorom
Prvé volanie bez pageToken. Hodnotu nextPageToken z odpovede pošlite ako query parameter pageToken ďalšieho volania; nextPageToken: null = posledná stránka. Kurzor je nepriehľadný reťazec — neparsujte ho ani neskladajte. Pre všetky stránky jedného prechodu zachovajte status, limit a hlavičku. Parameter nextPageToken sa prijme ako alias pageToken (ak pošlete oba, musia byť rovnaké).
Odporúčaný polling
  • pravidelne (napr. každú minútu) začnite od začiatku so status=RECEIVED
  • každý dokument stiahnite cez detail, uložte a potvrďte
  • potvrdené dokumenty z ďalšieho prechodu vypadnú; starý kurzor neodkladajte na neskôr
Stavy
RECEIVED — prijaté a zvalidované, ešte nepotvrdené
ACKNOWLEDGED — potvrdené (cez SAPI aj cez APEX API — stav je spoločný)
Bez filtra obe. Dokumenty odmietnuté pri validácii sa v zozname neobjavia. Zoznam vracia len metadáta, stav dokumentov nemení.
Typické chyby
  • 400 SAPI-VAL-001 — neplatný pageToken, rozdielne pageToken/nextPageToken, záporný limit
  • 400 (Problem Details) — chýba hlavička alebo limit nie je číslo
  • 401 SAPI-AUTH-002, 403 SAPI-AUTH-007 — participant nepatrí vášmu tenantovi
  • 429 SAPI-RATE-001
Parametre
Názov
Popis
Stav
X-Peppol-Participant-Id
Hlavička — participant príjemcu (krátky alebo kanonický tvar)
povinné
pageToken
Kurzor z nextPageToken predchádzajúcej odpovede
voliteľné
limit
Veľkosť stránky, predvolene 20; odporúčame najviac 100
voliteľné
status
RECEIVED alebo ACKNOWLEDGED
voliteľné
Výstupné polia
Názov
Popis
documents[].documentId
UUID dokumentu v APEX (pre detail a potvrdenie) — nie číslo faktúry
documents[].documentTypeId, processId
Peppol typ dokumentu a proces
documents[].senderParticipantId, receiverParticipantId
Kanonický tvar iso6523-actorid-upis::…
documents[].creationDateTime
Kedy APEX dokument prijal (nie dátum vystavenia faktúry)
nextPageToken
Kurzor ďalšej stránky alebo null
GET v1 SAPI inbound

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

Detail prijatého dokumentu: metadáta a celý StandardBusinessDocument (SBDH obálka s biznis dokumentom) ako XML reťazec.
Payload
payload je StandardBusinessDocument tak, ako prišiel sieťou Peppol, znovu serializovaný — prefixy menných priestorov a formátovanie sa môžu líšiť od originálu. Biznis dokument nájdite podľa menného priestoru, parsujte s ohľadom na menné priestory a nevalidujte koreň priamo voči UBL XSD. Stiahnutie stav nemení.
Typické chyby
  • 404 (prázdne telo) — ID nie je UUID alebo dokument neexistuje
  • 403 SAPI-AUTH-009 — dokument nie je adresovaný participantovi z hlavičky
  • 400 SAPI-DOC-002 — nejde o prijatý dokument vášho tenanta
  • 401 SAPI-AUTH-002, 429 SAPI-RATE-001
Výstupné polia
Názov
Popis
receivedAt
Kedy APEX dokument prijal
metadata
Rovnaký objekt ako v zozname (documentId, documentTypeId, processId, senderParticipantId, receiverParticipantId, creationDateTime)
payload
StandardBusinessDocument ako UTF-8 XML reťazec
payloadFormat
XML
POST v1 SAPI inbound

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

Potvrdenie, že váš systém dokument bezpečne prevzal. Stav prejde na ACKNOWLEDGED. Idempotentné.
Kedy službu volať
  • až po stiahnutí detailu, spracovaní XML a trvalom uložení dokumentu
  • ak niektorý krok zlyhal, nepotvrdzujte — dokument zostane v status=RECEIVED
  • opakované potvrdenie vráti 200 s pôvodným časom potvrdenia
Typické chyby
  • 404 (prázdne telo) — dokument neexistuje alebo nie je váš
  • 403 SAPI-AUTH-009 — dokument nie je adresovaný participantovi z hlavičky
  • 409 SAPI-DOC-002 — ide o odoslaný, nie prijatý dokument
Parametre
Názov
Popis
Stav
documentId
documentId zo zoznamu (path); telo sa neposiela
povinné
X-Peppol-Participant-Id
Hlavička — príjemca dokumentu
povinné
Výstupné polia
Názov
Popis
documentId
Potvrdený dokument
status
ACKNOWLEDGED
acknowledgedDateTime
Čas (prvého) potvrdenia, ISO 8601 s posunom
Kľúčové pojmy, stavy a identifikátory
Základné pojmy, ktoré potrebujete pri každej integrácii: rozdiel medzi rozhraniami, tvary identifikátorov, životné cykly dokumentov, validácia a odpovede v sieti Peppol.
APEX API (/api/v1, /api/v2) je plné REST API: odosielanie (aj hromadné), príjem, validácia, precheck, stav, udalosti, odpovede (MLR/IMR/MLS), webhooky a MQTT, vyhľadanie participantov, štatistiky a licencia. Token z ASOL IAM (client_credentials).

APEX SAPI (/sapi/v1) je zjednodušené rozhranie podľa slovenskej špecifikácie SAPI-SK v1.0: odoslať, prijať, potvrdiť. Odosielanie je tiež asynchrónne — ACCEPTED znamená prevzatie, nie doručenie — ale všetky kontroly (dokument, príjemca v Peppol) prebehnú synchrónne v rámci requestu. Vlastné auth endpointy s refresh tokenom; ten istý access token funguje aj na APEX API.

QHUB je asynchrónna integrácia cez RabbitMQ pre systémy v ekosystéme ASOL a ERP s messaging vrstvou — pozri Integračnú príručku.

Rozhrania sa dajú kombinovať: napr. odosielanie cez SAPI a sledovanie doručenia cez /api/v1/documents/{id}/status alebo webhooky.
Peppol participant ID jednoznačne určuje účastníka siete. Krátky tvar <ICD>:<hodnota> (napr. 0245:2024000001) a kanonický tvar iso6523-actorid-upis::0245:2024000001 sú v requestoch zameniteľné. Odpovede v1 inboxu a notifikácie používajú kanonický tvar, v2 inbox a lookup krátky.

Slovensko: schéma 0245 (SK:DIČ) — DIČ má 10 číslic bez prefixu SK. Ďalšie bežné schémy: 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 organizácie) nie je Peppol identifikátor; /participants/lookup/ico ho cez Register účtovných závierok preloží na DIČ.
QUEUED → PROCESSING → DELIVERED (→ prípadne FAILED po negatívnom MLS)
pri chybe prenosu: PROCESSING → RETRYING → PROCESSING → … → DELIVERED alebo DEAD_LETTER

QUEUED — prevzatý, čaká vo fronte • PROCESSING — prebieha AS4 prenos • DELIVERED — prijímajúci AP potvrdil prijatie (AS4 receipt) • RETRYING — čaká na ďalší pokus • DEAD_LETTER — pokusy vyčerpané alebo trvalá chyba, treba zásah • FAILED — negatívny Peppol MLS od prijímajúceho AP • REJECTED — licencia neplatná v čase odosielania. Hodnota SENT je v číselníku, pri odosielaní sa však nepoužíva.

Chybu validácie, neznámeho príjemcu či cudzieho odosielateľa API vráti hneď v odpovedi — taký dokument vôbec nevznikne.

DELIVERED znamená doručenie do prístupového bodu príjemcu (Peppol corner 3), nie spracovanie v jeho ERP — to signalizujú až aplikačné odpovede (IMR) a MLS.
APEX API: VALIDATED (validácia prešla, čaká na stiahnutie, notifikácia DOCUMENTS_RECEIVED) → ACKNOWLEDGED (váš systém potvrdil). REJECTED = dokument neprešiel validáciou (je v zozname, notifikácia nepríde), FAILED = chyba spracovania. RECEIVED je len vnútorný medzistav počas príjmu.

SAPI: zjednodušený model RECEIVED (prijaté a zvalidované, čaká na potvrdenie) → ACKNOWLEDGED; zamietnuté dokumenty SAPI nezobrazuje. Potvrdenie je spoločné pre APEX API aj SAPI.

Duplicitne doručenú AS4 správu APEX rozpozná a druhýkrát ju neuloží.

Technický stav prevzatia (Peppol MLS, Message Level Status) posiela odosielajúcemu poskytovateľovi APEX vo vašom mene — negatívny vždy, pozitívny, ak oň odosielateľ požiadal. Vy sa staráte len o obchodnú odpoveď (napr. IMR), ak ju váš proces vyžaduje.
1. XML Schema (XSD) — štruktúra podľa UBL 2.1
2. EN 16931 Schematron — európska norma e-fakturácie (povinné polia, číselníky, výpočty)
3. Peppol BIS pravidlá — pravidlá Peppol nad rámec EN 16931 (napr. PEPPOL-EN16931-R*)

Validačná sada sa vyberá podľa documentTypeId a cbc:CustomizationID: Peppol BIS Billing 3.0 (faktúra, dobropis, samofakturácia), národné varianty PINT, nemecká XRechnung, objednávky (Order, Order Response) a ďalšie Peppol BIS dokumenty. Pri viacerých verziách tej istej sady sa použije najvyššia. Rovnaká validácia beží v /validate, /precheck, /send, dávkach aj SAPI.
MLS (Message Level Status, urn:peppol:edec:mls) — technický stav správy, ktorý posiela prijímajúci prístupový bod odosielajúcemu. APEX pri odosielaní žiada MLS pre každý dokument; pozitívny (AP/AB) → notifikácia MLS_RECEIVED, negatívny (RE) → dokument prejde na FAILED a príde MLS_RECEIVED_NEGATIVE. Príjem MLS je v sieti Peppol povinný od 28. 2. 2027 a odosielanie od 31. 3. 2027 — dovtedy ho niektoré prístupové body ešte nevracajú, chýbajúci MLS teda nie je chyba.
MLR (Message Level Response, BIS 36a / T71) — staršia aplikačná odpoveď prijatia/zamietnutia.
IMR (Invoice Response 3.0 / T111) — obchodné rozhodnutie odberateľa o faktúre.
ORDER_RESPONSE (BIS 28a), RECEIPT_ADVICE (BIS 30a).

Kódy: AP prijaté, RE zamietnuté, CA podmienečne prijaté, UQ otázka, IP v spracovaní. Všetky nájdete cez GET /api/v1/documents/{id}/responses.
Prijatý dokument (APEX API ublDocument, SAPI payload) je celý StandardBusinessDocument — obálka SBDH (http://www.unece.org/cefact/namespaces/StandardBusinessDocumentHeader) s UBL dokumentom vnútri, presne ako prišiel sieťou. Biznis dokument hľadajte podľa menného priestoru (napr. urn:oasis:names:specification:ubl:schema:xsd:Invoice-2), nie ako koreň.

Prefixy nie sú kontrakt. cac:, cbc: ani iné prefixy sa nemusia zhodovať medzi verziami ani v rámci jedného dokumentu — používajte namespace-aware parser (XPath s registrovanými menými priestormi, JAXB, XmlReader s NamespaceURI…).
POST /api/v1/documents/send — hlavička Idempotency-Key voliteľná; kľúč platí 24 h; porovnáva sa obsah (dokument a smerovacie metadáta).
POST /api/v1/batches — voliteľná, odporúčaná; kľúč neexpiruje; porovnávajú sa bajty tela (SHA-256).
POST /sapi/v1/document/send — povinná; kľúč platí 24 h; porovnáva sa payload a metadáta (odosielateľ, príjemca, typ, proces).

Spoločné pravidlá: ten istý kľúč + rovnaký request → pôvodná odpoveď (bez nového odoslania); rovnaký kľúč + iný request → 409 IDEMPOTENCY_CONFLICT; súbežne bežiaci request s rovnakým kľúčom → 409 IDEMPOTENCY_IN_PROGRESS (zopakujte neskôr). Odmietnutý request kľúč nespotrebuje. Pri timeoute vždy opakujte s tým istým kľúčom.
Ak AS4 prenos zlyhá (sieť, timeout, chyba prijímajúceho AP), dokument prejde do RETRYING a worker ho skúsi znova. Dokument má 5 pokusov; po 1. až 4. zlyhaní príde ďalší pokus o 30, 60, 120 a 240 s, piate zlyhanie znamená DEAD_LETTER — celkovo zhruba 7,5 minúty plus čas prenosov (AS4 timeout je 120 s). Trvalé chyby (napr. certifikát príjemcu nevydaný CA OpenPeppol) idú do DEAD_LETTER hneď. Každý pokus vytvorí udalosti QUEUE_PROCESSING_STARTED a pri zlyhaní QUEUE_PROCESSING_FAILED (Attempt n/5 failed, retry in …s: <príčina>). Dokument v DEAD_LETTER vyžaduje zásah — kontaktujte podporu s documentId; po náprave ho môže zaradiť znova (udalosť QUEUE_MANUAL_REQUEUE, bez notifikácie).

APEX navyše chráni prijímajúce prístupové body: keď cieľ opakovane zlyháva, odosielanie naň sa na 30 s preruší (circuit breaker) a dokumenty sa preplánujú bez spotrebovania pokusu. Tenanti sa vo fronte striedajú, takže jeden veľký odosielateľ nezablokuje ostatných.
SML (Service Metadata Locator) je DNS register siete Peppol: z Peppol ID určí, ktorý SMP spravuje údaje účastníka.
SMP (Service Metadata Publisher) publikuje, aké typy dokumentov a procesy účastník prijíma, URL jeho AS4 endpointu a certifikát prístupového bodu.

APEX výsledok lookupu príjemcu ukladá a obnovuje po uplynutí TTL (predvolene 5 dní) alebo po zlyhanom prenose. Uložený výsledok sa nevzťahuje na konkrétny typ dokumentu — ak príjemca medzitým zmenil registráciu, chyba sa môže prejaviť až pri prenose. Pred odoslaním APEX overuje, že certifikát prístupového bodu príjemcu vydala CA OpenPeppol a je platný.
Verzia je súčasťou cesty (/api/v1, /api/v2). Publikovaná verzia sa nikdy nemení spätne nekompatibilne — nový formát vzniká pod novou verziou a predchádzajúca funguje ďalej. Dnes má verziu v2 len príjem (GET /api/v2/documents/inbox a detail) — líši sa iba krátkym tvarom identifikátorov. Všetky ostatné endpointy sú len vo v1. Klienti majú ignorovať neznáme polia v odpovediach a neznáme hodnoty eventType.
Najčastejšie Peppol identifikátory typov dokumentov a procesov
DokumentdocumentTypeIdprocessId
Faktúra (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
Samofaktúra (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
Odpoveď 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
Odpoveď na faktúru (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) — posiela APEXurn:oasis:names:specification:ubl:schema:xsd:ApplicationResponse-2::ApplicationResponse##urn:peppol:edec:mls:1.0::2.1urn:peppol:edec:mls
Autentifikácia

OAuth 2.0 — Bearer token

Všetky endpointy okrem /sapi/v1/auth/token, /renew a /revoke vyžadujú hlavičku Authorization: Bearer <access_token>. Access token je JWT podpísaný (RS256) serverom ASOL IAM a získate ho grantom client_credentials (server-to-server, bez prihlásenia používateľa) — priamo z IAM, alebo cez SAPI endpoint, ktorý navyše vydá refresh token. Výsledný token je ten istý a platí pre APEX API aj SAPI.

Dva spôsoby získania tokenu
A) Priamo z ASOL IAMB) Cez SAPI
EndpointPOST https://iam.qasida.sk/oauth2/tokenPOST /sapi/v1/auth/token
Formátapplication/x-www-form-urlencodedapplication/json
Access tokenJWT, platnosť podľa expires_inten istý JWT z IAM
Refresh tokennie — nový token vždy cez client_credentialsáno, 30 dní, rotácia cez /sapi/v1/auth/renew
Odporúčané preAPEX API, Swagger UI (Authorize)SAPI integrácie podľa SAPI-SK v1.0

1. Token

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

2. Použitie

Authorization: Bearer <token> v každom requeste

3. Obnovenie

pred vypršaním nový client_credentials alebo /renew

4. Revoke

/sapi/v1/auth/revoke pre refresh token

🔑Dôležité: prístupové údaje (clientId, clientSecret) sú viazané na jednu organizáciu (tenanta) v APEX — token určuje, ku ktorým dokumentom a participantom máte prístup. Access token obnovujte s rezervou (napr. 1–3 min pred expires_in), jeden token používajte pre všetky requesty počas jeho platnosti a pri 401 si vyžiadajte nový. APEX overuje token lokálne (podpis a platnosť), revokácia access tokenu ho preto pred vypršaním nezruší. Parameter scope nie je potrebný — prístup určuje tenant.
Príklad autentifikácie
Token request a použitie
A) Token priamo 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 cez SAPI (s refresh tokenom)
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..."
}
Obnovenie cez SAPI
POST /sapi/v1/auth/renew
Content-Type: application/json

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

Chyby, limity a bezpečnosť

Ako vyzerajú chybové odpovede, ktoré chyby má zmysel opakovať, aké limity platia a na čo si dať pozor pri návrhu klienta. Rozhodujte vždy podľa HTTP kódu a strojového kódu chyby, nie podľa textu správy.

APEX API — /api/**
Formát chyby
JSON objekt s poľami timestamp, status, error, message a spravidla path. Strojový code majú dávky a idempotencia (INVALID_IDEMPOTENCY_KEY, IDEMPOTENCY_CONFLICT, IDEMPOTENCY_IN_PROGRESS, BATCH_*, PARTICIPANT_NOT_AUTHORIZED, LICENCE_INVALID, TOO_MANY_OPEN_BATCHES); pri ostatných chybách je message len informatívny text. /documents/send pri zlyhanej validácii vracia error: "Validation Error" s validationErrors[] a validationWarnings[] (code, message, location). Chyby frameworku (nečitateľný JSON, zlý typ parametra, chýbajúci parameter, 405/415) majú formát Problem Details (type, title, status, detail, instance). 404 pre neexistujúci alebo cudzí zdroj má prázdne telo. timestamp je bez časovej 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[] (alebo null), retryable a correlation_id (uveďte ho podpore). Odmietnutie odoslania ho obaľuje do status: REJECTED s errorCode. Odpovede 415, 405, 406 a chýbajúca hlavička pri príjme majú formát Problem Details (RFC 9457); 404 pri detaile a potvrdení má prázdne telo.
{
  "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 čo s nimi
HTTPVýznamČo urobiť
200 / 201 / 202 / 204Úspech; 202 = prevzaté na asynchrónne spracovaniePri 202 sledujte stav (/status, notifikácie)
400Neplatný request alebo dokument. Špeciálny prípad: Invalid UUID string: anonymousUser znamená token bez tenanta (napr. token používateľa namiesto integračného klienta)Opravte request; neopakujte bez zmeny
401Chýbajúci, neplatný alebo expirovaný token (hlavička musí začínať presne Bearer )Získajte nový token a request zopakujte raz
403Participant nepatrí vášmu tenantovi, neplatná licencia, tenant z tokenu nie je v APEX založený (Authenticated tenant not found)Skontrolujte Peppol ID, licenciu (/api/v1/licenses/info) a prístupové údaje
404Zdroj neexistuje alebo patrí inému tenantovi (zámerne nerozlíšené)Skontrolujte ID a prostredie
409Konflikt idempotencie, stav neumožňuje operáciuIDEMPOTENCY_IN_PROGRESS zopakujte neskôr; ostatné riešte
413Príliš veľká dávkaRozdeľte dávku
415Nesprávny Content-TypePosielajte application/json (ZIP dávka application/zip)
429Prekročený rate limit alebo kapacita príjmu dávokPočkajte podľa Retry-After, potom exponenciálny odstup
500 / 503Neočakávaná alebo dočasná chybaOpakujte s exponenciálnym odstupom a tým istým Idempotency-Key
Rate limiting
EndpointyLimit
POST /sapi/v1/document/send100 requestov / min / IP (vlastný limit)
všetky ostatné /api/** a /sapi/** (vrátane /sapi/v1/auth/*)200 requestov / min / IP (spoločný limit)
Limit sa počíta pre zdrojovú IP adresu (token bucket s priebežným dopĺňaním — krátky nárazový burst je povolený, potom cca limit/60 za sekundu). Každá odpoveď nesie hlavičky X-RateLimit-Limit a X-RateLimit-Remaining; pri 429 aj Retry-After (sekundy do ďalšieho voľného requestu). Rate limit sa vyhodnocuje pred autentifikáciou, takže sa počítajú aj neúspešné requesty. Hromadné odosielanie má navyše vlastné limity (3 otvorené dávky, BATCH_INTAKE_BUSY).
HTTP 429
Odpoveď pri prekroč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"
  }
}
Pri /api/** má telo 429 tvar chyby APEX API: {"timestamp", "status": 429, "error": "Too Many Requests", "message", "path"}. Limity sa uplatňujú pre každú inštanciu služby samostatne — berte ich ako horný orientačný limit, nie ako garantovanú kapacitu.
Odporúčania pre robustného klienta
Opakovanie a idempotencia
Pri 429, 500, 503 a timeoute opakujte s exponenciálnym odstupom (napr. 2, 4, 8, 16 s + náhodný jitter). Odosielacie requesty posielajte vždy s Idempotency-Key a pri opakovaní s tým istým kľúčom — tak faktúru nikdy neodošlete dvakrát.
Tolerantné parsovanie
Ignorujte neznáme polia v JSON a neznáme hodnoty eventType či stavov — API sa rozširuje spätne kompatibilne. Časy parsujte ako ISO 8601 s posunom a porovnávajte okamihy, nie reťazce (počet desatinných miest sa líši). XML payload parsujte s ohľadom na menné priestory.
Bezpečnosť
Len HTTPS. clientSecret, refresh token a MQTT heslo ukladajte v trezore tajomstiev, nie v kóde ani logoch. Webhooky nie sú podpísané — overujte ich tajomstvom v customHeaders a obsah si vždy načítajte z API podľa documentId. Notifikácie berte ako signál, nie ako zdroj pravdy.
Príklady

Request / Response príklady

Konkrétne requesty a odpovede pre kľúčové scenáre. $APEX je základná URL prostredia (napr. https://api.sandbox.apex.qasida.sk), $TOKEN access token. XML dokumenty sú v príkladoch skrátené.

POST /api/v1/documents/send
Odoslanie faktúry
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 pred odoslaním
Response — pripravené na odoslanie
{
  "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 — príjemca nie je v 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
Vyhľadanie participanta
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
História dokumentu
Response (skrátené)
[
  {
    "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 notifikácia
Request
{
  "name": "ERP Invoice Inbox",
  "description": "Notifikácie o nových faktúrach",
  "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": "zdielane-tajomstvo" }
}
Notifikácia, ktorú 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: zdielane-tajomstvo

{
  "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}
Stiahnutie prijatej faktúry
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>"
}
Potvrdenie 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 notifikácia 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 odoslanie
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 — príjemca nie je v 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"
  }
}