Guide
Applications
How ORN API access is organised: applications hold scopes and an environment, credentials authenticate against them, and everything rolls up to your organization.
The access model
API access belongs to your organization. Inside it, you create applications, and inside each application you create credentials (API keys). Every request is authenticated through that chain: key → credential → application → organization — and all three layers must be active for the request to proceed.
| Layer | Carries | Lifecycle |
|---|---|---|
| Organization | Subscription tier, platform data link, wallet | Active or deactivated by ORN |
| Application | Name, environment (sandbox/production), granted scopes | Active or deactivated; managed in the console |
| Credential | API key (hashed), display prefix, optional expiry | Active, revoked or expired |
Managing applications
Applications and credentials are managed in the Developer Console in your dashboard (Developer → API). Creating an application registers its name and environment; creating a credential mints an API key that is shown exactly once at creation.
- Create one application per integration so usage, scopes and credentials stay separable.
- Start in the sandbox environment; create a production application when your integration is verified.
- Revoke credentials from the console the moment a key is no longer needed or may have leaked.
- Deactivating an application blocks all of its credentials immediately.
Scopes are granted to an application, not to individual keys — every credential of the application operates within the application’s scopes (see Scopes).
Environment isolation
Each application is bound to one environment, and the key’s encoded prefix must match it. A sandbox key against a production application — or the reverse — is rejected as UNAUTHORIZED before any lookup-dependent logic runs. This makes it structurally impossible to point test traffic at production records by mistake.