Authorization
The API supports four authorization methods. Choose the one that best fits your integration scenario.
1. Simple — Client Credentials
Best choice when you are integrating the API directly into your own application and you act on behalf of yourself. There is no user-facing OAuth redirect — you exchange your API key for a short-lived bearer token and attach it to every request.
- Open Settings / API Key in the application and copy your
client_idandclient_secret. - Request a token:
POST /api/auth/token Content-Type: application/x-www-form-urlencoded grant_type=client_credentials &client_id=YOUR_CLIENT_ID &client_secret=YOUR_CLIENT_SECRET &scope=send_documents receive_documents
- Use the returned
access_tokenas aBearertoken in subsequent requests:Authorization: Bearer <access_token>
- When the access token expires, use the
refresh_tokenfrom the same response to obtain a new token pair without re-entering your credentials:POST /api/auth/renew Content-Type: application/json { "refresh_token": "YOUR_REFRESH_TOKEN" }Alternatively, simply request a brand-new token by repeating step 2 with yourclient_idandclient_secret.
2. Simple OAuth — Authorization Code (own application)
Best choice when you are integrating into your own application but want to use the standard OAuth 2.0 Authorization Code flow. The user (you) will be redirected to a consent screen and asked to grant the requested permissions. This is useful when you want the token to be tied to an interactive session.
- Open Settings / API Key and copy your
client_idandclient_secret. Set a redirect URI there. - Redirect the user to the authorization endpoint:
GET /api/auth/authorize ?response_type=code &client_id=YOUR_CLIENT_ID &redirect_uri=https://your-app.example.com/callback &scope=send_documents receive_documents &state=RANDOM_STATE
- The user grants access. Exchange the returned
codefor a token:POST /api/auth/token Content-Type: application/x-www-form-urlencoded grant_type=authorization_code &code=RETURNED_CODE &redirect_uri=https://your-app.example.com/callback &client_id=YOUR_CLIENT_ID &client_secret=YOUR_CLIENT_SECRET
3. Normal OAuth — Developer Application
Best choice when you are building a multi-tenant application that will be used by your own customers. Each customer logs in with their own account and explicitly grants your application access to their data. You act on their behalf using the token they issue.
- Navigate to /developers/ and create a new Developer Application. You will receive a dedicated
client_idandclient_secretfor that application. - Redirect your customer to the authorization endpoint (same as above), but using the Developer Application credentials and the scopes your application needs.
GET /api/auth/authorize ?response_type=code &client_id=YOUR_DEVELOPER_APP_CLIENT_ID &redirect_uri=https://your-app.example.com/callback &scope=send_documents &state=RANDOM_STATE
If you already know which company you want to connect, pass one of the following to pre-select it on the consent screen — the user will see that participant highlighted/pre-filled:
Parameter(s) When to use Example euVatId You know the company's EU VAT ID. Checked first; rn/countryCodeare ignored when a match is found.&euVatId=CZ12345678 rn + countryCode You know the company's registration number and country. Both parameters are required together. &rn=12345678&countryCode=CZ Matching is case-insensitive and whitespace-normalized. If no participant in the user's account matches, the consent screen shows all available participants and no pre-selection is applied.
- The customer is shown a consent screen bound to their account and grants your application access.
- Exchange the authorization code for a token. The issued token is scoped to the customer's account and the permissions they approved.
4. Affiliate ID — Lightweight Lookup Access
A simplified credential intended for read-only public lookups (e.g. checking whether a participant is registered in Peppol). The affiliateId is a UUID that can appear in URLs and referrer headers — it is treated as semi-public. Its main purpose is protection against anonymous abuse and DoS attacks, not strict authentication.
Pass it as a query parameter to lookup endpoints:
GET /api/lookup?affiliateId=YOUR_AFFILIATE_UUID&...
affiliateId for write operations or for accessing private account data. Use one of the token-based methods above for anything beyond public lookups.Permissions (Scopes)
When requesting a token you specify one or more scopes. The following scopes are available:
| Scope | Description |
|---|---|
| admin | Full editing of everything. |
| read_participant_info | Read participant information (email, registration number, etc.). |
| send_documents | Create and send new documents. The application can only access documents it created itself. |
| receive_documents | Access new incoming documents that have not been processed yet. |
| receive_all_documents | Access all incoming documents regardless of their processing state. |
| read_all_documents | Read all documents, including those sent by other applications. |
Request only the scopes your integration actually needs. Tokens issued via the Developer Application flow are further limited to the scopes the customer approved on the consent screen.