For the complete documentation index, see llms.txt. This page is also available as Markdown.

Credentials

Create credentials to authenticate API's and SDKs once you create new credentials you can download or copy.

Go to Developer Portal -> Credentials -> Create New -> Enter Name

You will get the Client ID and Client Secret.

You can set the scope of each credential at the time of creation

Query: Read access to retrieve data and perform Localization queries

Write: Create and update access to modify existing Map, MapSet or Object Tracking data

Delete: Remove access to permanently delete Account data

How Credentials Work

MultiSet uses an OAuth 2.0–style client credentials flow for machine-to-machine (M2M) authentication. Your clientId and clientSecret are long-lived identifiers for your application; they are exchanged at runtime for a short-lived Bearer access token (JWT) that authorizes individual API calls.

MultiSet credentials authentication flow
Client Credentials → Bearer JWT → Authenticated API request

Step-by-step

  1. Create credentials in the Developer Portal. A clientId and clientSecret are generated and bound to your account, with the scopes you select (Query / Write / Delete). The secret is shown once — store it somewhere safe (env vars, a secrets manager, server-side config). MultiSet does not store a recoverable copy.

  2. Exchange credentials for an access token. Your application sends a POST request to https://api.multiset.ai/v1/m2m/token with an Authorization: Basic base64(clientId:clientSecret) header. The endpoint validates that the client is active, the secret matches, and the owning account is verified and active.

  3. Receive a Bearer token. On success, the response contains a signed JWT and an expiresOn timestamp. Tokens are valid for 30 minutes from issue.

  4. Call MultiSet APIs. Attach the token to every request as Authorization: Bearer <token>. This applies to REST endpoints (Map, MapSet, Localization, Object Tracking) and to SDK calls that route through the MultiSet cloud.

  5. Per-request validation. For each API call the backend verifies the token signature and expiry, checks that the credential's scope permits the requested route and method, and enforces the CORS allowlist configured for your account.

  6. Refresh before expiry. When the token expires (or you receive a 401), repeat step 2 to obtain a fresh one. There is no separate refresh-token flow — re-authenticate with clientId + clientSecret.

Scopes and authorization

Scopes are evaluated on every request. A token issued from a credential created with only the Query scope cannot perform write or delete operations, even if the route exists — the API will respond with 403 Forbidden. Choose the minimum scope your integration needs, and create separate credentials for read-only services (e.g. a public-facing localization client) versus tools that manage map data.

Security best practices

  • Never embed clientSecret in a shipped mobile app, public website, or git repository. Treat it like a password.

  • For server-side and back-office tools, store the secret in a secrets manager or environment variable and exchange it for a token at runtime.

  • For browser-based experiences (e.g. WebXR demos), prefer a thin backend proxy that holds the secret and returns short-lived tokens to the client. Direct in-browser exchange is convenient for prototyping but exposes the secret to anyone who views the page source.

  • Rotate credentials if you suspect exposure. Deactivate or delete the old credential in the Developer Portal — existing tokens issued from it remain valid until they expire (max 30 minutes), but no new tokens can be issued.

  • Restrict by origin. Configure your CORS allowlist so that browser requests can only be made from the domains you control. See Configuring Allowed Domains (CORS).

  • Use distinct credentials per environment (dev / staging / prod) so you can rotate or revoke one without affecting the others.

Where to use the token

Surface
How credentials are used

REST API

Exchange clientId/clientSecret for a token, then send Authorization: Bearer <token> on every request.

Unity SDK / Quest SDK

Configure clientId and clientSecret in the SDK; the SDK performs the token exchange and refresh internally.

iOS / Android native SDKs

Same as Unity — pass credentials to the SDK config and it handles token lifecycle.

For the full token-endpoint reference and copy-paste code samples, see Authentication.

Last updated

Was this helpful?