Partners — start integrating with ORBIS.ID

Four profiles, four paths

A single generic onboarding flow would be the lazy answer and would feel wrong to every one of these. They differ in what ORBIS has to provision, what you have to prove, and whether you need an account at all.

Issuer needs an ORBIS organization

You hand out credentials that people carry in a wallet and can show anywhere.

Relying party / verifier no ORBIS account needed

You check a proof somebody shows you, and you want to know it is real, unexpired and not revoked.

Wallet needs an ORBIS organization

You are building the surface a person holds their credentials in.

Data partner needs an ORBIS organization

You deposit attested data into ORBIS, or receive events out of it, through the bridge and webhook plane.

The pipeline — one state machine, seen from your side

ORBIS operators work the same eight states you see here. There is no second, partner-only status board that can disagree with theirs. Every stage names who holds it and what moves it on, because a state you cannot act on is a dead end.

Applied ORBIS acts

Your application exists and is in the review queue. Nothing has been provisioned.

What moves it: An ORBIS reviewer picks it up. You do not need to do anything.
Reviewing ORBIS acts

A reviewer is reading it and may come back to you with questions.

What moves it: The reviewer either asks you something or moves you to a sandbox.
Sandbox you act

You have a demonstration organization to build against. It is marked as a demo everywhere, permanently.

What moves it: You build the integration, then ask for certification.
Certifying you act

The platform is running the real exercises against your integration and recording the evidence.

What moves it: Every check on the readiness board passes. Each failure names the concrete fix.
Live nobody waits

You are a provisioned organization on the production rail.

What moves it: Nothing — this is the destination. Your organization is now managed in Organizations, not here.
Suspended ORBIS acts off the forward path

Your access is paused. The reason is recorded and is shown to you.

What moves it: Resolving the recorded reason with ORBIS.
Declined nobody waits off the forward path

ORBIS is not taking this application forward. The reason is recorded.

What moves it: Nothing automatic. You may apply again if what was recorded changes.
Withdrawn nobody waits off the forward path

You asked to stop. Nothing is provisioned and nothing is pending.

What moves it: Nothing. Apply again whenever you want to.

Why there are no durations on this page

You would reasonably like to know how long each stage takes. ORBIS has not measured that — the pipeline is new and there is no completed history to quote a distribution from. Publishing a plausible-sounding “two to three business days” would be an invented number, and this platform does not put invented numbers on its production origin. When the desk has real stage clocks, the measured time appears here and on your status page. Until then, what each stage waits on is written above, which is the half you can act on.

What you can and cannot do yourself

You can apply, build against a sandbox, run the certification exercises, and watch your own state.
You cannot grant yourself an organization, a token, or a stage. Every capability grant is an operator action through the ORBIS approvals ladder.
That split is the point: self-serve changes who starts the process, never what is enforced in it.

What gets proved before you go live

Reaching production is not a checkbox exercise. The platform runs the real thing against your integration and records the evidence — the URL it called, the status it got, how long it took. A failure tells you which link of the chain broke and what to change.

Your did:web resolves publicly and carries the key ORBIS expects.
Your webhook endpoint signs correctly — a signed challenge comes back with the right HMAC.
An issuance completes into a test holder, over OID4VCI (issuer profile).
A presentation completes and verifies, over OID4VP (verifier and wallet profiles).
Revocation is honoured — a revoked credential is refused against the signed status list.
Bad input is refused — malformed, expired and replayed are each rejected, not tolerated.

Live The certification engine is wired to the desk. Your status page shows each exercise above with what it proves, what was observed, and — on anything that is not green — the concrete fix. Exercises that could not run say so; they are never shown as failures, and never as passes.

Sandbox — and why it can never be mistaken for production

There is no separate sandbox host and no parallel “test mode” that can drift from the real one. You build inside the demo namespace on the same platform, and that namespace is marked permanently, in code.

The demo law

A demonstration organization’s slug starts with demo-.
Its display name ends with “ (Demo)”.
A demo organization is never un-marked — not in the console, not in a wallet, not in an export.
Fixture data answers fixtures: true on the wallet bridge. That flag is an honesty marker, not a debug switch.
A demo organization is never promoted into a real one. Real organizations exist only through the provisioning ceremony — which is also why nothing you do here can produce one.

Because the marking is a predicate the platform enforces rather than a label people remember, demo-hygiene sweeps select exactly the demo organizations: they can never take a real one with them, and can never miss a demo one that was renamed to look real.

Practically: credentials you issue in a sandbox are real SD-JWT VCs signed by a demo issuer, so the wire is identical — but every surface that shows them says what they are, and no relying party can mistake the issuer for a production one.

Live vs. planned on this surface

The same honesty table /developers publishes, applied to the partner pipeline itself. A page existing is not a claim that the capability behind it is running.

Partner-surface state on this deployment.
Capability	State	What that means for you
Profile paths, pipeline, sandbox law — these pages	Live	Served from this deployment. The stages and profiles are read from the platform’s own definitions, not retyped here.
Verification rail for a relying party — `/verify/*`	Live	Public and CORS-open. No account, no key, no application. Start now.
Application intake — `POST /api/partners/applications`	Live	Applications are recorded and enter the operator review queue.
Status lookup — `POST /api/partners/applications/status`	Live	Needs your reference and your contact email. There is no route that lists partners, and no way to walk references.
Certification readiness board	Live	Your status page shows each exercise with its evidence.
Self-service sandbox provisioning (one click)	Not built	A sandbox is created by an ORBIS operator when your application reaches that stage. Nothing on a public page can provision an organization.
Marketplace listing for certified partners	Not built	Planned, and derived from certified capability rather than self-asserted. It does not exist today, so applying does not get you one.
Self-service API keys	Partial	All three phases are built and the routes are mounted: a partner signs in with a code sent to the contact email on their approved application, then mints, lists, rotates and revokes keys inside the grant an operator attached at go-live. The tenant comes from that stored grant and is never read from the request, so a key cannot be pointed at another customer. What is still missing is the customer record the grant should hang off — grants are keyed by application reference today — and the portal screens a partner would use, so in practice an operator still attaches the grant before any of this is reachable for a given partner. Whatever you mint is revealed to you exactly once: ORBIS keeps only a hash and can never re-show a token. No public form mints or displays one — every key comes from a session opened by a code sent to the contact email on your own application.

The API reference lives at /developers and the machine-readable contract at /openapi.json. Nothing on this page restates them — they are the one source.

Start integrating.