The change to make now
Clerk’s machine-to-machine (M2M) tokens reached general availability on October 14, 2026. If your application has background workers or backend services calling one another, this is a good moment to review which credentials they use and what the new usage model could cost. It is not a reason to replace user sessions or every existing API key.
Clerk describes M2M tokens as credentials for communication between machines in your own infrastructure. Its GA announcement says the APIs are stable for production, and adds dashboard charts for token creation and verification activity. The announcement also reiterates planned usage charges, but says billing is not live and that Clerk will provide at least 30 days’ notice before it begins.
The useful first step is therefore an inventory, not a broad migration: identify service-to-service calls, assign an identity to each caller, and measure token creation and verification separately. Then decide which calls belong on M2M credentials and which should remain user-delegated.
Match the credential to the caller
Authentication should describe who is making a request and whose authority it carries. A browser session represents a signed-in person. A service credential represents a workload. An API key that a customer creates for your product may represent that customer’s delegated access. Treating these as interchangeable makes permissions hard to reason about and rotation risky.
For a worker that performs a scheduled export, for example, a user’s session cookie is the wrong long-lived credential. The worker should have its own machine identity, with only the machine-to-machine relationship it needs. If it acts on behalf of a particular user, that is a different authorization design: preserve the user context and use an appropriate delegated flow instead of silently converting the worker into a broad machine principal.
Give each workload only the specific machine relationship and access it needs. This is a conceptual explanation, not a Clerk interface.
Clerk’s machine-authentication guide distinguishes M2M tokens for communication between services in your infrastructure from OAuth access tokens used to act on behalf of a user and API keys that your application’s users create. The guide also says Clerk does not currently support the OAuth client-credentials flow. Check that distinction before changing a client integration; the name “machine authentication” alone does not tell you which type fits.
Inventory calls before issuing tokens
Start with a short table in your own system. Record the caller, receiver, operation, current credential, required data, and owner. Include cron jobs, queue consumers, internal webhooks, deployment jobs, and service-to-service HTTP calls. This often reveals credentials that were copied from a developer account or reused because they were easy to provision.
For each row, answer these questions:
- Is the caller a workload, a user, or a customer integration?
- Which receiving machine should accept it?
- Which operations must it perform, and which must remain forbidden?
- What happens if the credential is exposed or the caller is retired?
- Who owns rotation and incident response?
Do not create a single “backend” identity for unrelated workers just to make the migration faster. Separate identities make it easier to revoke one job without disrupting others. Configure communication relationships deliberately, then deploy the receiving service’s verification path before switching callers. Keep a rollback plan that changes one caller at a time.
Choose token format and lifetime intentionally
Clerk’s SDK creates opaque M2M tokens by default. Its createToken() reference also supports JWT format; the reference says JWTs can be verified locally without a network request, while opaque tokens use the server-side verification path. These are different operating tradeoffs. Local verification can reduce a request dependency, while opaque-token verification gives you a centralized check. Evaluate the current Clerk documentation and the failure modes your application can tolerate before choosing.
Set an expiration that fits the job’s operational window, rather than allowing a credential to live indefinitely by accident. A very short lifetime can increase token creation traffic if workers repeatedly mint credentials; a very long one can extend the exposure window. If a worker starts frequently, assess whether it can reuse a token safely until it approaches expiration. Clerk’s reference documents minRemainingTtlSeconds for server-side reuse of opaque tokens with matching machine, claims, and scopes. It also rejects a threshold greater than or equal to the effective token lifetime.
Keep machine secret keys in server-side secret storage, never in a browser bundle, mobile app, source control, or logs. Limit which deployment environments can read each secret. Make revocation and rotation an exercised procedure: revoke a test machine token, confirm the receiver rejects it, and document how to restore service with a newly issued credential.
Estimate usage from observed behavior
The GA announcement says Clerk plans to charge $0.001 per token creation and $0.00001 per verification of opaque tokens. It says billing is not live and promises at least 30 days’ notice before billing begins. Treat those figures as the announced model, then verify the current terms before budgeting or shipping a pricing promise to customers.
Use the new dashboard usage charts to observe creation and verification counts. A rough estimate for opaque tokens is:
estimated monthly usage = (creations × 0.001) + (verifications × 0.00001)
For example, 10,000 creations and 2,000,000 opaque-token verifications would imply $10 plus $20 under the announced rates, or $30 before any other applicable plan terms. This is arithmetic on the published unit rates, not a forecast or a Clerk invoice. Your actual usage can differ, and the terms may change. Measure a representative period, include peak traffic, and set an internal alert threshold before billing starts.
Creation and verification counts point to different design choices. High creation volume may mean short-lived workers are minting on every request rather than reusing credentials. High opaque verification volume may reflect request volume itself; it is not automatically waste. Optimize only after you understand the security and reliability consequences. If you test JWT verification or token reuse, compare total work, revocation behavior, and operational complexity—not just the lower line item.
Measure token creations and verifications separately, then plan credential rotation from observed behavior before billing starts.
Roll out one service at a time
Choose a low-risk caller first. Create its machine identity, configure the allowed relationship, and add verification at the receiver. Test valid, expired, malformed, and revoked credentials. Confirm that an unrelated machine is rejected. Add dashboards or logs for authentication failures without recording token contents or machine secrets.
Switch that caller behind a controlled rollout. Track successful requests, rejected requests, token creation, and verification volume. Keep the previous credential available only for the rollback period, restrict it during that period, and remove it once the new path is stable. Repeat for the next caller. This makes failures attributable and keeps an auth change from becoming a simultaneous rewrite of every backend integration.
If a call is actually on behalf of a signed-in user, stop and revisit the design instead of forcing it into this rollout. The machine’s own identity cannot by itself preserve the user’s permissions or consent. Conversely, a background maintenance task should not borrow a human session just because a user identity already exists.
Where an app starter fits
An app shell can help you build the operational surfaces around a backend change: an issue list, service inventory, usage dashboard, or rollout checklist. OTF’s SaaS Dashboard starter is an editable UI starting point for that kind of app work. It does not include Clerk M2M token support, identity configuration, or this migration; those require your own backend implementation. If you are planning the surrounding interface, see our SaaS dashboard table-column preferences guide for an example of adapting a real table screen.
A practical checklist
- Classify every caller as user, customer integration, or workload.
- Separate service identities by responsibility and owner.
- Configure only the machine relationships and operations each caller needs.
- Pick token format, expiry, reuse, rotation, and revocation behavior deliberately.
- Deploy receiver verification before switching one caller at a time.
- Observe creation and verification charts, estimate usage, and set an alert threshold.
- Recheck Clerk’s current pricing and notice before billing starts.
The GA milestone makes M2M tokens a production option, while the usage charts make it easier to learn how a system would use them. The safest next action is to map and measure a narrow service-to-service path, then migrate it with a rollback plan. That gives you evidence about both the security boundary and the expected usage before you expand the change.
Top comments (0)