Switching your Peppol provider to getpeppr

Move a Peppol address you already receive on from another provider to getpeppr: who holds it now, what to ask, the order to follow, and the short gap in reception.

How a switch works

A Peppol address (a participant identifier such as 0208:0123456789) is held by one access point at a time. The network's address book, the SML, points each address to the SMP of the provider that holds it, and senders follow that pointer to deliver.

To move an address, your previous provider first removes its registration, then getpeppr registers it. getpeppr cannot take over an address another provider still holds, and we do not support transfer by migration key: our Peppol provider registers an address only once the previous access point has removed it.

Plan for a short gap in reception. Between the removal and our registration, no access point holds your address, and Peppol has no central mailbox that keeps an invoice for you in the meantime. Whether the sender's provider retries later or reports a failure depends on that provider. See how long the gap lasts.

Find out who holds your address

Look the identifier up in our Peppol lookup. It reads the SML, the record senders actually follow: Registered with (SMP) names the SMP that holds the address, and Not registered on Peppol means nobody holds it.

The OpenPeppol lookup at lookup.peppol.org reads the same record, independently of us. Choose SML (OpenPeppol), the production network, enter the identifier as scheme:value, and read the SMP URL under SMP information. Participant Not Found means nobody holds it. On 2 October 2026 it gave the same answer as getpeppr's SML reader for six reference addresses: five on the production network, held by Storecove or by nobody, and one on the test network, held by another provider.

Don't rely on the Peppol Directory for this. The directory at directory.peppol.eu is a separate listing, updated on its own schedule. On 2 October 2026 it still listed an address of ours that had left the network 26 hours earlier, and not yet the address that replaced it. Our Peppol lookup uses it only for the company name and document types, and says when it is behind.

List every identifier your company is registered under. A company can have more than one, for example a company number (0208) and a VAT number (9925). An identifier left at the previous provider keeps receiving there.

Ask your previous provider to remove the registration

Send your previous provider a request like the one below, with your own identifiers and company details. Ask for a date and time: the gap starts when they remove the address, so the sooner you know it, the shorter you can keep it.

Removal request

Subject: Peppol — please remove our registration

Hello,

We are moving our Peppol e-invoicing to another provider. Please remove our
Peppol registration (SMP entry and SML record) for these participant
identifiers:

  - 0208:<your company number>
  - 9925:<your VAT number>

Company: <legal name>, VAT <your VAT number>

Please tell us the date and time at which you will remove it, and confirm
once it is done. We will check the result in the Peppol SML.

Thank you.

The order to follow

Platforms: request the authorisation at any time

For a customer you manage through the Legal Entities API, the order no longer matters. You can request the customer's authorisation before the previous provider removes the address:

1. Create the customer in production and wait until its identity is verified.
2. Request the authorisation (POST /v1/legal-entities/:id/attestation), and have the customer ask the previous provider to remove the address.
3. If the address is still held elsewhere when the customer confirms, the status becomes awaiting_release. While it waits, getpeppr's watcher runs every minute, re-reads the SML in bounded batches and registers the address once it finds it free.
4. The status moves on to active and you receive legal_entity.registered.

registrationDetail.heldBy names the SMP host that still holds the address, when it is a plain host name, and registrationDetail.waitingUntil says when getpeppr stops waiting: 30 days after the confirmation. Production only; the sandbox has no authorisation step.

Webhooks. An endpoint subscribed to * receives legal_entity.awaiting_release. An endpoint that lists event names explicitly receives it only after you add legal_entity.awaiting_release to its list.

If getpeppr has not completed the registration when the 30-day window ends, the status becomes provisioning_failed with registrationDetail.reason: "already_registered" and you receive legal_entity.registration_failed. Call POST /v1/legal-entities/:id/attestation again: getpeppr answers 202 and waits up to 30 more days, with no new email and no new confirmation from your customer. Details in the sub-tenant lifecycle.

Your own company: ask for the removal, add the identifier, getpeppr registers it once it is free

For the Peppol identity of your own account, getpeppr registers an identifier once its verification succeeds and the address is free. If another provider still holds it, getpeppr waits instead of failing, so you can add the identifier before or after the removal:

1. Ask your previous provider to remove the registration, and get its date and time.
2. Add the identifier in the console, under Peppol identity. See identity verification.
3. While the previous provider still holds the address, the identifier shows Waiting for release with that provider's SMP (awaiting_release in GET /v1/identity; production sends are refused with address_held_elsewhere). getpeppr checks again every 15 minutes and registers the address at the first check after it is free.
4. Check that it is registered (below), and that our Peppol lookup or lookup.peppol.org now shows Storecove's SMP, smp.peppol.storecove.com.

The gap is the same either way. No one can send to the address between its removal and its registration here. Adding the identifier early only means getpeppr is ready the moment it is free. If an identifier shows Registration failed instead, retrying will not change the outcome: contact support so we can resolve it.

How long the gap lasts

The gap starts when your previous provider removes the address and ends when getpeppr's registration reaches the SML. It has three parts:

When your previous provider removes the address. That timing is theirs, which is why the request asks for a date and time.
When getpeppr starts registering. For a platform customer in awaiting_release, at a later run of getpeppr's watcher, which runs every minute; how soon each customer is checked when many are waiting is not measured. For your own company, once you add the identifier and its verification completes.
How fast the registration reaches the SML. In the registrations we timed on 1 October 2026: 30 to 60 seconds on the test network, and under three minutes for one registration in production, verification included. We have not measured more than that.

The SML records carried a 60-second cache lifetime when we read them on 2 October 2026. A sender's access point may keep its own cache for longer; we cannot measure that.

Pick a quiet day, and tell the companies that invoice you most often: an invoice they send during the gap may need to be sent again.

Check before and after

In our Peppol lookup, or on lookup.peppol.org with SML (OpenPeppol) selected:

Before: the SMP is your previous provider's.
After the removal: Not registered on Peppol (Participant Not Found on lookup.peppol.org). The gap has started.
After the switch: the SMP is smp.peppol.storecove.com, the SMP of Storecove, the Peppol access point getpeppr runs on.

In getpeppr, a platform customer is done at active, which getpeppr sets only after finding the customer through the SML and its SMP the way another access point would. For your own company, read your identifiers, then confirm the routable address in our Peppol lookup or on lookup.peppol.org: an identifier can be set up at our provider without being a Peppol address, as a Norwegian VAT number is.

Your own company

import { Peppol } from "@getpeppr/sdk";

const peppol = new Peppol({ apiKey: "sk_live_..." });
const identity = await peppol.identity.get();

for (const id of identity.identifiers) {
  // "verified" or "no_registry": set up at our provider for this identifier — confirm the
  // routable address on lookup.peppol.org. "provisioning": under way.
  // "registration_failed": the network refused it — contact support.
  console.log(`${id.scheme}:${id.value} → ${id.status}`);
}

A platform customer

const le = await peppol.legalEntities.get(legalEntityId);

if (le.status === "awaiting_release") {
  // Authorised, but the previous provider still holds the address.
  // getpeppr's watcher runs every minute and registers it once it finds it free.
  const { heldBy, waitingUntil } = le.registrationDetail ?? {};
  console.log(`Held by ${heldBy ?? "another access point"} — waiting until ${waitingUntil}`);
}

France

In France, the previous accredited platform (PA) must remove everything it registered for the company, Peppol registrations and annuaire entries alike, before a new platform can take over. That is the rule of our Peppol provider, Storecove, and of its documentation for the annuaire.

The automatic wait above does not cover French annuaire addresses (0225). And in production, getpeppr does not yet register companies in the French annuaire: see the France guide for what is open today.

Platforms moving many customers

Each customer is a separate switch with its own gap. Create each one, request its authorisation, and let each previous provider remove its addresses on its own schedule: getpeppr watches every customer in awaiting_release separately and registers each one at a check after its address is free. Customers are processed in bounded batches, and we have not measured the throughput or how long a large batch takes: stagger the removals, and wait for each customer to reach active.

Send each customer, or each previous provider on its behalf, the removal request above, with every identifier the customer is registered under.
Follow the switches with the webhook events, or by reading status on GET /v1/legal-entities.
Retry a customer in provisioning_failed with the same authorisation call; getpeppr answers 202.

Webhook events of a switch

import { webhooks } from "@getpeppr/sdk";

const event = await webhooks.constructEvent(rawBody, signature, webhookSecret);
const data = event.data as { legalEntityId: string; heldBy?: string; reason?: string };

switch (event.type) {
  case "legal_entity.awaiting_release":
    // Tell your customer to chase the previous provider; nothing else to do.
    await notifyTeam({ waiting: data.legalEntityId, heldBy: data.heldBy });
    break;
  case "legal_entity.registered":
    // Reachable on Peppol at getpeppr: the switch is complete.
    await notifyTeam({ switched: data.legalEntityId });
    break;
  case "legal_entity.registration_failed":
    // reason "already_registered": the provider reported an existing registration,
    // or the 30-day window ended before the registration completed.
    await notifyTeam({ failed: data.legalEntityId, reason: data.reason });
    break;
}

Retry after provisioning_failed

const result = await peppol.legalEntities.requestAttestation(legalEntityId, {
  contactEmail: "owner@acme.example",
});
// 202 → { id: "…", externalId: "customer_8412", status: "provisioning" }
console.log(result.status);

France

Document Status