Introduction
About​
Discord API Types is a community-maintained project that brings API types for Discord's REST, Gateway and Voice APIs.
Installation​
Install with npm
/ yarn
/ pnpm
/ bun
/ deno
:
- npm
- yarn
- pnpm
- bun
- deno
npm install discord-api-types
yarn add discord-api-types
pnpm add discord-api-types
bun add discord-api-types
deno install npm:discord-api-types
Usage​
You can only import this module by specifying the API version you want to target. Append /v*
to the import path, where
the *
represents the API version. Below are some examples
- JavaScript
- ESM
- TypeScript
/**
* @type {import('discord-api-types/v10').APIUser}
*/
/**
* @type {import('discord-api-types/v10').APIUser}
*/
import { type APIUser } from 'discord-api-types/v10';
You may also import just certain parts of the module that you need. The possible values are: globals
, gateway
,
gateway/v*
, payloads
, payloads/v*
, rest
, rest/v*
, rpc
, rpc/v*
, utils
, utils/v*
, voice
, and
voice/v*
. Below is an example of importing directly from the gateway submodule
- CommonJS
- ESM
- TypeScript
const { GatewayVersion } = require('discord-api-types/gateway/v10');
console.log(`Let's connect to wss://gateway.discord.gg/?v=${GatewayVersion}`);
import { GatewayVersion } from 'discord-api-types/gateway/v10';
console.log(`Let's connect to wss://gateway.discord.gg/?v=${GatewayVersion}`);
import { GatewayVersion } from 'discord-api-types/gateway/v10';
console.log(`Let's connect to wss://gateway.discord.gg/?v=${GatewayVersion}`);
Note: The
v*
exports (discord-api-types/v*
) include the appropriate version ofgateway
,payloads
,rest
,rpc
, andutils
you specified, alongside theglobals
exports
Deno​
We also provide typings compatible with the deno runtime. Here are 3 examples of how you can import them:
- From GitHub
- From deno.land/x
- From skypack.dev
// Importing a specific API version
import { APIUser } from 'https://raw.githubusercontent.com/discordjs/discord-api-types/main/deno/v10.ts';
// Importing a specific API version
import { APIUser } from 'https://deno.land/x/discord_api_types/v10.ts';
// Importing a specific API version
import { APIUser } from 'https://cdn.skypack.dev/discord-api-types/v10?dts';
Project Structure​
The exports of each API version is split into three main parts:
-
Everything exported with the
API
prefix represents a payload you may get from the REST API or the Gateway. -
Everything exported with the
Gateway
prefix represents data that ONLY comes from or is directly related to the Gateway. -
Everything exported with the
REST
prefix represents data that ONLY comes from or is directly related to the REST API.-
For endpoint options, they will follow the following structure:
REST<HTTP Method><Type><Query|(JSON|FormData)Body|Result>
where the type represents what it will return.-
For example,
RESTPostAPIChannelMessageJSONBody
orRESTGetAPIGatewayBotInfoResult
. -
Some exported types (specifically OAuth2 related ones) may not respect this entire structure due to the nature of the fields. They will start with either
RESTOAuth2
or with something similar toREST<HTTP Method>OAuth2
-
-
If a type ends with
Result
, then it represents the expected result by calling its accompanying route.- Types that are exported as
never
usually mean the result will be a204 No Content
, so you can safely ignore it. This does not account for errors.
- Types that are exported as
-
-
Anything else that is miscellaneous will be exported based on what it represents (for example the
REST
route object). -
There may be types exported that are identical for all versions. These will be exported as is and can be found in the
globals
file. They will still be prefixed accordingly as described above.
This package will add types only for known and documented properties that are present in Discord's API Documentation repository, that are mentioned in an open pull request, or known through other means and have received the green light to be used. Anything else will not be documented (for example client only types).
With that aside, we may allow certain types that are not documented in the
API Documentation repository on a case by case basis. They will be
documented with an @unstable
tag and are not subject with the same versioning rules.