Clerk promises at least 30 days' notice before billing M2M tokens

Clerk's dashboard now charts token creation and verification as two series, according to the GA announcement as a dev.to post relays it ^[3]. They are separate because they count different events. Creation happens when a worker mints a credential. Verification happens when a receiving service checks one. The post warns that a very short lifetime can raise creation traffic if workers keep minting new credentials ^[10].

Token format decides where verification happens. The SDK creates opaque tokens by default ^[7]. Per the createToken() reference, opaque tokens use the server-side verification path, and JWTs can be verified locally without a network request ^[8]. The post frames the tradeoff this way: local verification can reduce a request dependency, and opaque verification gives a centralized check ^[9].

That choice will matter for the bill. The post does not say what Clerk will charge or which of the two events it will meter ^[18]. Until Clerk says, a team can only measure its own counts under each format.

Reuse is the lever on the creation side. Per Clerk's reference, the minRemainingTtlSeconds parameter lets the server reuse an opaque token when the machine, the claims and the scope all match ^[11]. A worker that starts often could hold one token until it nears expiry instead of minting one per start. The post tells teams to assess whether that reuse is safe and to set an expiration that fits the job's operational window ^[12]. A very long lifetime pulls the other way, because it extends the exposure window ^[10].

In our view, the creation count is the one a team can change cheaply, because reuse is a parameter. The verification count follows request volume under opaque tokens. Whether that matches Clerk's meter is unknown.

The post's sequence for adopting M2M tokens, in order:

1. Build a table that lists each caller with the service it calls, the operation it performs, the credential it uses now, the data it needs and who owns it. Cover HTTP calls between services as well as cron jobs, queue consumers, internal webhooks and deploy jobs ^[13]. 2. Give each workload its own identity. The post says separate identities make it easier to revoke one job without disrupting others ^[15]. 3. Deploy the receiving service's verification path before switching any caller ^[15]. 4. Switch one caller at a time, with a rollback plan for each ^[15]. 5. Read creation and verification counts separately before deciding which calls belong on M2M credentials and which stay user-delegated ^[17].

The post also says M2M tokens are not a reason to replace user sessions or every existing API key ^[16].