Peppol Participant Lookup & Change Monitor

Verify whether suppliers and customers are actually published on the live Peppol network, see their current document-type capabilities, and detect publication, SMP and capability changes over time.

Give it a list of Peppol participant identifiers. For each one it answers the question your ERP actually needs answered before it enables e-invoice routing:

Is this participant published on the Peppol network right now, which SMP serves it, and which document types does it currently advertise?

Why not just check the Peppol Directory?

The Peppol Directory is a useful discovery tool, and this Actor is not a criticism of it. But publication in the Directory is voluntary and asynchronous, so Directory presence and network publication are two different facts:

Peppol Directory  ->  a company chose to list itself, at some point
Peppol SML/SMP    ->  current publication and advertised document types

Network discovery is a prerequisite for routing, not a delivery test. This Actor does not fetch ServiceMetadata endpoints, validate Access Point certificates, send invoices or confirm the recipient's business acceptance rules.

During the research for this Actor, participant 0192:930751340 was listed in the Peppol Directory and returned NXDOMAIN from the production SML - it was not published on the network at all. That is one participant out of a small sample; it illustrates why Directory presence alone is not a routing check.

This Actor reads the network's own discovery chain instead:

participant identifier
  -> SML DNS/NAPTR lookup      (is it published at all?)
  -> SMP base URL              (who serves it?)
  -> SMP ServiceGroup          (which document types are advertised?)
  -> normalized observation + fingerprint + change events

This covers the publication and ServiceGroup stages of network discovery, not the complete Access Point delivery workflow.

Free tools such as Peppol Lookup and peppol.tools are useful for manual checks or direct API integrations. This Actor adds Apify-native batches, persisted change detection, explicit per-item diagnostics and exportable datasets. It does not sell exclusive access to Peppol metadata.

What you get

If a process restarts after publication begins, it fails with PUBLICATION_REPLAY_BLOCKED instead of replaying potentially charged rows. Inspect that run's dataset and start a new run. Automatic continuation of a partially published run is not supported; this is a conservative billing guard, not an exactly-once delivery guarantee.

One row per participant, with a per-item status, so one bad identifier never spoils the batch:

check_status	Meaning
SUCCESS	The chain completed. The observation is trustworthy.
NOT_FOUND	The SML authoritatively has no record of this participant.
PARTIAL	Authoritative evidence exists but is incomplete or inconsistent.
FAILED	The check could not be completed. No claim is made either way.

network_status	Meaning
PUBLISHED	Reachable, and advertising at least one document type.
PUBLISHED_NO_DOCUMENT_TYPES	Reachable, but advertising nothing it can receive.
NOT_PUBLISHED	Not on the network. No Access Point can route to it.
UNKNOWN	This check established nothing. Never read UNKNOWN as absence.

A DNS timeout is never reported as NOT_PUBLISHED. Neither is a SERVFAIL, an SMP timeout, an SMP 5xx, or an HTTP 200 that turns out to be an error page. Those are FAILED, with an error code and a retryable flag. This distinction is the whole point of the Actor: a monitor that reports outages as unpublished participants would have you disable routing for healthy suppliers.

Sample input

{
  "participants": [
    "9925:BE0848934496",
    "0192:930751340",
    "iso6523-actorid-upis::0208:0891323496"
  ],
  "network": "production",
  "monitorChanges": true,
  "emitUnchanged": true
}

Identifiers may be written as 9925:BE0848934496 or in full as iso6523-actorid-upis::9925:BE0848934496. The four-digit prefix is the ISO 6523 scheme code (9925 Belgian VAT, 0192 Norwegian organisation number, 0208 Belgian company number, 0106 Dutch KvK, 0195 Singapore UEN, and so on).

A bare company number with no scheme code is rejected, not guessed at - inferring the scheme would produce a confident answer about the wrong company. Duplicates are removed before any lookup, so the same participant is never charged twice, however it is spelled.

Sample output

{
  "participant_id": "iso6523-actorid-upis::9925:BE0848934496",
  "participant_scheme": "9925",
  "participant_value": "BE0848934496",
  "network": "production",
  "check_status": "SUCCESS",
  "network_status": "PUBLISHED",
  "smp_url": "https://smp.peppol.org",
  "smp_host": "smp.peppol.org",
  "document_types": [
    "busdox-docid-qns::urn:fdc:peppol:end-user-statistics-report:1.1::EndUserStatisticsReport##urn:fdc:peppol.eu:edec:trns:end-user-statistics-report:1.1::1.1",
    "busdox-docid-qns::urn:fdc:peppol:transaction-statistics-report:1.0::TransactionStatisticsReport##urn:fdc:peppol.eu:edec:trns:transaction-statistics-reporting:1.0::1.0"
  ],
  "document_type_count": 2,
  "changed": true,
  "change_types": ["FIRST_OBSERVATION"],
  "fingerprint": "sha256:...",
  "source": "Peppol SML/SMP",
  "source_url": "https://smp.peppol.org/iso6523-actorid-upis%3A%3A9925%3ABE0848934496",
  "lookup_domain": "3kbwcdjpjlznbhgy2qydzak2gvaadf323uwokpt44l6l4jm3mpyq.iso6523-actorid-upis.participant.sml.prod.tech.peppol.org",
  "source_checked_at": "2026-09-05T12:00:00Z",
  "scraped_at": "2026-09-05T12:00:00Z",
  "error_category": null,
  "error_message": null
}

lookup_domain is the exact DNS name that was queried, so you can reproduce any answer by hand:

$dig +short NAPTR 3kbwcdjpjlznbhgy2qydzak2gvaadf323uwokpt44l6l4jm3mpyq.iso6523-actorid-upis.participant.sml.prod.tech.peppol.org

For a participant that is not published, source_url is an RFC 4501 dns: URI naming the lookup that was actually performed. The Actor never fabricates an https:// URL for a resource it did not fetch.

Monitoring

With monitorChanges on (the default), each participant is compared against its own last successful observation:

Change type	Fires when
FIRST_OBSERVATION	No baseline yet.
PUBLISHED	Was verified not published, now published.
UNPUBLISHED	Was published, now verified not published.
SMP_CHANGED	Still published, but a different SMP now serves it.
DOCUMENT_TYPE_ADDED	New document types published.
DOCUMENT_TYPE_REMOVED	Document types withdrawn.
NO_CHANGE	Nothing customer-visible moved.

Three guarantees make the change stream trustworthy:

• A failed or partial check never overwrites a good baseline. An SMP outage cannot manufacture an UNPUBLISHED event on the following run.
• Changes come only from conclusive observations. A FAILED row never produces a change event.
• A mass-unpublish pattern is refused, not believed. If most of the participants that were published at the last check suddenly come back unpublished, the run reports them as FAILED, flags the run summary, and preserves every baseline. An SML incident is far likelier than your whole supplier base leaving the network overnight.

Set emitUnchanged to false and a scheduled run returns changes plus diagnostic rows for failed or partial checks. Verified unchanged checks are also charged and remain accessible in the run's UNCHANGED_CHECKS Key-Value Store report. This setting filters output, not payment. RUN_SUMMARY.billableParticipants counts accepted checks across both outputs. A PENDING receipt after an interruption does not prove a charge: reconcile it against the run's event counts. Do not resurrect that run; start a fresh run to avoid replaying uncertain billing. When monitorChanges is off, all results are returned regardless of emitUnchanged.

Baselines advance only after an observation is delivered (and accepted for charging on pay-per-event runs). Reaching the charge limit preserves the previous baseline, so the undelivered change can be returned on a later run.

State uses uniquely keyed KVS snapshots. Concurrent runs merge the latest successful observation per participant and network; a completed write compacts only snapshots it has already read. Storage operations therefore vary with overlapping runs. Legacy state without a network prefix cannot be assigned safely to production or test and is ignored; the next successful check establishes a fresh baseline.

Schedule it

Create a Task with your watchlist, then schedule it daily or weekly. The stored baseline is keyed per participant and per network, so a schedule keeps working unattended.

Webhook on changes

Set emitUnchanged to false, point an Apify webhook at ACTOR.RUN.SUCCEEDED, and read the output. The changes view selects columns, not rows; filter changed == true in your consumer for movements, and handle error rows separately.

https://api.apify.com/v2/datasets/{datasetId}/items?view=changes&clean=true

API

curl -X POST "https://api.apify.com/v2/acts/<username>~peppol-network-reachability-monitor/run-sync-get-dataset-items?token=<APIFY_TOKEN>" \
  -H 'Content-Type: application/json' \
  -d '{"participants": ["9925:BE0848934496"], "network": "production"}'

Because every row carries a stable source_id, scraped_at and fingerprint, runs from different weeks join to each other without any extra work.

Use with AI agents through Apify MCP

Discover and inspect without an account

Use this Streamable HTTP MCP URL for anonymous Actor search and documentation:

https://mcp.apify.com?tools=search-actors,fetch-actor-details

Ask your agent to search for Peppol participant lookup, then use fetch-actor-details with automa-flow/peppol-network-reachability-monitor to inspect its input, output and pricing. These tools do not run the Actor.

Run with your own Apify account

Expose the Actor as a typed tool using this separate URL:

https://mcp.apify.com?tools=automa-flow/peppol-network-reachability-monitor

Connect using OAuth in a compatible client (recommended), or set the Authorization: Bearer <APIFY_TOKEN> header using your own Apify API token from your client's secret settings. Never put a token in the URL, a prompt or version control. Runs are billed to the connected account at the listed price.

An anonymous HTTP 401 from this direct Actor URL, the default MCP URL or ?tools=actors is expected: those configurations include authenticated tools. It does not mean the public Actor is missing from search. For anonymous discovery, use the explicit read-only URL above. See Apify MCP authentication and anonymous access.

Example prompt:

Run automa-flow/peppol-network-reachability-monitor for participants
9925:BE0848934496 and 0192:930751340 on the production network. For each, say
whether it is published, which SMP serves it and how many document types it
advertises. Keep NOT_PUBLISHED strictly separate from FAILED, and tell me which
ones I should not enable Peppol routing for yet.

The Actor answers a technical reachability question; PUBLISHED is not a guarantee of delivery, and nothing it returns is tax, accounting or legal advice.

Use cases

Start from a saved example and replace its sample participant IDs:

• Verify participants before configuring routing: one-off production lookup without updating monitoring baselines.
• Monitor partner reachability changes: first observations establish baselines; later runs report changes and errors. Verified unchanged checks are still charged and saved in UNCHANGED_CHECKS.
• Check the Peppol test network: integration checks with baselines separate from production.

These examples do not create schedules or notifications. Monitoring baselines are shared across this Actor's tasks in your account, separately per network.

Other workflows:

• Supplier onboarding - confirm a supplier is reachable before enabling Peppol routing, instead of finding out from a rejected invoice.
• Customer reachability checks - verify a customer can receive the document type you intend to send.
• ERP and e-invoicing integration QA - assert that your own participants are published and advertising the right capabilities after a deployment.
• Peppol migration monitoring - watch a country or customer base move onto the network as mandates take effect.
• Scheduled partner-master verification - keep supplier master data honest.
• An agent or API tool for "can this participant receive Peppol documents?"

Pricing

Pay $0.0015 per check ($1.50 per 1,000 verified participants), charged once per unique participant per run that receives a trustworthy terminal answer:

Billed	Not billed
SUCCESS / PUBLISHED	Invalid identifiers
SUCCESS / PUBLISHED_NO_DOCUMENT_TYPES	Duplicates
NOT_FOUND / NOT_PUBLISHED	PARTIAL and FAILED results
	DNS timeouts, SERVFAILs, SMP timeouts, SMP 5xx
	Retries
	Participants held back by the mass-failure guard
Verified unchanged observations, including emitUnchanged=false	Unfunded checks

A verified NOT_PUBLISHED is billed because establishing it takes the same authoritative lookup as a positive answer - and knowing that a supplier cannot receive Peppol documents is the answer you came for.

You are never charged for the Actor's own retries or internal requests. Platform usage is included. There is no startup or additional dataset-item fee. Set a maximum cost per run; the minimum selectable cap is $0.0015, not a minimum charge. Your available Apify credit may lower the effective cap. Unfunded results become free MAX_TOTAL_CHARGE_REACHED diagnostics and do not advance the baseline. The cap also bounds source work: if it covers only ten checks, only the first ten unique inputs are attempted; later inputs receive billing diagnostics. Source failures within that reserved batch are free but do not trigger backfill. Use a cap covering your complete watchlist for comprehensive monitoring.

Examples: 10 verified checks cost $0.015; 100 cost $0.15; 1,000 cost $1.50. Checking 1,000 participants daily for 30 days costs at most $45, even when none change; hourly checks for 30 days cost at most $1,080. Prefer daily batches unless your workflow needs a shorter interval. Every scheduled run has its own cap. Free lookup APIs and cheaper Directory exports exist; this Actor adds Apify-native batch status, persisted change detection and a consistent integration contract.

Performance

Hosted on Apify on 2026-09-05, build 0.1.2, default 512 MB:

Participants	Run time	Peak process RAM
1	6.2 s	59.1 MiB
10	20.9 s	64.0 MiB
100	25.0 s	65.9 MiB
1,000	73.0 s	136.8 MiB

The 1,000-participant run touched 51 distinct SMP providers and made 974 SMP requests, with no source retries. Available account credit limited it to 884 paid results; 114 billing-limit diagnostics and two rejected SMP URLs were free. Runtime varies by provider and network; these are observations, not an SLA. No browser or proxy was used. Historical local benchmark.json measured Python allocations with tracemalloc, not hosted process RAM; it is not a capacity claim.

Limitations

• PUBLISHED does not guarantee end-to-end invoice delivery. It means the participant is discoverable and its SMP advertises the capability. The receiving Access Point, the participant's own systems and the document's business validity are all outside what any discovery lookup can see.
• NOT_PUBLISHED means "not discoverable through the validated production lookup path at check time", not that the company does not exist, is not a Peppol user, or cannot be reached another way.
• This is a point-in-time observation. The network changes; re-run to re-check.
• MVP reads the ServiceGroup only. Per-document-type endpoint metadata, certificates and process identifiers are not collected.
• The Actor does not resolve a company name or a bare registration number to a participant identifier. You supply the identifier.
• Peppol Directory business cards - company names, addresses, contact people - are deliberately not collected. Reachability monitoring does not need them.

Source and freshness

Data comes from the Peppol network's public discovery infrastructure:

• the Service Metadata Locator, production zone participant.sml.prod.tech.peppol.org (and the test zone participant.sml.test.tech.peppol.org);
• the participant's own Service Metadata Publisher, over its standard anonymous read-only REST binding.

Every check queries the discovery infrastructure instead of returning a stored baseline as a fresh result. DNS resolver caches and source-side propagation can delay visible changes; source_checked_at records the check time, not a guarantee of instantaneous global consistency.

Legal and affiliation

• This Actor is independent and not affiliated with OpenPeppol, and is not certified or endorsed by OpenPeppol or any Peppol Authority.
• It observes public Peppol network discovery and service-metadata infrastructure, using the same anonymous lookups any Access Point performs. No account, no Peppol certificate, no authentication and no access control is involved.
• Results describe technical publication and capability state at observation time.
• The Actor sends no Peppol documents, uses no management APIs, and performs no writes to the SML or any SMP.
• Participant identifiers are processed only as you supply them. They are never enumerated, discovered or enriched.
• This is not tax, accounting or legal advice.