SMP Registration

The Service Metadata Publisher (SMP) is the directory that tells the Peppol network where to find you. When you register in the SMP, other participants can discover your capabilities and send you documents.

You do not need the API for this

SMP registration is fully self-serve in the browser: the registration wizard walks through business details, participants, Access Point choice (GoRoute's AP, your own, or another provider's) and document types, and the SMP Dashboard shows live network status, the published business card and document types, certificate expiry, and provides register / deregister / delete with confirmation dialogs. The API below is the machine equivalent of the same flow.

What is SMP?

The SMP stores:

1. Who you are — Your Peppol identifier
2. What you can receive — Document types and processes
3. How to reach you — Your Access Point's endpoint
4. Security info — Certificates for message encryption

┌───────────────────────────────────────────────────────────────┐
│                    SMP Record                                  │
├───────────────────────────────────────────────────────────────┤
│ Participant: 0106:12345678                                     │
│ ├── Document: Invoice-2                                        │
│ │   └── Process: BIS Billing 3.0                              │
│ │       └── Endpoint: https://ap.goroute.ai/as4                │
│ └── Document: CreditNote-2                                     │
│     └── Process: BIS Billing 3.0                              │
│         └── Endpoint: https://ap.goroute.ai/as4                │
└───────────────────────────────────────────────────────────────┘

How SMP Lookup Works

When GoRoute sends an invoice to a receiver:

1. Sender provides: 0106:12345678 (receiver ID)
          │
          ▼
2. GoRoute queries SML: Where is this participant's SMP?
          │
          ▼
3. SML returns: smp-goroute.acc.edelivery.tech (SMP URL)
          │
          ▼
4. GoRoute queries SMP: What are this participant's capabilities?
          │
          ▼
5. SMP returns: 
   - Document types: Invoice, Credit Note
   - Access Point: https://receiver-ap.example.com/as4
   - Certificate: [X.509 certificate]
          │
          ▼
6. GoRoute delivers invoice to receiver's Access Point

Registration Process

Step 1: Create Participant

First, create a participant record in GoRoute:

import requests

participant = {
    "scheme": "0106",
    "identifier": "12345678",
    "name": "My Company BV",
    "country": "NL",
    "email": "invoices@mycompany.nl"
}

response = requests.post(
    "https://app.goroute.ai/peppol-api/api/v1/participants",
    headers={
        "X-API-Key": "your_api_key",
        "Content-Type": "application/json"
    },
    json=participant
)

result = response.json()
print(f"Participant ID: {result['id']}")

Step 1a: Ask which document types are on offer

GET /peppol/doc-types lists the document types GoRoute is willing to publish for a country — the curated set. The doc_type_id values it returns are exactly the values you may put in the optional document_types list in Step 2. If you intend to register with the country defaults and nothing else, you can skip this step.

Two things about this endpoint that catch people out

• The path has no /api/v1 prefix. It is /peppol/doc-types, appended directly to the base URL. Every other endpoint on this site sits under /api/v1, so the natural guess is to add that prefix here too. Do not: this router sits outside the versioned prefix, and the prefixed path does not exist and returns 404.
• No API key is needed. This endpoint is public. It returns static configuration: the same information anyone already gets by looking up a registered participant in the SMP. Our machine-readable API description currently marks this path as requiring an API key. That is a mistake in the description, not a requirement of the endpoint, and it is recorded as a defect for engineering.

import requests

response = requests.get(
    "https://app.goroute.ai/peppol-api/peppol/doc-types",
    params={"country": "AU"},   # no API key
)

for entry in response.json()["doc_types"]:
    print("default" if entry["default"] else "opt-in ", entry["label"])

country is optional. Omit it and you get the set that applies to a country with no special profile, which today is the Peppol BIS Billing 3.0 invoice and credit note pair. Australia returns nine entries; here are two of them, taken from a real response:

{
  "country": "AU",
  "doc_types": [
    {
      "doc_type_id": "urn:oasis:names:specification:ubl:schema:xsd:Invoice-2::Invoice##urn:peppol:pint:billing-1@aunz-1::2.1",
      "process_id": "urn:peppol:bis:billing",
      "label": "PINT A-NZ — Invoice",
      "schemes": ["peppol-doctype-wildcard"],
      "default": true
    },
    {
      "doc_type_id": "urn:oasis:names:specification:ubl:schema:xsd:Order-2::Order##urn:fdc:peppol.eu:poacc:trns:order:3::2.1",
      "process_id": "urn:fdc:peppol.eu:poacc:bis:ordering:3",
      "label": "Peppol BIS Ordering 3.0 — Order",
      "schemes": ["busdox-docid-qns"],
      "default": false
    }
  ]
}

Field	Meaning
doc_type_id	The Peppol document type identifier. This is the value to send in document_types
process_id	The process identifier GoRoute publishes alongside it. You never send this yourself
label	A readable name, meant for a checklist or a dropdown
schemes	The identifier scheme or schemes this type is published under
default	true if a registration with no body publishes it; false if it must be asked for

One entry here can mean more than one entry in the SMP. The PINT A-NZ types are published twice each — once under the exact identifier and once under the wildcard one — but they appear as a single entry, because choosing a document type always keeps every variant it is published under. You select the document type, not the identifier.

Step 2: Register in SMP

POST /api/v1/participants/{participant_id}/register — requires the participants:manage permission.

{participant_id} is a UUID, not a Peppol identifier

The path parameter is the UUID of the GoRoute participant record returned by Step 1 — the id field. It is not the scheme:value Peppol identifier. Passing 0106:12345678 here fails.

Document types: country defaults, or an explicit selection

The request body is optional. With no body (or {}), GoRoute registers the participant's country default set:

• Australia and New Zealand: PINT A-NZ Invoice and Credit Note, published under the peppol-doctype-wildcard scheme only, each as two entries — the exact id (…@aunz-1::2.1) and the wildcard id (…@aunz-1*::2.1). This is the shape the PINT A-NZ Billing specification requires. Peppol BIS Billing 3.0 is not part of this set — for these two countries it is offered as an opt-in, and only for these two. See Document Capabilities for why one scheme and not two.
• All other countries: Peppol BIS Billing 3.0 Invoice and Credit Note under busdox-docid-qns, as the default.

Optionally send {"document_types": [...]} with ids from GET /peppol/doc-types?country=XX. A selection can only narrow the country's curated set — it never adds anything that is not on that set, and arbitrary identifiers are never published. Opt-in types exist for Australia and New Zealand: Peppol BIS Billing 3.0, PINT A-NZ Self-Billing, Peppol BIS Ordering 3.0 (Order and Order Response) and Peppol BIS Despatch Advice 3.0.

An explicit selection is the full desired set — document types you leave out are removed from the SMP, which is how "remove a document type" works. A registration with no body only ever adds.

An explicit document_types list deletes what you leave out

Sending a document_types list is not a filter on what gets added. It is a statement of everything the participant should advertise from now on. Any document type currently published for that participant and missing from your list is deleted from the SMP. Senders who relied on it will no longer be able to reach the participant with that document type.

Three consequences worth knowing before you send one:

• The removal is best-effort and does not fail the call. If a deletion is refused, it is reported back in removed_doc_types with an error status, and the rest of the registration still succeeds. A registration reported as successful can still contain a removal that did not happen — read the field, do not assume.
• The participant's stored record does not shrink. GoRoute merges newly registered types into the local document_types list rather than replacing it, so removed types remain in document_types and are still counted in total_doc_types. Checking the participant record after a narrowing registration will therefore make it look as though nothing was removed. removed_doc_types in the registration response is the truthful record; the local list is not.
• A list that matches nothing is refused, with a confusing status. If none of the ids you send exist in that country's curated set, nothing is left to register and the call fails with HTTP 502, error_code: SMP_REGISTRATION_FAILED, and a cause reading "None of the requested document types are available for country XX — nothing to register." The 502 is misleading here — nothing failed on the SMP, the request was simply unusable — but 502 is what the service returns today, so that is what is documented. It is recorded as a defect for engineering.

If you want to add capabilities without any risk of removing one, register with no body and then use the SMP Dashboard's Manage checklist, which shows you the current set before you change it.

Oman participants ignore a document_types selection entirely

Oman registrations go through the tax authority's own SMP, which fixes the document type set itself. GoRoute deliberately drops the selection rather than half-applying it, so an Oman participant sent a narrowing list gets the full Oman set and no error and no warning. Nothing is removed either. If you are managing Oman participants, do not use a selection to try to control what they publish; it will look as though it worked.

import requests

response = requests.post(
    f"https://app.goroute.ai/peppol-api/api/v1/participants/{participant_id}/register",
    headers={"X-API-Key": "your_api_key"},
)

result = response.json()
print(result["participant"], result["service_group"])
print(result["smp_registered"], result["sml_registered"], result["total_doc_types"])

The response reports what the SMP accepted:

Field	Meaning
participant	The scheme:value Peppol identifier
service_group	created, already_exists, or error_<status>
document_types	One entry per document type, each with doc_type_id, scheme and a status of ok or error_<status>
removed_doc_types	Present only when you sent an explicit document_types list. One entry per document type deleted from the SMP, each with doc_type and a status of removed or error_<status>
business_card	What happened to the participant's Business Card — the record that carries the company name across the network. See Business Card below
smp_registered	True only when the ServiceGroup and every document type succeeded
sml_registered	True when the ServiceGroup succeeded — PHOSS creates the SML entry alongside it
total_doc_types	Count of document types recorded on the local participant record. This count does not go down after a narrowing registration — see the warning above

sml_registered and smp_registered move independently

A participant whose ServiceGroup was created but whose document types were rejected exists in the SML and resolves to nothing. A sender addressing it receives a 404 and an AS4 TRANSPORT_ERROR. If smp_registered is false, the registration is incomplete even though the participant looks present.

The Business Card, and the "Unknown" name

Routing entries tell the network where to send a document. They do not carry the company's name. That comes from a separate record called the Peppol Business Card, and registration publishes one as its own step.

This is why a participant can be correctly registered, fully reachable, and still appear to everyone else on the network as "Unknown": the routing worked and the name was never published.

The name GoRoute publishes is the participant's legal name, or its display name if no legal name is recorded. Both fields are optional on a participant record, so "we hold no name for this participant" is a real case rather than a theoretical one.

The business_card field in the registration response reports what happened:

Value	Meaning
created	The Business Card was published. This is the normal result
error_<status>	The SMP refused the Business Card and returned that HTTP status
error	The request could not be made at all
skipped_no_name	Routing was published, but no name is recorded for this participant, so no Business Card was published. Add a legal name or display name and register again
skipped	The main registration entry did not succeed, so the Business Card was not attempted

Participants registered before 28 August 2026 may have no Business Card

Registration only began publishing Business Cards in the release that went live on 28 August 2026. A participant registered before that has no Business Card unless one was created another way, and will show as "Unknown" in Peppol Directory searches and in other participants' lookups. Running the registration call again publishes it — a re-registration of an already-published participant is maintenance, so it is not subject to the billing gate below. Send no body and nothing will be removed.

Publishing the Business Card is best-effort by design. A failure is reported in this field and never undoes an otherwise complete registration, so a participant is never left unreachable because their name could not be published. The trade-off is that you have to read the field: a registration can report success and still have no name on the network.

Because Peppol Directory indexing is asynchronous, a newly published Business Card takes minutes to about an hour to appear in Directory search — see Peppol Directory listing.

Billing gate on fresh publishes

In production, registering a participant that is not yet on the network requires the organisation's SMP subscription. Without one the endpoint returns HTTP 402 with error_code: SUBSCRIPTION_REQUIRED and nothing is published. The gate applies only to fresh publishes: re-registering an already-published participant (document-type changes, business-card republish) is maintenance and always works, as do deregistration and deletion — billing never strands a live registration.

The billing surface itself:

Endpoint	Purpose
GET /api/v1/billing/smp	Subscription state for the caller's org, plus whether checkout is available
POST /api/v1/billing/smp/checkout-session	Server-created Stripe Checkout (USD-fixed); returns a redirect URL. 409 if already subscribed
POST /api/v1/billing/smp/portal-session	Stripe customer portal (cards, invoices, cancellation) for existing subscribers

Stripe is the system of record for payment; GoRoute stores no card data.

Registration errors

Registration returns HTTP 502 with one of these error codes:

error_code	When
SMP_REGISTRATION_FAILED	The PHOSS SMP refused or failed the registration
OMAN_SMP_REGISTRATION_FAILED	An Oman participant was refused by OTA's SMP wrapper
PARTICIPANT_NOT_FOUND	HTTP 404 — no participant with that UUID in your organisation

The Oman error carries a hint: OTA's SMP verifies with the Fawtara Portal that an accepted ServiceProvider-Taxpayer connection exists before it will register a participant. Accept the taxpayer's connection request on the portal first, then retry within three business days.

Step 3: Verify Registration

GET /api/v1/participants/{participant_id}/smp-status — note the hyphen. smp-status is a single path segment; it is not two segments separated by a slash.

response = requests.get(
    f"https://app.goroute.ai/peppol-api/api/v1/participants/{participant_id}/smp-status",
    headers={"X-API-Key": "your_api_key"},
)

status = response.json()
print(status["registered"], status["participant"])

For a participant on GoRoute's own PHOSS SMP the response carries registered, participant, the service_group_xml when the participant is present, and the locally recorded local_smp_registered, local_sml_registered and local_document_types.

Oman participants take a different path

An Oman participant does not live in GoRoute's PHOSS SMP, and OTA's wrapper is PUT/DELETE only — there is no read route to query. smp-status returns what GoRoute recorded at registration time (registered, participant, rail: "oman-central-smp", smp_registered, sml_registered, document_types) plus a note saying so. Verify authoritatively via the Fawtara Portal (E-Services > SMP Management), SML DNS resolution, or a public SMP GET.

A failed status check returns HTTP 502 with error_code: SMP_CHECK_FAILED.

SMP Record Structure

An SMP record contains:

Service Group

<?xml version="1.0" encoding="UTF-8"?>
<ServiceGroup xmlns="http://busdox.org/serviceMetadata/publishing/1.0/">
    <ParticipantIdentifier scheme="iso6523-actorid-upis">0106:12345678</ParticipantIdentifier>
    <ServiceMetadataReferenceCollection>
        <ServiceMetadataReference 
            href="https://smp.goroute.ai/0106:12345678/services/urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"/>
    </ServiceMetadataReferenceCollection>
</ServiceGroup>

Service Metadata

<?xml version="1.0" encoding="UTF-8"?>
<ServiceMetadata xmlns="http://busdox.org/serviceMetadata/publishing/1.0/">
    <ServiceInformation>
        <ParticipantIdentifier scheme="iso6523-actorid-upis">0106:12345678</ParticipantIdentifier>
        <DocumentIdentifier scheme="busdox-docid-qns">
            urn:oasis:names:specification:ubl:schema:xsd:Invoice-2::Invoice##urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0::2.1
        </DocumentIdentifier>
        <ProcessList>
            <Process>
                <ProcessIdentifier scheme="cenbii-procid-ubl">
                    urn:fdc:peppol.eu:2017:poacc:billing:01:1.0
                </ProcessIdentifier>
                <ServiceEndpointList>
                    <Endpoint transportProfile="peppol-transport-as4-v2_0">
                        <EndpointURI>https://ap.goroute.ai/as4</EndpointURI>
                        <RequireBusinessLevelSignature>false</RequireBusinessLevelSignature>
                        <Certificate>MIIF...</Certificate>
                        <ServiceDescription>GoRoute Peppol Access Point</ServiceDescription>
                        <TechnicalContactUrl>https://goroute.ai/#contact</TechnicalContactUrl>
                    </Endpoint>
                </ServiceEndpointList>
            </Process>
        </ProcessList>
    </ServiceInformation>
</ServiceMetadata>

Document Capabilities

What a participant advertises comes from the curated per-country set, which you can ask for at any time — see Step 1a for the endpoint and its fields.

For Australia and New Zealand the curated set is:

	Document type	Scheme
default	PINT A-NZ — Invoice	peppol-doctype-wildcard (exact + * ids)
default	PINT A-NZ — Credit Note	peppol-doctype-wildcard (exact + * ids)
opt-in	Peppol BIS Billing 3.0 — Invoice / Credit Note	busdox-docid-qns
opt-in	PINT A-NZ Self-Billing — Invoice / Credit Note	peppol-doctype-wildcard (exact + * ids)
opt-in	Peppol BIS Ordering 3.0 — Order / Order Response	busdox-docid-qns
opt-in	Peppol BIS Despatch Advice 3.0	busdox-docid-qns

Every other country currently gets Peppol BIS Billing 3.0 Invoice + Credit Note as its default, with no opt-ins.

Why Australia and New Zealand use one identifier scheme, not two

PINT A-NZ is published under peppol-doctype-wildcard only. That is not a GoRoute preference; the specification requires it. OpenPeppol's PINT A-NZ Billing BIS, version 1.1.1, section 5.1.3 "Document type identifier scheme" says:

It is mandatory to follow the Policy for Identifiers. Only the peppol-doctype-wildcard Document Type Identifier scheme is allowed.

— PINT A-NZ Billing BIS, section 5.1.3

Publishing PINT A-NZ under busdox-docid-qns as well would therefore be non-conformant. Each PINT A-NZ document type is published twice, but under the same scheme: once under the exact identifier (…@aunz-1::2.1) and once under the wildcard identifier (…@aunz-1*::2.1). Both are needed — GoRoute's run against the OpenPeppol A-NZ testbed failed one test without the exact entry and a different test without the wildcard one.

Australia and New Zealand are the only two countries treated this way.

Why the opt-in types are off by default

Advertising that you accept Orders, Order Responses or Despatch Advices is a promise that the participant's Access Point will accept those documents and that someone will act on them. Only the participant can make that promise, so GoRoute never makes it for them. Turn them on in the registration wizard's checklist, in the SMP Dashboard's Manage control, or by sending an explicit document_types list.

An older registration may still advertise things this list would not publish now

A registration with no body adds and never removes. So an Australian or New Zealand participant registered before the defaults changed on 28 August 2026 may still be advertising Peppol BIS Billing 3.0 — because it was a default then and nothing has taken it away. Registering again with no body will not remove it.

This is a statement about what the code does. It is not an observation of any particular customer's record. To see what a participant actually advertises today, use GET /api/v1/participants/{participant_id}/smp-status or look the participant up in a public SMP. To change it, send an explicit document_types list — and read the warning about deletion in Step 2 first.

SMP Management

Changing document capabilities

Re-register with an explicit selection — the registration endpoint doubles as the capability editor:

requests.post(
    f"https://app.goroute.ai/peppol-api/api/v1/participants/{participant_id}/register",
    headers={"X-API-Key": "your_api_key", "Content-Type": "application/json"},
    json={"document_types": [
        # ids from GET /peppol/doc-types?country=XX — the FULL desired set
    ]},
)

The explicit list is reconciled against what the SMP currently publishes: selected types are added or refreshed, de-selected types are deleted from the SMP. In the browser, the SMP Dashboard's Manage control on each registered participant is the same operation as a checklist. If the country itself is wrong, correct country on the participant record first — it decides which curated set applies.

Read the deletion warning in Step 2 before you use this. In short: send the complete set you want, not the changes you want; check removed_doc_types in the response to see what was actually taken off the SMP; and do not check the participant record to confirm a removal, because the stored document_types list does not shrink. Oman participants ignore the selection altogether.

You cannot use this to publish a document type that is not on the country's curated set. The selection narrows what GoRoute offers; it cannot add to it. Arbitrary document type identifiers are never published through this API.

An earlier revision documented a PUT capability route

No such route ever existed, and there is still no per-capability endpoint. The only lever is the registration reconcile described above, and only ids from the curated country set are ever published.

Deregister from SMP

POST /api/v1/participants/{participant_id}/deregister — a POST, not a DELETE, and it requires the participants:manage permission.

response = requests.post(
    f"https://app.goroute.ai/peppol-api/api/v1/participants/{participant_id}/deregister",
    headers={"X-API-Key": "your_api_key"},
)

result = response.json()
print(result["participant"], result["status"])

status	Meaning
deleted	The ServiceGroup was removed
not_found	It was already gone — the desired end state, so this counts as success
error_<status>	The SMP refused; the participant is still published

Deleting the ServiceGroup cascades to all of its ServiceMetadata. On success the local record is kept but marked unregistered, and its document types are cleared.

A refused deregistration does not change local state

If the SMP refuses the delete, GoRoute deliberately leaves the local flags untouched and the call fails with HTTP 502 and error_code: SMP_DEREGISTRATION_FAILED. Recording a removal that did not happen would mean believing a participant was gone while they remained reachable — and Oman requires deregistration within one working day of a connection ending. Re-check with smp-status rather than assuming.

Deregistration

Deregistering from SMP means other participants can no longer send you documents via Peppol. Only do this if you're migrating to another Access Point or leaving the network.

Delete the participant record

DELETE /api/v1/participants/{participant_id} needs the participants:manage permission and answers 204 No Content on success. It soft-deletes: the record disappears from the SMP Dashboard and the wizard, but it is retained so that historical transactions still resolve. A participant id that does not belong to your organisation gets 404.

Deregister first. That is the clean sequence, and it is what the dashboard already does — it offers Delete only for participants that are off the network.

If you delete a participant that is still published on the SMP, GoRoute deregisters it for you before deleting anything. Removing the SMP ServiceGroup takes the SML entry and every published ServiceMetadata with it. An entry that has already gone counts as success.

A refused deregistration cancels the delete

If the SMP will not let go of the participant, the call answers HTTP 502 with error_code: SMP_DEREGISTRATION_FAILED and nothing is deleted. The participant is still published, still visible and still yours. Read a 502 here as "try again, or deregister explicitly first" — never as "probably deleted".

An organisation in delivery-simulation mode skips the deregistration step: there is no live registration to take down, so the record is simply soft-deleted.

Two further consequences of a delete are easy to build the wrong assumption on:

• Re-creating a deleted identifier brings the old record back. Create a participant with a scheme and identifier this organisation deleted earlier, and GoRoute reactivates the original record — same participant UUID — and updates whichever fields you send.
• A deleted participant frees its place in your plan allowance. Only active participants that are published on the SMP count towards the identifiers your plan includes.

Peppol Directory listing

Registration makes a participant routable immediately — any sender's SMP lookup finds it. The public Peppol Directory (directory.peppol.eu; test participants: test-directory.peppol.eu) is a separate search index: after each registration or business-card change, GoRoute's SMP announces the participant to the Directory, which then fetches the business card and indexes it asynchronously — typically minutes, up to about an hour. A fresh registration that lookups resolve but Directory search does not yet show is normal, not a fault.

Test vs Production

Test SMP

SML: acc.edelivery.tech
SMP: smp-test.goroute.ai

Production SMP

SML: edelivery.tech
SMP: smp.goroute.ai

Environment Isolation

Test and production are completely separate networks. A participant registered in test cannot receive documents from production, and vice versa.

Troubleshooting

Registration Failed

Error: "Participant already registered with another AP"

The identifier is already registered with a different Access Point. The previous provider must deregister before GoRoute can register.

# Contact GoRoute support for migration assistance
# admin@goroute.ai

Lookup Returns Nothing

Error: "Participant not found in SMP"

1. Check if registration completed successfully
2. Verify you're using the correct environment (test/prod)
3. Wait 5-10 minutes for DNS propagation

Registered but not in the Peppol Directory

See Peppol Directory listing — Directory indexing is asynchronous. If a participant is still missing after a few hours, contact admin@goroute.ai.

Wrong Document Types

Error: "Receiver does not support document type"

The receiver's SMP registration doesn't include the document type you're trying to send.

# Check the receiver's capabilities first. The lookup takes a single
# peppol_id in scheme:value form, not a separate scheme and identifier.
response = requests.get(
    "https://app.goroute.ai/peppol-api/api/v1/participants/lookup",
    params={"peppol_id": "0106:12345678"},
    headers={"X-API-Key": "your_api_key"}
)

capabilities = response.json()["capabilities"]

Best Practices

1. Register Early — Complete SMP registration before going live
2. Test First — Always register in test environment before production
3. Check What Was Registered — With no request body the set comes from the participant's country, so confirm it with smp-status rather than assuming. If you sent a document_types selection, also read removed_doc_types in the response: it is the only reliable record of what was taken off the SMP
4. Send No Body Unless You Mean To Remove Something — A registration with no body only ever adds. A document_types list deletes every published type you leave out
5. Check the Name, Not Just the Routing — A business_card of skipped_no_name means the participant is reachable but will show as "Unknown" to everyone else on the network
6. Monitor Status — Set up alerts for SMP registration changes
7. Keep Records — Maintain history of registration changes

API Reference

All paths are relative to https://app.goroute.ai/peppol-api. {participant_id} is the UUID of the GoRoute participant record in every case.

Method	Path	Permission	Notes
GET	/peppol/doc-types	None — public	Not under /api/v1. Optional country query parameter. Lists the curated set for a country
POST	/api/v1/participants/{participant_id}/register	participants:manage	Optional request body: {"document_types": [...]}. With no body, the country default set is published and nothing is removed. With a list, everything you leave out is deleted from the SMP
POST	/api/v1/participants/{participant_id}/deregister	participants:manage	POST, not DELETE
GET	/api/v1/participants/{participant_id}/smp-status	Authenticated	A single hyphenated path segment
DELETE	/api/v1/participants/{participant_id}	participants:manage	204 on success; soft-deletes the record. A still-published participant is deregistered first, and a refused deregistration answers 502 SMP_DEREGISTRATION_FAILED without deleting anything — see Delete the participant record

GET /peppol/doc-types is the one endpoint here that is not under /api/v1 and needs no API key.

There is no capabilities-editing route. See "Changing document capabilities" above.

Next Steps

• Sending Documents
• Receiving Documents
• Partner Verification