Arratech Connect · Connect Explained · Participants

Participant creation, step by step

Follows one participant from the identifier you type to a live registration on the Peppol network. The left column is what an orgadmin does in the Connect Portal. The right column is the same outcome as API calls. Every step ends with where the participant now is in the flow.

Verified against tenant-service main, 2026-10-07Portal arratech-admin main, 2026-10-07

The flow at a glance

Everything starts from the participant's Peppol ID, the scheme-prefixed identifier such as 0007:5590123450. Which scheme applies in each country, where to find the number, and the validation rules are on the Peppol IDs page.

Two questions shape everything: is the identifier already on the network, and is anything still outstanding on the participant. The first splits the flow into an own participant, whose identifier Arratech registers, and an external participant, whose registration made elsewhere is copied. The second is the Draft, which both pass through. A participant is live when nothing is outstanding and, for an own participant, its document types are registered.

This page describes the general flow. Some countries add their own rules or steps, so a participant there may behave differently; see Countries.

The steps below describe a participant created where external participant registration is switched on in your environment. Arratech switches it on per environment, so ask Arratech whether it is on where you integrate. Where it is off, an identifier that is already registered elsewhere cannot be added, because the create fails. A new identifier is registered in the same call and the participant lands ACTIVE straight away, with no draft and no document-type step. Outside a country's own registration flow, supportedDocumentTypes is then refused at the create, so add document types afterwards.

The lookup decides which kind of participant it becomes, the Draft holds whatever is still outstanding, and a participant is live when nothing is. Each box is a step below, in this order; the wizard's final screen is step 5 or 7.

Enter the identifier

Name, Peppol identifier and access point. The access point's environment, production or test, is the participant's environment.

State after this step

nothing saved yet

Connect Portal

Participants → Add Participant opens the wizard (Create Participant while the list is empty). Organisation admins only. The wizard works in the environment chosen under Peppol environment in the top bar.

Peppol environment menu open in the top bar, Production closed with its reason — The Peppol environment switch. An environment the organisation cannot use is closed and says why.

Basic Info

Name: display name.
Participant Identifier: scheme:value, for example 0007:5590123450. Format and check digit are validated as you type. Which number and scheme to use per country: Peppol IDs.
Default access point: the access points of the selected environment. Arratech's shared ones carry an Arratech badge. A single available access point is preselected and locked. In Test the wizard title carries a TEST pill.

Next is enabled once name, identifier and access point are valid.

API

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

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.

GET/participant_identifiers?filter=iso6523:eq:0007user

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

Access point

GET/orgs/{orgId}/aps/alltouseorgmember

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

Code	Reason
AT-1009	identifier format or check digit
AT-2001 / 2002	scheme unknown / retired
AT-1062	access point not usable

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

Look up the identifier

The identifier is looked up in the SML of the selected environment. The result decides which kind it becomes: not found makes it an own participant, registered elsewhere an external participant.

State after this step

nothing saved yet

Connect Portal

The lookup runs by itself after you stop typing a valid identifier, in the selected environment, together with a check against the organisation's own participants. The result appears under the field.

Result	Message	Effect
Already in your organisation	"This participant is already in your organisation on Peppol Test as ‹name›."	Blocked. Open existing participant closes the wizard and shows that participant.
Not found	"No existing registration for this identifier on the selected network. You can continue."	Own participant. Doc Types stays in the stepper.
Registered elsewhere	"This participant identifier is already registered on the network as ‹name›. Continuing will add it as an External participant with a read-only copy of its published metadata."	External participant. Doc Types leaves the stepper.
Already on Arratech's SMP	Same message as registered elsewhere.	Save is refused: "This participant identifier is already registered and cannot be added again."
Lookup failed	"Could not verify this identifier. Check the format and try again, or continue if you are sure it is correct."	You may continue. Save repeats the lookup.

Basic Info with the not-found message under the identifier — Not found. The TEST pill shows which environment was searched.

Basic Info with the registered-elsewhere warning and a two-step stepper — Registered elsewhere. The stepper drops to two steps.

Basic Info blocked: the identifier is already in the organisation, with an Open existing participant link — Already in your organisation. Next stays disabled.

API

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

GET/lookup?participantIdentifier=0007:5590123450&environment=TESTpublic

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:

SML answer	Kind
no entry	own participant
entry points to another provider's SMP	external participant
entry on the SMP chosen in smpRef	refused, AT-1064
DNS, transport or signature failure	refused, AT-1105, AT-2501 / 2502, or AT-1010 when no SMP answered

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

Own participant · not found in the lookup

Register the identifier

Where external participant registration is switched on, the platform registers the identifier on the network, without document types, and attaches the conditions the identifier calls for. Where it is off, the identifier is registered and the participant is ACTIVE straight away. Registered elsewhere? Go to step 6.

State after this step

Draft

Connect Portal

Nothing to do. The platform registers the identifier when the participant is saved, before it reads the document-type selection. You continue to step 4.

Which conditions the participant gets

The identifier decides them. Its scheme, and the country given on the business card or implied by the scheme, select a jurisdiction in the gating configuration. Every condition configured there is attached as pending. No configuration: nothing outstanding. The set is a snapshot; later configuration changes do not touch existing participants.

API

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

Code	Reason
AT-1064	identifier already on the chosen SMP
AT-1105 / 2501 / 2502 / 1010	lookup failed, nothing saved

Own participant

Select document types

The document types the participant will receive. Stored on the draft; registered on the network when the participant goes live. At least one is required before the participant can go live.

State after this step

Draft

Connect Portal

Doc Types

Filter by Category (default Invoice), search by name, or switch on PINT for the wildcard document types.
Tick as many document types as the participant should receive. Each selection appears as a chip under the list.
A document type with several processes expands into sub-rows; the group checkbox selects all of them.
PINT document types offer an Exact Match switch: off registers the wildcard variant, on registers only the exact value.

API

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

GET/document_types?filter=category:eq:Billingpublic

{ "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" }] }] }

PUT/orgs/{orgId}/participants/{id}/supported_document_typesorgadmin

{ "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

Code	Reason
AT-1069 / 1068	document type unknown / process not one of its processes
AT-1152	more than 20 entries
AT-2409	empty list on a draft
AT-2401	participant is External

Own participant

Final details and submit

Optional business card, contacts and Directory request, then Submit. Submit saves the participant: the identifier is registered (step 3) and the document types are stored (step 4).

State after this step

DraftLive

Connect Portal

Business card: legal name and identifier, country, VAT, DUNS, GLN, website, address. Published to the network with the participant.
Point of contact: business or technical contacts.
Request Peppol Directory publishing on creation.

Final Details and Submit step, own participant — Final Details & Submit.

After Submit

Outcome	What you see	Badge
Something outstanding	Dialog Participant saved: "‹name› has been saved, but it is not published on the network yet", then which conditions are still needed.	UNPUBLISHED
Nothing outstanding	Snackbar "Participant created successfully". The document types are registered at once and the participant is live.	ACTIVE
Already registered	Back to Basic Info with the error under the identifier.	not created

Dialog · Participant saved

Screenshot pendingRequires creating a participant in staging.

API

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. The portal picks the first matching SMP by name.

GET/orgs/{orgId}/smps/alltouseorgmember

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

Create

POST/orgs/{orgId}/participantsorgadmin

{
  "name": "Nordlys Handel AB",
  "participantIdentifier": "0007:5590123450",
  "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. Each SMP entry names the organisation's first Support contact as technical contact, or Arratech's support page when there is none.

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

Code	Reason
AT-1064	identifier already on the chosen SMP
AT-1061 / 1113	SMP not usable / environment mismatch
AT-1119	Demo organisation at its limit of 10 participants
AT-1105 / 2501 / 2502 / 1010	lookup failed, nothing saved
AT-1009	body validation

External participant · registered elsewhere in the lookup

Copy the published metadata

The information already registered for the identifier is taken over as a read-only copy: access points and document types from the other provider's SMP, the business card from that SMP or the Peppol Directory. Nothing is written to the network. Not found in the lookup? Go to step 3.

State after this step

nothing saved yet

Connect Portal

Triggered by Next on Basic Info once the lookup reports the identifier registered elsewhere. The wizard drops the Doc Types step, since the other provider decides the document types, and goes to its final screen (step 7).

API

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" } }

External participant

Final details and submit

Business card and contacts are optional and are saved on the participant; a Directory request is not sent, since only the other provider can publish it. Submit saves the participant with its copy and puts it in Draft, or straight to live when nothing is outstanding.

State after this step

DraftLive

Connect Portal

After Submit the wizard shows External Metadata: the copied access points, document types and certificates, with the time they were fetched, read-only. If conditions apply, a Gating step follows (step 8). A last Submit saves any business card entered and closes the wizard. Badge EXTERNAL, status ACTIVE.

External Metadata step with the copied access point, certificates, SMP and supported documents — External Metadata: the copy taken from the other provider's SMP.

API

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

POST/orgs/{orgId}/participantsorgadmin

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

Errors

Code	Reason
AT-1064	identifier already in this organisation, same environment
AT-2405	document types sent
AT-1061 / 1113	SMP not usable / environment mismatch
AT-1105 / 2501 / 2502 / 1010	lookup failed, nothing saved

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. A French send-only External participant is the exception: it waits in PENDING_MANDATE until its KYC is approved. The two PENDING statuses in the table belong to the French flow. A participant in any other country that still has a condition outstanding stays UNPUBLISHED.

Status	Class	Where in the flow
UNPUBLISHED	OWN_UNREGISTERED_IN_PEPPOL	Draft, own participant: a condition or the document types are outstanding
PENDING_MANDATE	none, or EXTERNAL	French flow only. A French participant of your own, or a French send-only External participant, waiting for its KYC approval
PENDING_TAX_REGISTRATION	none	French flow only. KYC approved, waiting for the tax authority's registration
ACTIVE	EXTERNAL	External participant: Draft while a condition is outstanding, otherwise live
ACTIVE	OWN_REGISTERED_IN_PEPPOL	Live, own participant
ACTIVE	none	Live. Every create where external participant registration is not enabled (no draft), and a French own participant once it is registered
absent	none	Live, created before these statuses existed

Own and external participants

Draft: clear what is outstanding

The participant waits here until every condition attached in step 3 is cleared. Three kinds: cleared by an admin, cleared when an identity review is approved, cleared when the tax authority confirms the registration.

State after this step

DraftLive

Connect Portal

The conditions are listed under Gating in the participant's side panel. For an external participant they also appear as the wizard's last step, right after the registered information.

Heading "This participant cannot be used yet", then one row per condition with a Pending or Cleared badge and when it was added or who cleared it.
Clear, for organisation admins, on conditions an admin clears. The confirmation notes that the participant becomes usable once the last condition is cleared.
In the French flow, identity verification and tax-authority registration have no button. They clear when the platform records the approval or the confirmation, and until then the participant's badge reads PENDING MANDATE or PENDING TAX REGISTRATION. A participant in any other country that still has a condition outstanding stays UNPUBLISHED.

Side panel of a draft participant with two pending gating conditions and Clear buttons — An own participant in Draft with two pending conditions.

When the last condition clears, the participant is live. For an own participant this is the moment its document types and access point are registered on the SMP.

Which conditions apply per country and identifier scheme is configured by Arratech under Arratech Settings → Gating.

API

GET/orgs/{orgId}/participants/{id}/gatingorgadmin

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

kyc-review is an example. The real keys are the key values in the list of the participant's own gating conditions, so read that list before you clear anything. A condition of kind kyc cannot be cleared directly: approving the participant's KYC clears it.

Cleared by an admin

POST/orgs/{orgId}/participants/{id}/gating/{key}/clearorgadmin

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 an own participant is not yet live; on an External participant at any time.

Cleared by an identity review

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

POST/orgs/{orgId}/participants/{id}/kycorgadmin

POST/orgs/{orgId}/participants/{id}/kyc/documentsorgadmin

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

POST/orgs/{orgId}/participants/{id}/kyc/approveorgadmin

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.

While something is outstanding

The participant cannot send: a transaction from it is refused with AT-2402, naming the pending conditions.

Errors

Code	Reason
AT-2201	condition key unknown
AT-2202 / 2204	already cleared / already pending
AT-2203	unclear refused, own participant is live
AT-7016 / 7017	identity record not pending / no documents attached
AT-2402	transaction from a participant that cannot send yet