Get your credentials

Get your credentials

Every Mulberry integration starts with the same four credentials: a Retailer ID that identifies your account, a Public Token for the browser SDK, an API token for server-to-server REST calls, and — if you call the external-partner API — an OAuth client ID and secret. This page explains what each one is for and how to get it.

🚧

Credentials are not self-serve

You cannot generate these yourself. Every credential is provisioned by Mulberry Partner Success and surfaced in the partner dashboard. If you don't see a credential you need, contact your Partner Success manager rather than looking for a "create token" button.

❗

Staging and production credentials are not interchangeable

Staging and production are separate environments with separate endpoints and separate tokens. A token issued for staging will be rejected by production, and vice versa. Build and test against staging, then swap in the production set before you go live — never hard-code one environment's token where the other runs.

Prerequisites

Before you start, make sure:

1. Your company has a signed Mulberry partner agreement.
2. You have a login for the partner dashboard.
3. You know which environment you're integrating against right now — staging or production.
4. You've read Choose your integration so you know which of these credentials your path actually uses.

What each credential is for

📘

Not every path needs all four

A storefront-only integration may use just the Retailer ID and Public Token. A server integration adds the API token. Only partners building against the external-partner API need OAuth client credentials. Confirm your path in Choose your integration.

Get your Retailer ID and Public Token

The Retailer ID and Public Token are both safe to expose in browser code, and you'll almost always use them together to stand up the SDK.

1. Sign in to the partner dashboard.
2. Switch to the environment you're working in (staging or production).
3. Open your account/credentials settings and copy the Retailer ID and Public Token.

You should now have two values: a short Retailer ID (an opaque identifier such as 1977319c08a9) and a Public Token. These are the only credentials the browser SDK needs — see Initialize the SDK for where the Public Token goes.

👍

You can verify the Public Token immediately

Drop it into mulberry.core.init({ publicToken: 'YOUR_TOKEN' }) on a test page. If init resolves without an authorization error, the token is valid for that environment.

Get your API token

The API token authenticates your server when it calls the Mulberry REST API — for example, to register a sale or manage an existing warranty.

1. In the partner dashboard, confirm you're in the correct environment.
2. Open your credentials settings and copy the API token (also called the access token).
3. Store it as a server-side secret. Never ship it to the browser or commit it to source control.

Send it on every server-to-server request as a bearer token:

Authorization: Bearer <your-api-token>

You should now be able to make an authenticated REST call. A request with a missing or wrong-environment token returns 401 Unauthorized. For the endpoints this token unlocks, see the Mulberry SDK reference.

🚧

Public Token and API token are not the same value

The Public Token authenticates the browser SDK; the API token authenticates your server. They are distinct credentials with different scopes. Sending the Public Token to a REST endpoint that expects the API token — or the reverse — returns 401 Unauthorized.

Get your OAuth client credentials

The external-partner API authenticates with OAuth instead of a static API token. Mulberry provisions a client ID and client secret; your server exchanges them for a short-lived access token using the client_credentials grant, then uses that token to register partner transactions and update them (including cancelling a warranty by updating its transaction).

1. Ask Mulberry Partner Success to provision external-partner API access for your account.
2. Copy the client ID and client secret from the partner dashboard, per environment.
3. From your server, request a token with grant_type=client_credentials, sending your client_id and client_secret.

A successful exchange returns an access token you then send as Authorization: Bearer <access_token> on external-partner API calls:

{
  "access_token": "eyJ0eXAiOiJK...",
  "token_type": "Bearer",
  "expires_in": 14400
}

You should now have a bearer token valid for four hours (expires_in is in seconds). Cache it and re-request a new one before it expires rather than minting one per call. Invalid credentials return invalid_client; a grant type other than client_credentials returns invalid_request.

📘

Two different "access tokens"

The static API token above and the OAuth access token here are different credentials for different APIs. The API token is long-lived and used as-is; the OAuth access token is short-lived and minted from your client ID and secret. Use whichever your endpoint requires.

Staging vs. production

Keep the two credential sets in separate configuration and select between them with an environment flag — don't paste tokens inline. When you're ready to ship, swap the whole set at once and re-verify against production before sending real traffic. See Test and go live for the cutover checklist.

👍

Credentials in hand?

Head to your platform guide or to Initialize the SDK to put the Public Token and Retailer ID to work.