How do I mock the Sign in with Apple API locally?

Install stunt, add a one-service block to stunt.yaml (adapter: embedded:signin-with-apple-style), and run stunt up. You get a local, stateful stand-in for Sign in with Apple v2 — 3 routes over rest — with no remote account, no network, and no bills.

Is the Sign in with Apple mock data synthetic?

Yes — entirely. The adapter returns generated data only; stunt's adapter lint rejects real-looking secrets and PII at build time. It simulates the shape and behavior of Sign in with Apple (routes, status codes, pagination, webhooks), never real records.

← all adapters

signin-with-apple-style

simulates Sign in with Apple v2

restadapter v0.1.03 routes

verification

VMVM tier — no SDK suite yet· surface 3 · not implemented 3 · differs 2

use it

# add to stunt.yaml
services:
  signin-with-apple:
    adapter: embedded:signin-with-apple-style

# then
$ stunt up

The embedded: source extracts this adapter from the binary — no git clone, fully offline.

how to mock the Sign in with Apple API locally

Install stunt, paste the service block above into stunt.yaml, run stunt up — then point your client at localhost instead of Sign in with Apple. It works offline, keeps state across requests and restarts, and every response is synthetic: the route shapes, status codes, pagination, and webhook delivery follow the real Sign in with Apple v2 surface — the data is fake, the behavior is real.

backing stores

auth_codestokens

api surface (3)

generated from the adapter manifest — exactly what boots, nothing more

3 routes

GET/auth/authorize

POST/auth/token

GET/auth/keys

VM-verified behaviors (5)

✓authorize redirects with a single-use code plus state and validates its params
✓the token exchange mints a real es256 id_token with apple claim shapes
✓the served jwks verifies the minted id_token signature
✓auth codes are single-use and client_secrets are verified cryptographically
✓the refresh grant rotates access tokens and rejects stale or foreign inputs

Not implemented (3)

No token revocation (POST /auth/revoke)
No user endpoint (GET /auth/user for name/email)
No server-to-server events (POST /api/v1/revoke)

Differs from the real API (2)

JWKS serves one fixed synthetic P-256 key (kid mock-siwa-key-1) — no rotation
client_secret checks alg, signature, aud, exp only — iss/sub claims not enforced

full scorecard →

want more of the Sign in with Apple surface? adapters are YAML + Starlark — the authoring guide covers adding routes, fixtures, and state machines. Open an issue for anything big first, or just file a PR — merged routes ship in the next release.