Machine-to-machine (M2M) tokens

Partner integrations — backends, automation bots, third-party services — authenticate as a machine principal using a Clerk M2M token. No human session, no users row.

Using the token

Send it as a normal bearer token, on REST and on the WebSocket handshake:

// REST
fetch('https://api.myscore.live/api/v1/matches', {
  headers: { Authorization: `Bearer ${process.env.MYSCORE_M2M_TOKEN}` },
});

// WebSocket
io('https://api.myscore.live', { auth: { token: process.env.MYSCORE_M2M_TOKEN } });

A valid M2M token lets you read public data and subscribe to public match rooms. An expired or invalid token is rejected with 401 on REST; on WebSocket the connection falls back to anonymous and non-public subscriptions return an error event.

The #1 gotcha: token id vs secret

A Clerk M2M token object has two mt_-prefixed fields. Only one authenticates:

Field	Format	Use
id	mt_ + 32 lowercase hex (mt_5d40…b790)	identifier only — cannot authenticate
secret / token	mt_ + UPPERCASE alphanumeric (mt_NHXG…J0SM)	the actual bearer token

Clerk reveals the secret only once, at creation. The dashboard list afterwards shows only the id. If you get Authentication required with a token that’s all lowercase hex, you’re using the id — regenerate and copy the secret shown at creation time.

Instances are environment-scoped

Tokens are scoped to a Clerk instance, so they don’t cross environments:

API	Clerk instance	Token works on
api.myscore.live (prod) + staging.myscore.live	production	both prod & staging
test.myscore.live	development	test only

A prod token will not work against test, and vice-versa.

What partners can do

Read public match data over REST, and over WebSocket subscribe to public match rooms — see Integrate Live Scores ». The same data is always available over REST as a fallback.