Integration points

Before you build an issuance solution, you need to know which of your own systems have to change. This page maps the integration points for credential issuance: what you connect, who owns each side of the connection, and which MATTR VII surface implements it.

This page covers what connects to what. It does not cover how to configure any of it, so every integration point links to the guide that does.

The integration boundaryCopy Anchor Link

MATTR VII operates the issuance protocol. You operate the systems that decide who gets a credential and what it says.

MATTR VII owns these, so you do not have to build them:

• The OID4VCI token and credential endpoints, and the issuer metadata that Holder apps read.
• Credential assembly and cryptographic signing.
• Status list creation, signing, and publication.

You own these, and MATTR VII cannot supply them:

• The decision about who is eligible for a credential.
• The authoritative data the credential carries.
• How the offer reaches the holder.
• Anything downstream that consumes the outcome.

Integration points at a glanceCopy Anchor Link

Not every flow uses every point. The flow sections below say which apply where.

Authorization Code flowCopy Anchor Link

The Authorization Code flow crosses your boundary at up to four points. MATTR VII orchestrates the journey and calls out to you at each one.

1. Identity provider. MATTR VII redirects the holder to your OpenID Connect provider to authenticate. You keep your existing identity system and your existing assurance processes. What you configure on MATTR VII is the connection to it. See Authentication provider.
2. Interaction hook (optional). MATTR VII hands the holder to a web application you host, so you can add steps the standard flow does not cover, such as document capture, a biometric check, or a knowledge factor. You return control to MATTR VII when you are done. See Interaction hook.
3. Claims source. At issuance time MATTR VII calls an HTTPS endpoint you expose, passing the authenticated subject, and you return the claims. Your system of record stays where it is. See Claims source.
4. Event receiver (optional). MATTR VII calls your endpoint when issuance completes, so your downstream systems can react. See Webhooks.

For the end user experience of this flow, see the Authorization Code journey pattern.

Pre-authorized Code flowCopy Anchor Link

The Pre-authorized Code flow moves the authentication decision out of MATTR VII and into your systems. The architectural consequence is worth stating plainly: there is no identity provider integration in this flow, and the interaction hook is not available. Your application has already authenticated the holder before it asks MATTR VII for an offer.

That leaves these integration points:

• Eligibility and offer creation. Your system decides the holder is entitled to the credential and calls MATTR VII to create the offer. See Credential offer.
• Offer delivery. You choose the channel, whether that is a deep link in your own app, a QR code on a page you render, or a link in an email.
• Transaction code delivery (optional). If you require a transaction code, you send it to the holder out of band. MATTR VII does not deliver it.
• Claims. You have two options. Pass the claims in the offer when you create it, or reference a claims source from the credential configuration so MATTR VII retrieves them from your system.
• Event receiver (optional). As above.

To decide between this flow and the Authorization Code flow, see Choose an issuance flow.

Direct issuanceCopy Anchor Link

Direct issuance has the smallest integration surface, because there is no Holder app and no OID4VCI exchange. Your backend calls MATTR VII to sign a credential and receives it back. You then own delivery and storage, whether that is a PDF, an Apple or Google pass, or a QR code you render yourself.

There is no identity provider, no interaction hook, and no claims source. You pass the claims in the request. See Issue a CWT credential and the direct issuance journey pattern.

Cross-cutting integration pointsCopy Anchor Link

These apply regardless of which flow you choose.

Signing keys and PKICopy Anchor Link

Credentials are signed against a certificate chain, and you have a real choice about who holds the root. MATTR VII can generate and manage the Issuing Authority Certificate Authority (IACA) and Document Signer Certificates for you, or you can supply an external root certificate and keep ownership of its key protection and rotation. Note that supplying an external root does not necessarily move signer key custody, so read PKI and Chain of trust before you design around it.

Key protection options range from MATTR managed key vaults and hardware security modules through to arrangements that involve your own infrastructure. The available models depend on your deployment, so see Deployment models and talk to MATTR about your requirements.

Holder app trustCopy Anchor Link

If you need to restrict issuance to Holder apps you trust, MATTR VII can require the app to prove itself before it releases a credential. You register the app and its attestation material, and you decide whether the check is mandatory. See Trusted Holder apps, Wallet attestation, and End to end encryption.

Status and revocationCopy Anchor Link

Revocation is the one lifecycle operation with an asymmetric boundary. You call MATTR VII to change a credential's status, but the consuming side is a verifier or Holder app fetching a published status list. Nothing calls back into your systems, and you do not need to expose an endpoint for it. See Revocation.

Credential refresh lets a Holder app claim an updated credential without the holder authenticating again. It is a closed beta preview feature and is not generally available, so treat it as a direction rather than something to design around today.

Downstream systemsCopy Anchor Link

Three surfaces carry issuance outcomes into your wider estate, and they behave differently:

• Webhooks push. MATTR VII calls your endpoint. Two issuance event types are available, OpenIdCredentialIssued and OpenIdCredentialIssuedSummary. Events are signed with HTTP Message Signatures, and delivery order is not guaranteed, so make your processing idempotent. See Webhooks.
• Analytics pulls. You poll the Analytics API for platform events. See Analytics.
• The credential registry is queryable. Your service can look up records of issued credentials directly. See Users and Credential reports.

Related integration pointsCopy Anchor Link

Issuance is one side of a journey that continues in the Holder app and ends with a verifier.

• Holding integration points for the Holder app side of claiming.
• Verification integration points for the relying party side.
• Digital Trust Service integration points for establishing which issuers an ecosystem recognizes.
• Platform management integration points for tenant provisioning, access control, and observability.

Next stepsCopy Anchor Link

• Work through the build sequence from the Issuance overview.
• Choose your flow with Choose an issuance flow.
• Compare MATTR VII, MATTR Pi, and MATTR GO in Platforms.