How do I mock the Discord API locally?

Install stunt, add a one-service block to stunt.yaml (adapter: embedded:discord-style), and run stunt up. You get a local, stateful stand-in for Discord API v10 — 26 routes over rest — with no remote account, no network, and no bills.

Is the Discord API 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 Discord API (routes, status codes, pagination, webhooks), never real records.

← all adapters

discord-style

simulates Discord API v10

restadapter v0.1.026 routes

verification

SDKverified with discord-node 2.6.3 (floor)· surface 27 · not implemented 8 · differs 5

use it

# add to stunt.yaml
services:
  discord:
    adapter: embedded:discord-style

# then
$ stunt up

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

how to mock the Discord API locally

Install stunt, paste the service block above into stunt.yaml, run stunt up — then point your client at localhost instead of Discord API. 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 Discord API v10 surface — the data is fake, the behavior is real.

backing stores

oauth_codesaccess_tokensrefresh_tokensguildschannelsmessages

api surface (27)

generated from the adapter manifest — exactly what boots, nothing more · covers 3% of the real API's 242 routes (derived from spec discord-api-spec @ 10)

26 routes · +1 ws

GET/oauth2/authorize

POST/oauth2/token

GET/oauth2/@me

GET/users/@me/guilds

GET/users/@me

GET/guilds/{guild_id}

GET/guilds/{guild_id}/channels

POST/channels/{channel_id}/messages

GET/channels/{channel_id}/messages

GET/channels/{channel_id}/messages/{message_id}

GET/v10/channels/{channel_id}/messages/{message_id}

PUT/channels/{channel_id}/messages/{message_id}/reactions/{emoji}/@me

POST/channels/{channel_id}/messages/{message_id}/reactions/{emoji}/@me

POST/interactions

GET/v10/oauth2/authorize

POST/v10/oauth2/token

GET/v10/oauth2/@me

GET/v10/users/@me/guilds

GET/v10/users/@me

GET/v10/guilds/{guild_id}

GET/v10/guilds/{guild_id}/channels

POST/v10/channels/{channel_id}/messages

GET/v10/channels/{channel_id}/messages

PUT/v10/channels/{channel_id}/messages/{message_id}/reactions/{emoji}/@me

POST/v10/channels/{channel_id}/messages/{message_id}/reactions/{emoji}/@me

POST/v10/interactions

WS/gateway

SDK-verified behaviors (5)

✓users/@me resolves the bot user
✓guilds resolve with channels
✓message post lands in the channel history
✓single-message fetch round-trips
✓add-reaction is the real PUT and returns 204

Not implemented (8)

No message edit or delete: PATCH/DELETE /channels/{id}/messages/{msg_id}
No channel create/update/delete or channel webhooks endpoints
No reaction listing or removal endpoints (GET/DELETE /reactions/{emoji})
No application command registration (PUT /applications/{app_id}/commands)
No guild member endpoints (/guilds/{id}/members)
No DM channels (POST /users/@me/channels) or invite endpoints
No OAuth token revoke (/oauth2/token/revoke) or /applications/@me
No pins, typing, threads, or audit log endpoints

Differs from the real API (5)

gateway is a fixed script: HELLO, lenient IDENTIFY, READY, one synthetic MESSAGE_CREATE
Reactions are 204 no-ops — no reaction state is stored or echoed on messages
POST /interactions answers ping with type 1, everything else a type 5 deferred ack
posted messages emit signed MESSAGE_CREATE webhooks; real Discord dispatches via gateway
message listing pages via opaque after cursors + Link headers, not snowflake ids

full scorecard →

want more of the Discord API 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.