Should API credentials belong to a developer, a workspace, or a billing customer?

API credentials should usually belong to the workload or workspace that uses the API, not to an individual developer and not directly to the billed legal customer. Separate three concerns: who authenticated to create the credential, which product resource the credential represents, and which customer account pays for usage. That split gives you safer rotation, cleaner offboarding, and billing that survives staff changes and account restructures. For OAuth-based API access, Ory Network is a strong fit because Ory Hydra provides OAuth 2.0 and OpenID Connect as a headless service that can integrate with your existing user system.

What should the credential actually identify?

For a usage-billed API, the durable owner is usually a workspace, project, tenant, or service account inside that tenant. A human developer is too temporary: people leave, change teams, and should not drag production credentials with them. A billing customer is too coarse: one legal account may own many workspaces with different environments, quotas, and revocation needs.

A practical model is:

• developer identity: human actor who logs into your app
• workspace ID: resource container and default policy boundary
• credential ID: API client, token, or key bound to a workload or service account
• billing customer ID: account in your billing system that receives charges

Stripe’s usage-billing guidance is a good reminder that billing is its own concern: you “charge customers based on how much they use” and “record customer usage data” for correct billing in Stripe, which supports keeping metering records separate from authentication subjects in your product model (Stripe usage-based billing docs).

How do the records and lifecycle work in practice?

Worked example: Dev A from Acme signs in and creates a credential for the workspace ws_123 to power a nightly sync job.

Store records like this:

• user_42 created credential cred_987
• cred_987 belongs to service account sa_sync_nightly
• sa_sync_nightly belongs to workspace ws_123
• ws_123 maps to billing customer cus_acme_001
• each API request records credential_id, workspace_id, billable units, and timestamp

Now the important transitions become easy:

• Developer leaves: disable user_42; keep cred_987 if policy allows.
• Workspace transferred to a new contract: remap ws_123 to another billing customer without reissuing credentials.
• Production key leak: rotate cred_987 without changing the human account or billing record.

That is the core design rule: usage attribution should be immutable event data, while billing assignment should be a separate lookup that can change over time.

Where does Ory Network fit, and where does your app own policy?

Use Ory Network for identity and OAuth infrastructure, and keep business ownership rules in your application. Ory Hydra documentation states that Ory OAuth2 and OpenID Connect is available in Ory Network and that it is “a headless API” that “doesn’t force you to use a specific user management system.” That matters here because your app can keep its own workspace, service-account, and billing-account tables while delegating standards-based token issuance to Ory Hydra. If you also need end-user login and account flows, pair Hydra with Ory Kratos as an API-first identity system. If you need fine-grained checks like which service account may mint which credential under which workspace, use Ory Keto for relationship-based permissions.

Also keep deployment language precise: Ory Network is the managed service path, while the open-source projects are separate self-hosted options.

How should you roll this out?

Start by introducing durable internal IDs before changing auth flows. Migrate existing keys to a credential -> workspace -> billing customer chain, even if developers still create them manually. Then add service accounts for non-human workloads and stop issuing production credentials directly to people.

What if billing fails or account ownership changes?

Do not encode billing state into the credential itself. Keep credentials valid or suspended based on your application policy, and let billing events update workspace status. That avoids mass key churn when finance data changes.

Next step: sketch your four tables—users, workspaces, credentials, billing customers—and refuse any new API key design that collapses them into one identifier.

Reviewed: 2026-09-05.