Skip to main content

Overview

The Zuba API uses OAuth 2.0 Client Credentials flow for secure M2M (machine-to-machine) authentication. You’ll exchange your Client ID and Client Secret for a short-lived JWT access token, which you’ll use to authenticate API requests.

Getting Your API Credentials

Step 1: Generate Credentials

  1. Log in to your Zuba Dashboard (see the Environments table for the Sandbox and production dashboards)
  2. Navigate to Developers → API Keys and generate a new key
  3. Important: Copy and save your credentials immediately - you won’t be able to see the Client Secret again!
You’ll receive the following credentials:
  • Client ID: Your application’s public identifier
  • Client Secret: Your application’s secret key
  • Auth0 domain: Append /oauth/token to get the token endpoint (e.g., https://zuba-test.us.auth0.com/oauth/token in Sandbox)
  • Audience: The environment-specific API identifier, returned when you create the key (e.g., https://api.sandbox.zuba.com in Sandbox)
Keep your Client Secret secure! Never share it publicly or commit it to version control. Treat it like a password. If compromised, immediately rotate your credentials in the dashboard.

Authentication Flow

Step 2: Request an Access Token

Exchange your Client ID and Client Secret for a JWT access token. The samples below use the Sandbox token URL and audience; for production, use https://auth.zuba.com/oauth/token with audience https://api.zuba.com (see Environments):
Successful Response:
The access_token is a JWT that’s valid for 24 hours (86400 seconds). You’ll need to request a new token when it expires.

Step 3: Use the Access Token

Include the access token in the Authorization header of every API request:

Token Management

Token Expiration

Access tokens expire after 24 hours. Implement token caching and refresh logic to avoid requesting a new token for every API call:
Example: Token Cache

Environments

Zuba provides separate environments for development and production:
Always test in Sandbox before moving to production. Use separate credentials for each environment, and request tokens with that environment’s token URL and audience; a token minted with the wrong pair is rejected with 401.

Authentication Errors

Token Request Errors

API Request Errors

Example error response:

Security Best Practices

Never hardcode credentials in your application code. Use environment variables:
.env
Always use HTTPS for both token requests and API calls. Never send credentials or tokens over HTTP.
Rotate your credentials regularly. Two paths:
  • Rotate the secret in place: use the dashboard (Developers → API Keys → Rotate) or POST /v1/api-keys/{clientId}/rotate-secret. The Client ID stays the same, but the old secret stops authenticating immediately, so update your deployment right away.
  • Zero-downtime rotation (or to rotate the Client ID itself): generate a new key, update your environment variables, deploy, then delete the old key in the dashboard.
  • Store tokens in memory, not in databases or files
  • Never log tokens in application logs
  • Clear tokens when they expire
  • In serverless environments, cache the token outside the function instance where possible (warm-container memory or a secrets/KV cache) rather than minting a new token on every invocation
Request only the permissions your application needs. Contact support to configure specific scopes for your credentials.

Testing Authentication

Test your authentication setup before making actual API calls. The JavaScript, Python, and Java samples reuse the token helper from Step 2:
A successful authentication test will return your account balances or an empty array if no balances exist yet.

Next Steps

Quickstart Guide

Start making your first API calls

API Reference

Explore all available endpoints