What is discord-api-types?
The discord-api-types npm package provides TypeScript type definitions for the Discord API. It helps developers ensure type safety and autocompletion when interacting with the Discord API, making it easier to build bots and other applications that integrate with Discord.
What are discord-api-types's main functionalities?
Type Definitions for Discord API
Provides type definitions for various Discord API objects, such as users, channels, guilds, etc. This ensures that the data structures used in your application match the expected format of the Discord API.
import { APIUser } from 'discord-api-types/v10';
const user: APIUser = {
id: '1234567890',
username: 'exampleUser',
discriminator: '0001',
avatar: null,
bot: false,
system: false,
mfa_enabled: false,
banner: null,
accent_color: null,
locale: 'en-US',
verified: true,
email: 'example@example.com',
flags: 0,
premium_type: 1,
public_flags: 0
};
Enum Definitions
Includes enums for various constants used in the Discord API, such as channel types, message types, and more. This helps in avoiding magic strings and makes the code more readable and maintainable.
import { ChannelType } from 'discord-api-types/v10';
const channelType: ChannelType = ChannelType.GuildText;
API Interaction Types
Defines types for various interactions that can occur in Discord, such as commands, button clicks, and more. This helps in handling different types of interactions in a type-safe manner.
import { APIInteraction, InteractionType } from 'discord-api-types/v10';
const interaction: APIInteraction = {
id: '1234567890',
application_id: '0987654321',
type: InteractionType.Ping,
data: null,
guild_id: '1122334455',
channel_id: '5566778899',
member: null,
user: null,
token: 'aW50ZXJhY3Rpb25fdG9rZW4=',
version: 1
};
Other packages similar to discord-api-types
discord.js
discord.js is a powerful JavaScript library for interacting with the Discord API. It provides a higher-level abstraction over the raw API, making it easier to build bots and other applications. Unlike discord-api-types, which focuses on type definitions, discord.js provides a full-featured library with methods and classes for interacting with Discord.
eris
Eris is another JavaScript library for interacting with the Discord API. It is known for being lightweight and efficient, making it suitable for large-scale bot applications. Like discord.js, Eris provides a higher-level abstraction over the raw API, whereas discord-api-types focuses solely on type definitions.
discord-api
discord-api is a lower-level library that provides direct access to the Discord API endpoints. It is more similar to discord-api-types in that it focuses on providing a direct interface to the API, but it does not provide type definitions. Instead, it focuses on making HTTP requests to the API.
Discord API Types
Simple type definitions for the Discord API.
Installation
Install with npm / yarn / pnpm:
npm install discord-api-types
yarn add discord-api-types
pnpm add 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
const { APIUser } = require('discord-api-types/v10');
import { 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 are some examples
const { GatewayVersion } = require('discord-api-types/gateway/v10');
import { GatewayVersion } from 'discord-api-types/gateway/v10';
Note: The v*
exports (discord-api-types/v*
) include the appropriate version of gateway
, payloads
, rest
, rpc
, and utils
you specified, alongside the globals
exports
Deno
We also provide typings compatible with the deno runtime. You have 3 ways you can import them:
- Directly from GitHub
import { APIUser } from 'https://raw.githubusercontent.com/discordjs/discord-api-types/main/deno/v10.ts';
- From deno.land/x
import { APIUser } from 'https://deno.land/x/discord_api_types/v10.ts';
- From skypack.dev
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
or RESTGetAPIGatewayBotInfoResult
.
-
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 to REST<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 a 204 No Content
, so you can safely ignore it. This does not account for errors.
-
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.
A note about how types are documented: 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.