End-to-end delivery in sandbox

The sandbox is a closed delivery loop. Every outbound document is processed by the same pipeline as production — validation, UBL checks, the AS4 exchange, the SK Tax Data Document leg, the Finančná správa copy — but the AS4 transport delivers inside the sandbox only. Nothing is ever sent to a real Peppol Access Point.

That has one practical consequence people hit on their first test:

If you send a document to a real-world participant (a company hosted by ePoštár, Fitek, or any other provider), the API answers ACCEPTED, the status reaches SENT — and the real recipient never receives anything. That is by design: test traffic must not reach the production Peppol network.

A sandbox document is deliverable only to a receiver that exists in the sandbox — a sandbox company whose Peppol participant ID matches the receiverParticipantId of your send. Then the full flow works end-to-end, including the receive side.

Recipe: two sandbox companies

The complete loop takes under a minute to set up and about 30 seconds to run.

1. Create the receiving company

In the sandbox dashboard, create a second company (or reuse any company you already have — sending to yourself works too). Every company gets a Peppol participant ID from its master data at creation; you can see it in the company's settings and in the SAPI connector screen under allowed participants.

Note the receiver's participant ID — for example 9925:sk2020222222.

2. Get sender credentials

Install the SAPI-SK Connector on the sending company and copy its credentials (see SAPI-SK connector). SAPI routes are mounted at the API host root:

https://api.sandbox.efakturuj.sk/sapi

3. Send

curl -X POST https://api.sandbox.efakturuj.sk/sapi/auth/token \
  -H 'Content-Type: application/json' \
  -d '{"client_id":"…","client_secret":"…","grant_type":"client_credentials","scope":"document:send document:receive"}'

curl -X POST https://api.sandbox.efakturuj.sk/sapi/document/send \
  -H "Authorization: Bearer $TOKEN" \
  -H "Idempotency-Key: $(uuidgen)" \
  -H 'X-Peppol-Participant-Id: 9925:sk2020111111' \
  -d @send-payload.json
# → 202 { "providerDocumentId": "efk_sapi_doc_…", "status": "ACCEPTED" }

Set receiverParticipantId in the payload metadata to the participant ID from step 1.

4. Watch the sender side

curl https://api.sandbox.efakturuj.sk/sapi/document/status/$PROVIDER_DOCUMENT_ID \
  -H "Authorization: Bearer $TOKEN" \
  -H 'X-Peppol-Participant-Id: 9925:sk2020111111'

The status moves ACCEPTED → PROCESSING → SENT, the response gains a peppolMessageId, and the fs block shows the Finančná správa copy reaching SUBMITTED with a report deadline. Expect SENT within roughly 10–30 seconds; poll every few seconds.

5. Watch the receiver side

The receiving company sees the invoice in three places:

Web dashboard — the invoice appears in the company's received documents with status DELIVERED.

SAPI receive polling — install the SAPI-SK Connector on the receiving company too, then:

curl 'https://api.sandbox.efakturuj.sk/sapi/document/receive?limit=100&status=RECEIVED' \
  -H "Authorization: Bearer $RECEIVER_TOKEN" \
  -H 'X-Peppol-Participant-Id: 9925:sk2020222222'

curl -X POST https://api.sandbox.efakturuj.sk/sapi/document/receive/$DOCUMENT_ID/acknowledge \
  -H "Authorization: Bearer $RECEIVER_TOKEN" \
  -H 'X-Peppol-Participant-Id: 9925:sk2020222222' -d '{}'

Webhooks — an invoice.received event fires for the receiving company's registered endpoints (see Webhooks).

What each side sees

Where	Sender	Receiver
`GET /sapi/document/status/{id}`	✓ full lifecycle incl. FS copy	—
`GET /sapi/document/receive`	—	✓ list, detail, acknowledge
Web dashboard	connector-sent documents are not yet listed — the status endpoint is authoritative	✓ invoice visible as `DELIVERED`
Webhooks	document lifecycle events	`invoice.received`

Sending to real-world participants

Documents addressed to participants that don't exist in the sandbox are accepted, validated, and processed to SENT — exactly like production — but the transport stops at the sandbox boundary. Use this to test your submit and status-polling logic against realistic identifiers. When you intend an actual delivery to a real recipient, use production.