# Networkless Clerk token verification
By default, token verification calls out to fetch your instance's JWKS (public keys), cached on a TTL. That is fine on a long-lived server, but on edge functions, short-lived workers, or latency-sensitive paths, you want networkless verification.
## The JWT key option
Pass the instance JWT key to `verifyToken()` / `authenticateRequest()` and no network call happens. Clerk's docs recommend setting these options as environment variables where possible.
To get the keys without Dashboard clicking, Clerk's own docs tell agents to run `npx clerk@latest api jwks` to fetch the instance's JWKS, and `npx clerk@latest env pull` to write keys into the project env file. Use those instead of hard-coding keys you copy from a screen.
## The three JWKS sources
Clerk's manual JWT verification guide lists three ways to get the public key:
1. The Backend API JWKS endpoint (`https://api.clerk.com/v1/jwks`).
2. Your Frontend API URL plus `/.well-known/jwks.json`.
3. Your instance's JWKS public key from the Dashboard.
Any of them works for manual verification with your own JWT library. If you go manual, you also own expiry, issuer, authorized parties, and clock-skew checks, which is why the SDK path is recommended.
## Checklist
- Prefer the SDK (`authenticateRequest()` / `verifyToken()`) over hand-rolled JWT verification. Manual verification skips claim checks by default.
- In serverless/edge, prefer the JWT key option so a cold start does not pay a JWKS fetch before it can auth its first request.
- The session token arrives via the `__session` cookie (same origin) or the Authorization header (cross origin). Your manual code must check both; the SDK already does.