Integration points

Issuance, holding, and verification each have their own integration points. This page covers the ones underneath them: how your organization provisions tenants, who and what gets access, how platform activity reaches your monitoring, and how your brand appears on the platform.

Most of these connections are made once, early, and then rarely revisited. Getting them wrong is expensive to unwind, so they are worth settling before you build a flow.

Your deployment model sets the boundaryCopy Anchor Link

MATTR VII runs on two deployment models, and the one you are on comes with the environment MATTR provisions for you rather than being chosen per tenant. Regional Cloud shares infrastructure across customers in a given AWS region. Dedicated Cloud provisions an environment for your organization alone. Every tenant in an environment uses the same model.

Which model you are on changes what you can integrate with:

See Environments and tenants for the full comparison.

Integration points at a glanceCopy Anchor Link

Provisioning and API accessCopy Anchor Link

Two distinct sets of credentials exist.

Management API credentials are machine to machine credentials for your organization. You use them to list environments, create and manage tenants, and manage access control across them. They authenticate against a MATTR authentication provider rather than against a tenant, and the base URL for requests depends on your environment, region, and deployment model. See Management API.

Tenant client credentials are per tenant. Each service of yours that calls MATTR VII gets a client with the roles it needs and no more. The client secret is shown once at creation, so your secret management process has to capture it at that moment. See Create a client and Access control.

If you separate development, testing, and production, the shape of that separation follows your deployment model. On Regional Cloud it is separate tenants with separate client credentials. On Dedicated Cloud it can be separate environments.

Workforce identityCopy Anchor Link

The MATTR Portal supports single sign-on as a paid add-on, so your staff authenticate through your existing identity provider. MATTR supports any provider that integrates as an enterprise connection, including Microsoft Entra ID, Google Workspace, Okta, ADFS, and SAML based providers.

Three consequences matter when you plan this:

• MATTR performs the setup. You supply your email domain and a logo, and the MATTR team configures the connection and onboards your first user.
• Multi-factor authentication is delegated. Once single sign-on is enabled, your identity provider enforces it.
• User provisioning stays manual. Enabling single sign-on does not grant anyone access. Each user is invited to a tenant and assigned roles explicitly. There is no directory synchronization, so treat joiner and leaver processes as a manual step in your access review.

See Portal and Roles and permissions.

Observability and security toolingCopy Anchor Link

Platform events are pulled. The Analytics API stores events generated by tenant interactions, and you query them by direct API request or through the Portal. Events carry three logging levels: metadata only, non-sensitive data, and full event data. On Regional Cloud the level is fixed, and on Dedicated Cloud it is configurable. The events registry lists every event type, and the management events registry covers the Management API. See Analytics and Monitoring.

Security posture is polled. If you run a SaaS Security Posture Management tool, MATTR VII can expose posture data about the administrative accounts and machine clients that operate your platform. It covers your workforce, not credential holders or verification end users. This is a Dedicated Cloud add-on. See SSPM.

Security monitoring integration is arranged individually. On Dedicated Cloud, MATTR supports integration with customer security monitoring and detection capabilities, including forwarding platform event data to your own tooling. The specifics depend on your environment and are agreed with MATTR rather than self-configured, so there is no API or guide to follow here.

Event-driven integrationCopy Anchor Link

Webhooks push to an endpoint you provide and have a narrow scope. Today the available event types are both issuance events, OpenIdCredentialIssued and OpenIdCredentialIssuedSummary. There is no verification, holding, or trust service webhook, so those capabilities are read through the Analytics API instead.

Events are signed with HTTP Message Signatures, and you verify them against a published key set. MATTR VII does not guarantee delivery order and does not guarantee that an event arrives only once, so make your processing idempotent, using the event identifier in the payload. See Webhooks.

Domains and brandingCopy Anchor Link

A custom domain changes what end users see when they claim or present a credential. The integration is lighter than a full DNS mapping, because MATTR VII tenants are not exposed to end users directly.

You keep two responsibilities. You prove ownership of the domain with a TXT record on your DNS, and you run a web service on that domain that redirects or proxies requests. MATTR VII does not host that service. See Custom domain and the custom domain guide.

Related integration pointsCopy Anchor Link

• Issuance integration points.
• Holding integration points.
• Verification integration points.
• Digital Trust Service integration points.

Next stepsCopy Anchor Link

• Understand the topology in Environments and tenants.
• Set up programmatic access with Create a client.
• Compare MATTR VII, MATTR Pi, and MATTR GO in Platforms.