UMW Recordings API Authentication: Keys and OAuth 2.0

All requests to the UMW Recordings API must be authenticated. Credentials are issued after your organization completes the partner approval process — once approved, you can generate and manage credentials from the UMW Partner Portal. Choose the authentication method that best fits your integration architecture: API keys for server-to-server workflows, short-lived Bearer tokens for session-based access, or OAuth 2.0 for enterprise clients requiring delegated authorization.

Authentication Methods

API Keys
Bearer Tokens
OAuth 2.0

API keys are the default authentication method for server-to-server integrations. They are long-lived credentials scoped to your organization and provide a straightforward way to authorize requests without a token exchange step.Include your API key in the Authorization header of every request using the Bearer scheme:

Authorization: Bearer sk_live_xxxxxxxxxxxxxxxxxxxx

Full request example

curl https://api.umwrecordingsinc.com/v1/releases \
  -H "Authorization: Bearer sk_live_xxxxxxxxxxxxxxxxxxxx"

API keys are scoped to your organization and carry the full permissions of the issuing account. Never expose API keys in client-side code, public repositories, or browser environments. Use separate keys for sandbox and production workloads.

Bearer tokens are short-lived credentials suitable for session-based access. They follow the same Authorization header format as API keys and are ideal when you need time-bounded access control.

Authorization: Bearer <your_bearer_token>

Token expiration and refreshBearer tokens expire after 24 hours. Before expiry, exchange your refresh token for a new access token by calling the /v1/auth/token endpoint with grant_type: refresh_token:

curl https://api.umwrecordingsinc.com/v1/auth/token \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{
    "grant_type": "refresh_token",
    "refresh_token": "your_refresh_token"
  }'

A successful response returns a new access_token and an updated expires_in value. Build refresh logic into your integration to avoid unexpected 401 errors on long-running sessions.

OAuth 2.0 is available for approved enterprise clients that require delegated access on behalf of sub-accounts or downstream partners. Contact your UMW partner manager to enable OAuth 2.0 for your organization.Client credentials flowThe client credentials flow is the recommended grant type for machine-to-machine communication:

Exchange credentials for an access token

Send your client_id and client_secret to the token endpoint:

curl https://api.umwrecordingsinc.com/v1/auth/token \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{
    "grant_type": "client_credentials",
    "client_id": "your_client_id",
    "client_secret": "your_client_secret"
  }'

A successful response returns the following payload:

{
  "access_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...",
  "token_type": "Bearer",
  "expires_in": 3600
}

Authorize requests with the access token

Include the returned access_token in the Authorization header of every subsequent API call:

Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...

Access tokens issued through OAuth 2.0 expire after the number of seconds specified in expires_in. Repeat the token exchange before expiry to maintain uninterrupted access.

Credential Security Best Practices

Protecting your credentials is your responsibility as an API partner. Apply the following practices across all environments.

Use Environment Variables

Store all credentials — API keys, client secrets, and tokens — in environment variables or a secrets manager. Never hardcode credentials in source code or configuration files.

Rotate Compromised Keys Immediately

If you suspect an API key has been exposed, revoke it immediately from the Partner Portal and issue a replacement. Treat all previously issued requests using that key as potentially unauthorized.

Separate Sandbox and Production Keys

Always use distinct credentials for sandbox and production environments. This prevents accidental writes to production data during testing and simplifies access auditing.

Never Expose Credentials Client-Side

API keys and client secrets must only be used in server-side code. Do not include credentials in browser bundles, mobile app binaries, or any output that could be inspected by end users. Never log request headers containing authorization values.

Authentication Errors

The UMW API returns standard HTTP status codes when authentication fails. The table below describes the two most common authentication error responses.

Status Code	Name	Description
`401 Unauthorized`	Missing or invalid credential	The request did not include a valid `Authorization` header, or the provided credential is malformed, expired, or has been revoked. Verify that you are sending the correct key or token and that it has not been rotated.
`403 Forbidden`	Insufficient scope	The credential is valid, but it does not have the permissions required to access the requested resource or perform the requested action. Review the scopes assigned to your credential in the Partner Portal.

Get Started

Platform Guides

Platform Reference

UMW Recordings API Authentication: Keys and OAuth 2.0

Authentication Methods

Credential Security Best Practices

Use Environment Variables

Rotate Compromised Keys Immediately

Separate Sandbox and Production Keys

Never Expose Credentials Client-Side

Authentication Errors

​Authentication Methods

​Credential Security Best Practices

Use Environment Variables

Rotate Compromised Keys Immediately

Separate Sandbox and Production Keys

Never Expose Credentials Client-Side

​Authentication Errors

Authentication Methods

Credential Security Best Practices

Authentication Errors