Operating Model
US Video API currently uses an account-centric enterprise model. One shared account acts as the billing and execution workspace. Members can be invited into that workspace with role-based access. This is meant to be operationally simple:
- One account wallet
- Shared API keys and job history
- Controlled member access
- Clear billing ownership
Roles
| Role | Use It For | Permissions |
|---|---|---|
| Owner | Primary business owner or team lead | Full billing, member, key, and job control |
| Billing Admin | Finance or operations | Can view balance and transactions, and add funds; cannot manage members or keys |
| Developer | Engineering, automation, internal tooling | Can create/manage API keys and run jobs; cannot change billing or membership |
| Viewer | Leadership, procurement, client-facing oversight | Read-only access to account state |
Billing Control
The wallet is shared at the account level. That means all charges and deposits affect the same balance. For most teams, the cleanest setup is:
- Owner keeps final control.
- Billing Admin handles deposits and transaction review.
- Developers use keys and generate jobs, but do not top up.
This gives leadership a simple answer to “who controls spend?” without blocking API usage.
Engineering Access
Developers normally need only three things:
- API key visibility
- Ability to create or rotate keys
- Ability to submit and monitor jobs
Use one key per service or environment and name keys clearly so they can be rotated without confusion.
Member Lifecycle
The intended lifecycle is:
- Owner sends invite from
Shared Access. - Invitee signs in with the invited email.
- Owner assigns
billing_admin,developer, orviewer. - When someone leaves, owner removes them and rotates affected keys if needed.
Do not share one login across multiple people. Shared access exists specifically to avoid that.
Audit & Oversight
The admin side now tracks actions in a more enterprise-readable shape:
- Actor: who performed the action
- Account: which shared account was affected
- Target: which invite, user, key, or job the action touched
This is designed to make member management, billing actions, and operational changes easier to review later.
Recommended Setup
For most enterprise buyers evaluating quickly, this structure works well:
| Function | Recommended Role |
|---|---|
| CTO, founder, GM, or team owner | Owner |
| Finance, ops, procurement | Billing Admin |
| Backend engineer, automation engineer, product engineer | Developer |
| Executive visibility, partner visibility, client read-only access | Viewer |
Enterprise FAQ
How do shared accounts work?
A shared account gives one wallet, one execution workspace, shared API keys, and invited members with controlled roles.
What roles are available?
The current roles are owner, billing_admin, developer, and viewer.
Who should control billing?
Keep billing with the owner or a billing admin, and let developers focus on keys and jobs. That split is usually the cleanest enterprise operating model.