EUDI verifier API architecture for product teams

The product should call a verifier service, not implement the protocol everywhere

The EU reference verifier separates a Verifier API from the wallet-facing API. That is a useful architectural pattern even when a company builds its own implementation.

Internal product code can initialise a verification transaction and retrieve the result, while wallet-facing endpoints deal with request objects, direct-post responses and protocol-specific validation.

Design the API around business outcomes

A good internal contract exposes the verified result and meaningful failure states. The calling application should not need to understand every OpenID4VP parameter in order to know whether a business process may continue.

Protocol details still matter, but they belong in a dedicated verifier module with its own versioning, tests and telemetry.

• Create verification transaction.
• Reference an intended use or registration certificate.
• Return wallet interaction details to the frontend.
• Validate presentation response.
• Expose verified claims in a normalised result.
• Record expiry, cancellation and validation failure separately.

Reference implementations are useful, but are not production products

The official EU verifier repository explicitly describes itself as an initial development release and notes that production concerns such as protecting the Verifier API are outside the scope of the current reference implementation.

Production engineering therefore still needs authentication, tenant isolation, key management, observability, rate controls and a deployment model appropriate to the service.

Adminyra's direction

Adminyra EUDI is being built with this verifier-service boundary in mind. The goal is to let another product integrate once against a controlled API while the wallet ecosystem evolves behind it.

For customer-specific projects, the same architecture can be applied without requiring the rest of the Adminyra platform.