Authentication

Every Partner API request carries a Bearer token:

Authorization: Bearer YOUR_API_KEY
Content-Type: application/json

Your partner identity is inside the token. You never need to tell us who you are in a request body.

Getting a key

There are two routes, and they are not equivalent.

	Managed onboarding	Self-service
How	Talk to your account manager	Two API calls, no human involved
Time	Depends on the conversation	About two minutes
Rate limit	Negotiated, substantially higher	Free tier: 50 requests per hour
Your own branding at checkout	Yes	No, Chaiz branding
Which providers, durations, and payment terms you sell	Configured for your business	Chaiz defaults
Handoff and attribution set up for you	Yes	Generic
Good for	Anything you intend to launch	Evaluating and prototyping

Most partners should go through managed onboarding. Almost everything that makes an integration feel like yours rather than ours (your logo and colors on checkout, the plans you actually want to sell, payment terms, attribution so the sale is credited to you) is account configuration, and configuration is what onboarding sets up. Self-service gives you a key against Chaiz defaults, which is the right thing for a prototype and the wrong thing for a launch.

Email dev-support@chaiz.com to start. You can prototype self-service in the meantime; the integration code is identical, so nothing is wasted when you switch.

See what your account controls for the full list of what onboarding configures.

Self-service registration

For prototyping and evaluation. Skip this if you are being onboarded; your account manager issues your credentials directly.

sequenceDiagram
    autonumber
    participant You
    participant API as Chaiz API
    participant Mail as Your inbox

    You->>API: POST /Partners/Register
    API-->>You: 200 accepted
    API->>Mail: verification code
    Mail-->>You: code
    You->>API: POST /Partners/Register/Verify
    API-->>You: 201 with your API key
    Note over You: shown once, store it now

Register. POST /api/v2/Partners/Register with contactEmail, displayName, and agreedToTerms: true. We email a verification code. One registration per email address.
Verify. POST /api/v2/Partners/Register/Verify with the same email and the code. The response contains your API key, partner ID, tier, and rate limits.
Store the key. It is shown once. If you lose it, rotate rather than re-register.

Codes expire, and too many failed attempts invalidates the pending registration, in which case start again at step 1. Both of these calls are unauthenticated; every other endpoint is not.

Worked example with runnable curl: Quickstart.

Environments

Environment	Base URL
Production	`https://api.chaiz.com`
UAT	`https://chaiz-api-uat.azurewebsites.net`

Keys are issued per environment and are not interchangeable. A UAT key against production returns 401. Register separately in each.

Managing your key

All three require your current key as the Bearer token.

Operation	Endpoint	Effect
Rotate	`POST /api/v2/Partners/Register/Rotate`	Issues a new key and invalidates the old one immediately. There is no grace period, so deploy the new key before you rotate, or plan for a brief gap.
Inspect	`GET /api/v2/Partners/Register/Usage`	Returns your registration details, tier, and current rate limits
Deactivate	`DELETE /api/v2/Partners/Register`	Permanent. The key stops working and cannot be reactivated. You would need to register again.

Rotate when a key may have been exposed, when someone with access to it leaves, or on whatever schedule your own policy requires. Enterprise credentials are rotated by your account manager rather than through this endpoint.

The optional `partner` field

Several request bodies accept a partner field. Leave it out. We resolve it from your token.

If you do send it, it must match your token's partner identity exactly, or the request is rejected. The field exists for older integrations and offers no benefit in new ones.

Security requirements

These are obligations under the API License and Acceptable Use Policy, not suggestions.

Keep the key server-side. Treat it as a password with no expiry. Store it in environment variables or a secrets manager, never in source control, and never in anything that reaches a browser or a mobile binary. A key in client-side code is a key that has been published.

HTTPS only. Plain HTTP requests are rejected.

You are responsible for all activity performed with your credentials, and you remain liable for unauthorized use until you notify us. If a key may have been exposed, rotate it immediately via POST /api/v2/Partners/Register/Rotate, then email legal@chaiz.com.

When authentication fails

Response	Meaning	What to do
`401`	Missing, malformed, expired, rotated, or deactivated key; or a key from the wrong environment	Check the `Authorization` header format, then confirm the key matches the environment you are calling
`403`	Authenticated, but not permitted to use this endpoint	The endpoint needs a capability your account does not have. Contact dev-support@chaiz.com
`429`	Rate limit exceeded	Back off and retry after the `Retry-After` header. See Errors & Rate Limits

A partner field that disagrees with your token surfaces as an authorization error, not a validation error. If a request fails with auth errors and you are sure the key is good, check whether you are sending partner.

Next steps

Quickstart to make your first authenticated call.
Choose Your Integration to decide what to build.
Errors & Rate Limits for tier limits and retry behavior.

Authentication problems, tier changes, or enterprise credentials: dev-support@chaiz.com.

Quickstart

Choose Your Integration