COMPANY · PARTNERS

Four roles, and what each one is accountable for.

ORBIS works with four kinds of partner, and they do not need the same things from us. An issuer mints its own credential types. A relying party checks proofs and opens no account at all. A wallet holds credentials on a person's behalf. A data partner exchanges attested data through the bridge and webhook plane. This page names what each one is accountable for, before it asks you to apply for any of them.

One onboarding flow would fit none of them.

Issuer, verifier, wallet and data partner ask different things of us and give different things back. A single generic form would be the easy answer, and it would feel wrong to all four. Each role is defined by what it is accountable for, not by a title on a signup page.

The four roles.

Two of the four need an ORBIS organization behind them. Two do not — one of them needs nothing from us at all.

Issuer needs an ORBIS organization
Hands out credentials that people carry in a wallet and can show anywhere, under its own tenant.
Relying party / verifier no ORBIS account needed
Checks a proof somebody shows it and confirms the proof is real, unexpired and not revoked.
Wallet needs an ORBIS organization
Builds the surface a person holds their credentials in.
Data partner needs an ORBIS organization
Deposits attested data into ORBIS, or receives events out of it, through the bridge and webhook plane.

What moves an application forward.

Once you apply, the application moves through named stages. ORBIS operators and the applicant see the same stages — there is no separate status board that can disagree with the operator's own view.

Applied — ORBIS acts: The application sits in the review queue. Nothing is provisioned yet.
Reviewing — ORBIS acts: A reviewer reads it and may come back with questions before moving it on.
Sandbox — you act: You build against a demonstration organization, marked as a demo everywhere, permanently.
Certifying — you act: The platform runs the real exercises against your integration and records the evidence.
Live — nobody waits: The organization is provisioned on the production rail. This is the destination.
Suspended — off the forward path: Access is paused for a reason that is recorded and shown to you.
Declined — off the forward path: ORBIS is not taking the application forward. The reason is recorded.
Withdrawn — off the forward path: You asked to stop. Nothing is provisioned and nothing is pending.

What gets proved before an integration goes live.

Reaching production is not a checkbox exercise. The platform runs the real thing against an integration and records what it observed, so a failure names the exact link that broke.

The organization's key document resolves publicly and carries the key ORBIS expects.
Its webhook endpoint signs correctly — a signed challenge comes back with the right code.
An issuance completes into a test holder, over the issuance protocol.
A presentation completes and verifies, over the presentation protocol.
A withdrawn credential is refused against the signed status list.
Malformed, expired and replayed input is each rejected, not tolerated.

Before you go any further.

The roles above are named, not invented — this page was wrong to imply otherwise, and it has been corrected. What is genuinely missing is narrower: this build's own register carries no row yet for any part of the partner pipeline.

Four capabilities this page depends on — intake, sandbox provisioning, certification and self-service keys — have no row in this build's register. That is an absence in this rebuild, not a claim that the pipeline itself does not run anywhere.

The register holds 17 live · 2 partial · 2 planned · 5 not yet.

4 of the 4 capabilities this page depends on have no row in the register yet, so this page will not print a state for them. They are named rather than dropped, because a slice that silently shortens itself is the same defect as a claim with no receipt.

partner-application-intake
partner-sandbox-provisioning
partner-certification
partner-self-service-keys

The register route serves, but it carries no row for these yet. List what it does carry:

curl -s https://id.orbis.id/api/site/register | jq -r '.entries[].slug'

Straight answers.

Are the four roles job titles?: No. Each is defined by what it is accountable for, not by a title on a form.
Does every partner need an ORBIS organization?: No. A relying party checks proofs and needs no ORBIS account at all.
Can I apply for one of these roles right now?: See the apply page. It names exactly what happens when you do, and what this build runs itself versus what it only describes.
Where do the pipeline stages and the certification checks come from?: The company's own published partner page, harvested and checked against this repository on 2026-08-27. Nothing above was guessed at.

Four roles, and one of them needs nothing from us at all. Naming the role that does not require a relationship, on the page asking you to start one, is the only way the other three are worth reading.

Do not trust us. Check us.