EUDAMED XML envelope: distinguish actor code, Party ID and service token
The acquired message documentation distinguishes actor-on-behalf-of identity, requester Party ID, service ID/operation and the service access token. These fields identify different parts of the exchange; base64 encoding of the payload is not encryption or proof of authorization.
Evidence retrieved 2026-10-07. Source versions and topic-specific limits are listed below.
Sourced criteria · EU · EUDAMED
What changes the service scope?
Decision or task
What the source describes
What to prepare
message-exchange / HTML p [6]
The entire XML message must be base64 encoded. The payload element contains the encoded message. The highlighted line shows the encoded message. [1]
Apply this source context to the specific tasks below; retain missing facts and review current target-environment compatibility.
message-exchange / HTML li [20]
serviceID : A unique identifier of a service in EUDAMED [2]
Apply this source context to the specific tasks below; retain missing facts and review current target-environment compatibility.
message-exchange / HTML li [22]
serviceOperation : Supported by the service (e.g. download, upload, update, etc.) [3]
Apply this source context to the specific tasks below; retain missing facts and review current target-environment compatibility.
message-exchange / HTML li [24]
serviceAccessToken : Bearer security authentication token (security key) to gain access permission to the requested data by the requester as EUDAMED actor or third party (acting on behalf of the actor mentioned in nodeCode) [4]
Apply this source context to the specific tasks below; retain missing facts and review current target-environment compatibility.
message-exchange / HTML li [26]
serviceVersion : In case of multi-versioned compatible service, it allows to specify what version of the current service is invoked. [5]
Apply this source context to the specific tasks below; retain missing facts and review current target-environment compatibility.
message-exchange / HTML li [30]
nodeCode : Contains the EUDAMED code (e.g. SRN , CA identifier, NB code etc.) of the party that performs the call of service. In case of multi-profile endpoint (e.g. third-party companies), it contains the actor code on behalf of the request that is performed. [6]
Apply this source context to the specific tasks below; retain missing facts and review current target-environment compatibility.
message-exchange / HTML li [32]
nodeID : Identify the requester (actor/third-party integrators) of the message eDelivery endpoint, it contains the partyID of the requester. [7]
Apply this source context to the specific tasks below; retain missing facts and review current target-environment compatibility.
Dated technical/help evidence, not a complete legal duty set or live EUDAMED response. Current target-environment release, business rules, permissions and actual buyer records remain unresolved. Blank dictionary flags are unknown; occurrence and update notes keep their stated conditions. No credentials, registration deadline or completed production exchange is inferred.
Prepare the EUDAMED XML envelope work package
Use this checklist to gather your business or product details before speaking with a specialist. The items below explain what to record and suggest useful supporting documents. You can add your own answers in the editable project brief.
Map requester and represented actor
Record which organisation owns the AP and which actor the request is on behalf of; map their distinct identifiers.
Useful evidence: A requester/represented-actor identity and delegation matrix.
Map service and operation
Specify the exact supported module service and operation with its token reference and compatible version.
Useful evidence: An envelope field map with private token references and source-version locators.
Verify payload handling
Ask the integrator to show encoding, transport security and application validation separately.
Useful evidence: A redacted end-to-end trace demonstrating the envelope and decoded payload structure.
Work packages and dependencies
Conditional: EUDAMED XML envelope: distinguish actor code, Party ID and service token — Review the actual current records and target-environment requirements; complete the specific mapping/onboarding or maintenance task with source/version and acceptance evidence.
Questions for providers
How will you resolve the specific field/identity or state dependencies shown here for our actual records?
Which current environment release, permissions and business rules support the proposed operation?
What mapping, unresolved-error and acceptance evidence will you hand over, and who owns each correction?
Sources and data dates
Read the official document in context. The audit details identify the precise locators and preserved versions used for this page.
