For Software Vendors and Resellers

You build invoicing, ERP or accounting software — or you run e-invoicing for many client companies — and each of your customers needs to send and receive e-invoices under its own name. This page shows how that maps onto GoRoute.

For the commercial side (revenue share, white-label pricing), see the partner programme and white-label platform pages.

The model: one organisation per customer, beneath yours

Your partner organisation
├── Customer A  (own organisation, own API key, own Peppol participant)
├── Customer B
└── Customer C

• Each customer is its own GoRoute organisation, created beneath your partner organisation. Its documents, participants, webhooks and users are its own.
• An API key belongs to exactly one organisation. You hold one key per customer and pick the key, not a header, when you act for that customer. There is no "act as" header for API keys. See Organizations & multi-tenancy.
• You can see across your customers with the group views (below), while each customer sees only its own data.

1. Create the customer's organisation

Customer organisations are created in the GoRoute partner console (admin.goroute.ai → Onboard Client), signed in with your partner account. There is no public API that creates organisations; if you onboard customers at volume, talk to us about provisioning.

What the form asks for:

Field	Notes
Company name	The legal entity behind the customer's Peppol registration.
Country	Required. An ISO 3166-1 alpha-2 code.
Package	Required for a customer under your organisation — the plan you sell them.
VAT number, CR number, address, contact	Recommended. A VAT number you enter is stored unconfirmed: it does not become a sending identity until GoRoute has registered the customer's participant.
Integration mode	Portal (the customer gets a login, by activation link) or API only.
First user	Name and email of the customer's first portal user, unless API only.

You cannot set the customer's Peppol participant ID yourself; GoRoute assigns it when the participant is registered (step 3). The new organisation inherits your organisation's domains and features, and your branding unless it sets its own.

The console shows the customer's API key once. Store it like any other credential: encrypted, never in source control, mapped to your internal customer ID.

2. Give the customer's key the right scopes

The key issued at onboarding has the read, write and send scopes. That is enough to send documents and read transactions. Registering a participant and creating webhooks need the integrate scope (participants:manage, webhooks:manage), which that key does not carry.

Create a second key for the customer with POST /api/v1/api-keys, calling as the customer — from their portal account (org owner, org admin or developer role) or with a key that already holds the admin scope:

{
  "name": "YourProduct integration",
  "scopes": ["read", "write", "send", "integrate"]
}

Or ask GoRoute support to issue it with the onboarding.

3. Register the customer on Peppol

With the customer's key, create the participant and register it — the same calls a direct customer makes. See Registration.

participant = requests.post(
    f"{BASE_URL}/api/v1/participants",
    headers={"X-API-Key": CUSTOMER_KEY},
    json={"scheme": "0208", "identifier": "0123456789",
          "display_name": "Customer A BV", "country": "BE"},
).json()

requests.post(f"{BASE_URL}/api/v1/participants/{participant['id']}/register",
              headers={"X-API-Key": CUSTOMER_KEY})

Register the participant in the customer's organisation, never in yours. An identifier active in an organisation outside the caller's own tree is refused with 409 PARTICIPANT_HELD_BY_ANOTHER_ORG (the holder is not named). Your partner organisation sits above the customer, which is outside the customer's tree — so if you register a customer's identifier under your own key, the customer can never register it under theirs.

Country steps you will meet:

• Norway (0192) — the first publication needs the signatory's authority (fullmakt). An API key always receives 409 NO_AUTHORITY_REQUIRED with the role holders; upload the signed authority with POST /api/v1/participants/{participant_id}/authority. See the Norway guide.
• Oman (0248) — the taxpayer must first accept GoRoute as its service provider on the Fawtara Portal. See SMP registration.
• A customer moving from another provider follows Migrating Access Points.

4. Send for a customer

Use the customer's key. The transaction is then recorded in the customer's organisation: it appears in their history and fires their webhooks.

requests.post(
    f"{BASE_URL}/api/v1/documents",
    headers={"X-API-Key": CUSTOMER_KEY, "Idempotency-Key": invoice_number},
    json={"receiver_scheme": "0208", "receiver_id": "9876543210", "document": ubl_xml},
)

If your product holds invoice data rather than XML, use POST /api/v1/invoices the same way.

Sending with your own partner key is allowed when you name a participant that belongs to an organisation beneath yours — the sender check accepts any active participant in your tree. But the transaction is then recorded in your organisation, not the customer's, so their history and webhooks will not show it. Prefer the customer's key.

A sender outside your tree, or a customer organisation's Peppol ID with no active participant behind it, is refused with "Sender … is not an active participant of this organization or of an organization it manages" (SENDER_NOT_ENTITLED; on POST /api/v1/documents it arrives as 400 INVALID_REQUEST).

5. Webhooks per customer

Webhooks belong to one organisation, and a customer's events are delivered only to that customer's subscriptions — never to yours. Register one subscription per customer, with the customer's integrate-scoped key:

POST /api/v1/webhooks
{
  "url": "https://yourproduct.example/webhooks/goroute/customer-a",
  "events": ["transaction.delivered", "transaction.failed", "transaction.received"]
}

A distinct URL per customer makes failures easy to attribute. Event names, payloads and signature checks: Webhooks.

Reporting across your customers

Your partner key can read across the organisations beneath you:

Call	What you get
GET /api/v1/transactions?scope=group	Transactions of your organisation and every active organisation beneath it, each row with an entity.
GET /api/v1/transactions/stats?scope=group	The same totals across the group.
GET /api/v1/transactions/history?scope=group	The same history across the group.
GET /api/v1/compass/portfolio	A compliance findings roll-up per direct customer.
GET /api/v1/compass/group/transactions	Compass reconciliation across the whole group.

scope=group is refused with 400 NOT_A_GROUP when your organisation has no customers beneath it, and 400 GROUP_VIEW_DISABLED when the group view is switched off for your account. These are reads only: there is no cross-organisation write.

Signed-in partner users can also open a customer's portal read-only from the header's entity switcher. That is a portal feature and does not apply to API keys.

Branding

• Invoice branding (logo, colour, footer on the invoice PDF) is per organisation: GET/PUT /api/v1/settings/company/branding. A customer that sets nothing inherits yours.
• Your white-label portal (your domain, logo and colours on the portal your customers log in to) is set up with GoRoute. See the white-label platform.

Your customers then see your brand. GoRoute's Peppol accreditation (POP000991) stays GoRoute's: do not present it as your own.

Prove your integration

When your integration works end to end, pass the five sandbox scenarios in Partner Verification to earn the GoRoute Verified badge for your product.

Checklist

• One organisation per customer, created in the partner console.
• Each customer's key stored encrypted and mapped to your customer ID.
• An integrate-scoped key per customer for participants and webhooks.
• The customer's participant registered in the customer's organisation.
• Documents sent with the customer's key, with an Idempotency-Key.
• One webhook subscription per customer.
• Tested end to end on the test environment with 9999:test-… recipients.