Programmatic API access

What exists today for authenticated API access, and what is planned for API keys, developer portal, sandbox, and outbound webhooks.

Programmatic API access is on the roadmap, but the self-service developer experience is not available yet. These docs intentionally avoid fake API keys, fake sandbox credentials, or workflows that do not exist.

Developer portal and API keys are planned

OmniValVMS does not currently provide self-service API-key creation, key rotation, a dedicated sandbox, or client-configurable outbound webhook subscriptions. Use the real sign-in and bearer-token model described below until those capabilities ship.

What works today

Today, API calls authenticate the same way the platform does: sign in, receive an access token, and send it as a bearer token on subsequent requests.

  1. Create or use a client account

    Client Admin signup is available through the account endpoint.

  2. Sign in

    Exchange account credentials for an access token.

  3. Call APIs with a bearer token

    Send Authorization: Bearer <access-token> on each request.

  4. Refresh expired tokens

    Refresh the token before retrying reads or clearly idempotent requests that fail due to expiration. For P0 writes, reload state and history first.

What is not available yet

CapabilityCurrent status
Self-service API keysPlanned / not available yet
API key rotation/revocationPlanned / not available yet
Dedicated sandbox with synthetic dataPlanned / not available yet
Developer portalPlanned / not available yet
Client-configurable outbound webhooksPlanned / not available yet
Usage logs by API keyPlanned / not available yet

What to build against now

Use the API Reference for the actual current contract:

If you automate operational flows, design defensively:

  • Validate input before sending it.
  • Respect order state transitions; do not skip lifecycle gates.
  • Treat activation, assignment, QC, payments, and UCDP/EAD submissions as P0.
  • Refresh resources before retrying state-changing requests.
  • Record enough context to reconcile failures with order history and audit logs.

Possible future model

When self-service programmatic access ships, future documentation may include:

  • Creating API keys and viewing the secret once.
  • Rotating and revoking keys.
  • Scoping keys by role, client, and environment.
  • Viewing usage and audit logs.
  • Registering webhook endpoints and validating signatures.
  • Testing in a sandbox that cannot create real orders, payments, or submissions.

Until then, bearer-token authentication is the supported model.