End-to-end delivery in sandbox

The sandbox is connected to the real OpenPeppol TEST network via SMK, the same central metadata lookup production uses, pointed at the Peppol test SML zone (participant.sml.test.tech.peppol.org) with test PKI. 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 — and the AS4 transport really leaves the sandbox: the sender resolves the receiver through SMK and delivers to whatever access point is actually published there, exactly like a live send.

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

Delivery depends on where the receiver is published, not on whether it's "a sandbox company". A sandbox company can only receive once its Peppol participant has been published on the Peppol TEST network — and the sandbox does this automatically: every sandbox company gets a derived identifier 9950:sk<IČ DPH>efakturujtest at creation and it is published automatically within ~15 minutes. One exception: identifiers under the official DIČ scheme 0245:… cannot be auto-published — the Slovak central SMP requires a PDS verification code for that scheme, so 0245 publication is arranged by eFakturuj (contact support or your onboarding contact). Sending, on the other hand, works right away against any receiver that's already published — a test participant belonging to another provider (ePoštár, Fitek, a customer's own test setup, ...), or one of your own sandbox companies once it has been published. If the receiver only exists in production (the live Peppol network), the send still reaches SENT, but nothing arrives: the TEST network is a separate SML zone with separate PKI, so it cannot reach production participants. That's by design — test traffic must never reach the production Peppol network.

A sandbox document is deliverable to any receiver published on the Peppol TEST network: a sandbox company (once its participant is published — see above), a test participant of your own you've registered there, or another provider's test participant. The full flow works end-to-end, including the receive side, once the receiver is published — you don't need an external partner to see it work: the recipe below is the fastest way to run a complete send → receive round trip using nothing but two companies in your own sandbox account, provided the receiving company's participant has already been published.

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 9950:sk2020222222efakturujtest.

Publication is automatic and happens within ~15 minutes of registration (for 9950:sk…-style identifiers; 0245:… needs eFakturuj to arrange publication — see above). Check the company's detail screen for the publication status badge. Both directions now depend on publication: outbound sends (step 3) pre-flight the receiver's presence in the SML and fail fast with recipient_not_registered_in_sml when the receiver is provably unpublished (an inconclusive lookup still sends), and the receive side (step 5) needs the receiving participant published. If you see "Publication failed", use the "Publish again" button to retry.

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: 9950:sk2020111111efakturujtest' \
  -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: 9950:sk2020111111efakturujtest'

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: 9950:sk2020222222efakturujtest'

curl -X POST https://api.sandbox.efakturuj.sk/sapi/document/receive/$DOCUMENT_ID/acknowledge \
  -H "Authorization: Bearer $RECEIVER_TOKEN" \
  -H 'X-Peppol-Participant-Id: 9950:sk2020222222efakturujtest' -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`

Interop testing with other providers

You don't need to stay inside your own sandbox account. If you know another provider's TEST Peppol ID — a customer's own test participant, or another provider's test sandbox — send to it directly, no different from sending to one of your own sandbox companies. SMK resolves the AS4 endpoint for real, so SENT_PEPPOL on your side means the document is actually in flight to them. For them to send back to your sandbox participant, that participant must likewise be published in SMK, pointing at https://peppol-test.efakturuj.sk/as4 — which the sandbox does automatically for its derived 9950:sk…efakturujtest identifiers when the company is created.

Sending to production participants

Documents addressed to a production Peppol ID — a company's real, live Peppol identity, not a sandbox or TEST-network participant — are accepted, validated, and processed to SENT — exactly like a real send — but delivery goes nowhere. The sandbox only ever resolves receivers through the Peppol TEST SML/SMK, a completely separate zone from production with its own PKI that production access points don't trust. Use this to exercise your submit and status-polling logic against realistic identifiers with zero delivery risk. When you intend an actual delivery to a real recipient, use production.