Customer authorisation and participant registration

Accounting systems and other integrations manage their customers as companies in an eCourier team. Each company has its own authorisation agreement and can have multiple participants (network addresses). eCourier performs the network registration for the selected Peppol and/or NemHandel channels.

An API key gives your integration access to its team's resources. The customer company's authorisation is a separate requirement: new participants cannot be created through the API or portal until that company's authorisation is marked signed. This applies in both Test and Live.

Standard signing flow

1. Create the company with its legal name, country, company number, and signer.first_name, signer.last_name, and signer.title. Use a person authorised to act for that company.
2. Send the customer to the returned authorisation.sign_url. The eCourier page identifies your team, the customer company, and the signer, and links to the agreement for signing in eCourier.
3. Wait for authorisation.signed to become true. eCourier updates this flag once signing is complete. Read it using Company details.
4. Create the participant using that company's company_id, a scheme, an identifier, and the required channels.

You can supply an HTTPS redirect_url when creating the company. After signing, eCourier waits until the signed flag has been updated before redirecting the browser. Without a redirect URL, it shows a confirmation page. Your backend should still fetch company details before continuing onboarding. There is currently no customer-facing authorisation-completed webhook; the webhook events concern documents.

Signing links expire after 30 days. Fetch company details again to obtain a fresh link while the agreement remains unsigned. Once signed, sign_url is null.

Supplying your own signed agreement

This route requires a special agreement with eCourier and must be enabled for your team. Agree the authorisation document and signing process with eCourier before using it.

1. Create the customer company. For an enabled team, signer is optional at company creation, no eCourier agreement is created, and the response's authorisation is initially null.
2. Collect the customer's signed authorisation through your agreed process.
3. Upload the signed PDF to POST /v1/companies/{company}/authorisation/pdf as multipart/form-data, with pdf, signer[first_name], signer[last_name], and signer[title]. The PDF size limit is 1 MB.
4. A successful upload returns 201 with authorisation.signed: true and sign_url: null. You can then request participant creation.

The upload endpoint returns 403 if this feature is not enabled for the team. It returns 422 for invalid input or if the company already has an authorisation, including an unsigned one. It does not replace existing agreements; contact eCourier if an agreement needs to be corrected or replaced.

Signed, reviewed, and registered are separate states

State	Meaning
Authorisation missing or unsigned	New participant creation is blocked. The API returns 422 with The authorisation agreement must be signed before participants can be registered.
Authorisation signed	The signature requirement for creating a participant is satisfied. Other company, identifier, and channel checks still apply.
Participant created	The participant exists in eCourier and network registration is queued. A 201 response does not confirm that registration is active.
Network registration active	The registry has confirmed activation for the channel. The portal shows channel status and registration errors.

The participant API's channels array lists the configured channels; it does not expose their registration status. Use the portal to inspect activation and errors before treating the participant as ready to receive traffic.

The signed-authorisation check applies when creating a new participant. Updating an existing participant's channels does not start a new signing flow or recheck the signed flag. Removing a registered participant queues network deregistration; completion is asynchronous.

What the checks establish

eCourier scopes company and participant API operations to the API key's environment (pk_test and pk_live prefixes). It checks supported combinations of company country, identifier scheme, and channel, identifier format, and duplicate use within the platform. For schemes such as DK:CVR, the participant identifier must equal the company number.

Company creation validates the configured company-number format and, where supported, checks whether the number exists in a company registry. A definite “not found” result is rejected; an unavailable or unsupported lookup does not itself block creation.

These checks do not establish that a named signer has authority to represent the company. The PDF upload checks the file type, size, and supplied signer fields; it does not automatically verify the signature or the document's wording. Likewise, acceptance of a supplied GLN checks its format and existing use in eCourier, not external proof of the customer's entitlement to it. Your onboarding process should establish the customer's authority and right to use the submitted identifiers; do not treat a successful API response as confirmation of those facts.

See Workspace setup for the portal flow and API keys for team access.