Participant creation, step by step

No call. This step assembles three of the create fields: name, participantIdentifier, apRef. Scheme 0225 adds siret.

Identifier

• ICD:value. ICD: four digits from the Peppol scheme list. Value: 1 to 130 characters. Per-country guidance: Peppol IDs.
• Normalised on receipt: trimmed, lower-cased, iso6523-actorid-upis:: prefix removed.
• Scheme must be active in the code list. Check digit verified where the scheme has one.

{ "items": [{ "iso6523": "0007", "schemeid": "SE:ORGNR", "country": "SE", "state": "active" }] }

Access point

The organisation's own access points plus Arratech's shared ones: the test access point in Demo and Whitelabel mode, test and production in Shared mode. The access point's environment is the participant's environment.

Checked at save

{
  "name": "Nordlys Handel AB",
  "participantIdentifier": "0007:5590123450",
  "apRef":  "a1b2c3d4-…"
}

The same lookup the portal uses. Public, no token. environment selects the SML: PROD or TEST.

200 OK
[{ "participantIdentifier": "0007:5590123450",
   "name": "Nordlys Handel AB",
   "smp": { "smpUrl": "https://smp.other-provider.example", "environment": "TEST" },
   "accessPoints": [{ "apUrl": "https://ap.other-provider.example/as4",
                      "supportedDocuments": ["…"] }],
   "businessCard": { "legalName": "Nordlys Handel AB", "countryCode": "SE" } }]

404 Not Found
{ "code": "AT-1087", "error": "Participant not found" }

Arratech's own live participants are answered from its own records first; anything else is read from the SML and the SMP it points to.

What the save call does with the result

The create call repeats the lookup, with SMP signature validation, and decides which kind it is:

Calling /lookup first is optional. It lets you tell the user which kind they are creating before saving.

Performed by the create call, sent in step 5. Nothing to call here.

What the registration writes

In order: the participant row, the organisation's participant count, an entry on the SMP with no document types, the SML entry pointing at that SMP. A failure rolls all four back. The identifier now resolves on the network, but no document type can be delivered to it yet.

The conditions are attached in the same call, from the identifier's scheme and country as described on the left. They are read with the gating call in step 8.

"status": "UNPUBLISHED",
"participantClass": "OWN_UNREGISTERED_IN_PEPPOL"

Errors

List the document types, then set the participant's selection. Each entry names a document type and one of its processes.

{ "items": [{ "id": "at-01e", "name": "Peppol BIS Billing 3.0 Invoice",
              "scheme": "busdox-docid-qns", "category": "Billing",
              "process-ids": [{ "scheme": "cenbii-procid-ubl",
                                "value": "urn:fdc:peppol.eu:2017:poacc:billing:01:1.0" }] }] }

{ "supportedDocumentTypes": [
    { "documentId": "at-01e",
      "processId": "cenbii-procid-ubl::urn:fdc:peppol.eu:2017:poacc:billing:01:1.0" }
] }

• The list replaces the previous selection. At most 20 entries.
• processId is scheme::value and must be one of the document type's process-ids.
• exactMatchOnly: true applies to peppol-doctype-wildcard types only and registers the exact value instead of the wildcard.
• The same array may be sent in the create call of step 5 instead, which is what the portal does.

On a draft the selection is stored. If nothing is outstanding, the participant is live in the same call.

Errors

Submit is the create call. It carries what steps 1, 4 and 5 collected, plus the SMP.

The SMP

smpRef is the SMP the identifier is registered on. It must share the access point's environment and jurisdiction. The portal picks the first matching SMP by name.

Own SMPs plus Arratech's test SMP; Shared and Whitelabel mode add the production SMP.

Create

{
  "name": "Nordlys Handel AB",
  "participantIdentifier": "0007:5590123450",
  "transportProfile": "peppol-transport-as4-v2_0",
  "apRef":  "a1b2c3d4-…",
  "smpRef": "0797a863-…",
  "supportedDocumentTypes": [
    { "documentId": "at-01e",
      "processId": "cenbii-procid-ubl::urn:fdc:peppol.eu:2017:poacc:billing:01:1.0" } ],
  "businessCard": {
    "legalName": "Nordlys Handel AB", "countryCode": "SE",
    "legalIdentifier": "5590123450", "legalIdentifierCode": "SE:ORGNR",
    "taxIdentifier": "SE559012345001", "website": "https://nordlys.example",
    "businessAddress": { "streetAddress": "Hamngatan 1", "city": "Göteborg", "postalCode": "41101", "country": "SE" },
    "contacts": [{ "name": "Anna Berg", "email": "anna@nordlys.example", "contactType": "BUSINESS" }] }
}

Something outstanding:

201 Created
{ "id": "…", "status": "UNPUBLISHED", "participantClass": "OWN_UNREGISTERED_IN_PEPPOL" }

Nothing outstanding: the document types are registered in the same request.

201 Created
{ "id": "…", "status": "ACTIVE", "participantClass": "OWN_REGISTERED_IN_PEPPOL" }

The business card can also be set later with PUT /orgs/{orgId}/participants/{id}. The Directory request is a separate call once the participant is live.

Errors

Nothing to call. The lookup of step 2 already returned the published information; the create call in step 7 stores it on the participant as sourcedMetadata, with the time it was fetched. The copy changes only on refresh; the other provider controls the registration.

"sourcedMetadata": {
  "lastFetchedAt": "2026-09-03T10:00:00Z",
  "accessPoints": [{ "apUrl": "https://ap.other-provider.example/as4",
                     "smp": { "smpUrl": "https://smp.other-provider.example" } }],
  "endpoints":    [{ "documentTypeId": "busdox-docid-qns::…Invoice…", "isStale": false }],
  "businessCard": { "legalName": "Nordlys Handel AB", "countryCode": "SE" } }

Submit is the create call with name, participantIdentifier, apRef, smpRef and transportProfile only. smpRef is required although nothing is registered on it. supportedDocumentTypes is refused with AT-2405; omit it.

201 Created
{ "id": "…", "status": "ACTIVE", "participantClass": "EXTERNAL",
  "sourcedMetadata": { … } }

Errors

What the status field means

The status names the step the participant is waiting at, in the API's vocabulary. It does not say whether the participant is usable: an External participant reads ACTIVE from the moment it is saved.

{ "conditions": [
    { "key": "kyc-review", "label": "KYC review", "state": "pending", "kind": "manual",
      "createdAt": "2026-09-03T10:00:00Z" } ],
  "allCleared": false }

Cleared by an admin

200 OK
{ "key": "kyc-review", "state": "cleared",
  "clearedBy": { "userId": "…" }, "clearedAt": "2026-09-03T10:05:00Z" }

Clearing the last condition makes the participant live; an own participant's document types are registered on the SMP in the same call. …/unclear reverses a clear while the participant is not yet live.

Cleared by an identity review

Evidence is attached to the participant's identity record and a superadmin approves it; both are API-only. The record is created at save when the identifier scheme requires identity data, or explicitly:

Multipart, one file per call: PDF, JPEG or PNG, at most 10 MiB, content checked against the declared type.

Approval needs at least one document. It clears the condition and, where the jurisdiction requires it, requests the tax-authority registration. …/kyc/reject with a reason leaves the condition pending.

Cleared by the tax authority

The platform requests the registration and waits for the authority's confirmation, which it receives through its webhook receiver. When confirmed, the condition clears and the participant is live with the document types the jurisdiction mandates.

Errors