SMPs and Access Points

Note: The currently released APIs from Arratech only support whitelabeled Access Points, not SMPs. Future plans include support for whitelabeling of both Access points and SMPs, as described in the paragraphs below.

Arratech Solution supports whitelabeling of both SMPs and Access Points (APs). This means that an organisation can deploy its own, accredited SMPs and APs on Arratech's platform. The key for the accreditation is the SSL certificates for SMPs and APs issued by Peppol. When an organisation has its own Peppol certificate for e.g. access points, the organisation creates an Access Point in Arratech Solution, attaches the certificate and is ready to send and receive business transactions.

When an organisation is allowed to run in shared mode it is not required to have its own certificates - it can also use certificates from Arratech, and/or from a parent organisation if such exists.

Initially each organisation is in a demo/sandbox mode and it is only upon request and explicit approval by Arratech that the organisation is enabled to run in whitelabeled or shared mode. Note however that even in whitelabeled mode an organisation may use Arratech's test certificates.

Organisation Certificates

As mentioned above, organisations in shared mode and organisations that only use test certificates, do not have to manage any certificates themselves. However, organisations in whitelabeled mode that intend to run in production mode must upload their own production certificate(s) and then create an Access Point and/or SMP linked to this certificate.

Access Point

The Access Point (AP) API provides a unified interface for securely exchanging business documents across eDelivery networks. While Peppol is the first supported network, the API is designed to support multiple delivery ecosystems such as DBNA, EESPA, and other federated or private networks in the future.

All transactions follow the four-corner exchange model defined by the relevant network (e.g. Peppol), and use a standards-based transport protocol (currently AS4) to ensure secure, signed, and traceable delivery.

When a transaction is submitted, the platform performs the following steps:

  1. Document validation, ensuring well-formedness and compliance of SBD and SBDH data.
  2. Recipient resolution via network-specific mechanisms such as Peppol's SML and SMP.
  3. Transport-layer delivery using the appropriate certificate — either provided by the organisation (white-labeled mode) or issued and managed by Arratech (shared service mode).
  4. Delivery tracking via message-level identifiers, status updates, and evidence receipts (where supported by the network).

Each transaction is scoped to a specific organisation, and the transactions are logged and can be queried for auditing, reporting, and operational purposes.


SMP

The Service Metadata Publisher (SMP) serves as a decentralized registry for discovering the technical capabilities of document receivers in the PEPPOL network.

Arratech hosts two SMPs, one for production and one for test. The production SMP can be used by all organisations in shared mode while the test SMP can be used by all organisations. All organisations can also create their own SMP and connect it with their own certificate via the Arratech API.

An SMP consist of two main components:

  1. Discovery APIs, as specified by the OpenPeppol SMP Specification.
  2. Management APIs, which are proprietary to the provider and used for participant onboarding, configuration, and metadata lifecycle management.

SMP Discovery APIs

The OpenPeppol discovery APIs are a set of read-only RESTful endpoints used by Access Points and service providers to discover the technical capabilities of a participant.

For Arratech’s production SMP these endpoints are hosted under the base URL: http://smp.arratech.com/

Note: In compliance with PEPPOL specifications, the discovery API operates over HTTP on port 80, and all responses are returned in XML format as defined in the SMP specification.

SMP Management APIs

The SMP Management APIs enables organisations to register, update, and manage participants and their associated metadata; these endpoints are defined in our API.

While the PEPPOL specification defines elements like Service Groups and Service Metadata, it does not formally define a "Participant" object. The Arratech API introduces Participant as a first-class entity to:

  • Encapsulate all related document delivery endpoints and metadata
  • Store participant-specific information such as KYC data, contact details, and operational status
  • Offer a unified and secure interface for full lifecycle management of participants

To streamline metadata handling, the Arratech API flattens the traditional PEPPOL hierarchy into a simplified structure called DocumentEndpoint. This replaces the need to manage nested layers such as ServiceMetadata, Process, and ServiceEndpoint within the management interface.

Internally, Arratech preserves a fully PEPPOL-compliant data model to ensure compatibility with the SML and standard XML-based discovery mechanisms.

Each DocumentEndpoint represents a complete delivery path, uniquely defined by a combination of:

  • Participant
  • Document Type
  • Business Process
  • Transport Profile

This structure simplifies metadata management and aligns with RESTful best practices, while ensuring full interoperability with PEPPOL's discovery model.


Arratech Whitelabeling, Certificates, AP & SMP Summary

Current limitation:

  • Publicly released APIs currently support whitelabeled Access Points (APs) only, not SMPs.

---

Whitelabeling Modes

  • Whitelabeled mode
    • Organisation uses its own Peppol-issued SSL certificates for APs (and, in future, SMPs).
    • Organisation creates its own AP (and later SMP) in Arratech Solution and attaches its certificate.
    • Can still use Arratech test certificates while in whitelabeled mode for testing.
  • Shared mode
    • Organisation does not need its own certificates.
    • Can use certificates from Arratech and/or from a parent organisation.

Activation:

  • Every organisation starts in demo/sandbox mode.
  • Switching to whitelabeled or shared mode requires explicit request and approval by Arratech.

---

Organisation Certificates

  • Shared mode and organisations using only test certificates:
    • No need to manage certificates themselves.
  • Whitelabeled + production use:
    • Must upload their own production Peppol certificate(s).
    • Must create an Access Point (and, in future, SMP) linked to these certificates.

---

Access Point (AP)

  • Unified interface for secure business document exchange across eDelivery networks.
  • First supported network: Peppol.
  • Designed to support future networks: DBNA, EESPA, other federated/private networks.
  • Uses four-corner model and AS4 transport.

Transaction flow:

  1. Document validation (SBD/SBDH well-formedness & compliance).
  2. Recipient resolution (e.g. Peppol SML/SMP).
  3. Transport-layer delivery using the appropriate certificate:
    • Organisation’s own certificate (whitelabeled mode), or
    • Arratech-managed certificate (shared mode).
  4. Delivery tracking with message IDs, status updates, and evidence receipts (where supported).
  • Every transaction is scoped to an organisation.
  • All transactions are logged and queryable for auditing, reporting, and operations.

---

SMP (Service Metadata Publisher)

  • Decentralized registry for discovering receiver capabilities in the Peppol network.
  • Arratech hosts two SMPs:
    • Production SMP – usable by all organisations in shared mode.
    • Test SMP – usable by all organisations.
  • All organisations can also create their own SMP and connect it with their own certificate via the Arratech API (planned for public API support).

SMP Components

  1. Discovery APIs (OpenPeppol SMP spec)
  2. Management APIs (Arratech-proprietary for onboarding and lifecycle management)

SMP Discovery APIs

  • Read-only REST endpoints for APs/service providers to discover participant capabilities.
  • Arratech production SMP base URL: http://smp.arratech.com/
  • Per Peppol spec:
    • Operates over HTTP on port 80.
    • Responses are XML as defined in the SMP specification.

SMP Management APIs

  • Used to register, update, and manage participants and their metadata.
  • Peppol defines ServiceGroups and ServiceMetadata, but not a formal Participant object.
  • Arratech introduces Participant as a first-class entity to:
    • Group all document delivery endpoints and metadata.
    • Store KYC data, contact details, operational status.
    • Provide a unified, secure lifecycle management interface.

Supported document types:

  • Managed via supportedDocumentTypes on the Participant object.
  • Also via GET /orgs/:orgId/participants/:participantId/supported_document_types.
  • This replaces explicit management of nested ServiceMetadata → Process → ServiceEndpoint in the management interface.

Internal model:

  • Arratech maintains a fully Peppol-compliant data model internally.
  • Ensures compatibility with SML and standard XML-based discovery mechanisms.