Test your integration safely in an isolated environment before going to production. A test account gives access to the same API as production, but documents remain on the Peppol test network and never reach real recipients.
Request a test account
View the API documentation
The sandbox is the acceptance environment of the Procurement Service Bus (PSB). You validate, send and receive documents there with the same API flow as in production. Token requests, API calls and webhooks behave identically. The difference is in the routing: documents sent from a test account remain within the Peppol test network and never touch the production Peppol network.
This allows you to test mapping, error handling, status logic and webhook flows without risk to customers or operational processes. Your test and production credentials remain strictly separated, so a test connection can never accidentally send a real invoice.
A clientId and clientSecret with which you request a Bearer token via the Identity Server. The Client Credentials flow is standard for server-to-server integrations.
Separate URLs for PSB API, Identity Server, VPD service and mailhook address. Strictly separated from production, so configuration errors have no impact on live traffic.
Validate API, Transform API, webhooks, Peppol registration via SMP/SML test, document sending and receiving. Everything works as in production.
A registered Peppol party on the test network with which you send and receive documents. No impact on your production registration.
After your application is approved, you get access to the complete acceptance environment and all associated endpoints.
A test account currently goes through sales and delivery. You contact us via the contact form or schedule an introductory meeting. Sales will discuss with you what type of integration you are building (custom integration, software connector, white-label PSB partner) and what the scope is; delivery then creates your credentials and test party.
During the conversation you discuss the architecture, the intended volume, any white-label or multi-tenant requirements, and whether you also want to prepare production credentials alongside acceptance. This prevents you from having to wait for new credentials again during your integration process.
eConnect is exploring a simplified application process for developers. Until then, every sandbox account follows the current onboarding process.
accp-psb.econnect.eupsb.econnect.euaccp-identity.econnect.euidentity.econnect.euaccp-vpd.econnect.eu/graphql/v1vpd.econnect.eu/graphql/v1@accp.econnect.email@econnect.emailAlways keep a clear separation in your configuration between which set you are using. Never confuse acceptance with production.
After a successful acceptance phase, you switch to production in a controlled way using the same integration patterns you have already tested. You don't build a second integration; you swap the endpoints and credentials. This keeps the release process predictable and short.
The usual route is: integrate against the sandbox, end-to-end testing (sending, receiving, statuses, error scenarios), set up monitoring and logging, and only then activate production credentials. For more complex deployments (white-label, high volumes, multiple document types), eConnect specialists support the transition.
There are no costs associated with requesting and using a sandbox account during an ongoing integration process. The environment is intended to bring your integration to production. You discuss the terms during the introductory meeting, together with the setup of your production account.
No. Documents sent from a sandbox account remain within the Peppol test network and never reach real production recipients. That is the whole purpose of the sandbox: you can test freely without accidentally sending a real invoice, order or status message.
For an end-to-end test that also affects other systems (for example, a receiving ERP), you can register your own receiving party in the sandbox and send documents to your own test party.
Yes. The sandbox is a complete acceptance environment. OAuth2 token flow, REST API calls, webhooks, validation, transformation, Peppol registration and mailhooks behave identically. The difference is in the credentials, the endpoints (accp- prefix) and the separation of Peppol traffic.
This means you can build in the sandbox until your integration is fully stable, and you don't need to expect any functional surprises during go-live. Follow the steps in the getting started guide for your first API call.
Your first working API call often takes less than a day. A complete integration until production-ready takes an average of two to four weeks, depending on scope, document types and internal test coverage. Many customers start with one defined use case (for example, sending sales invoices), bring that to production, and then expand step by step with purchase invoices, orders or self-billing.
No. You can request a sandbox without a production account, for example as a software supplier exploring a Peppol connection or as a white-label partner in an exploratory phase. During the process you establish when you need production credentials; these can be created separately or included in the same application.
Always keep two separate sets in your configuration: one for accp- endpoints with your sandbox credentials, one for production. Many teams use separate environment variables or secrets per environment and build in a check that prevents production credentials from being loaded during a test run. This pattern is further elaborated in authentication.
Request a test account and safely build your integration on the PSB acceptance environment.
Request a test account
Schedule an introductory meeting