├── LICENSE ├── README.md └── specs ├── openapi.json └── openapi_preview.json /LICENSE: -------------------------------------------------------------------------------- 1 | MIT License 2 | 3 | Copyright 2023 Discord 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: 6 | 7 | The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. 8 | 9 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Discord OpenAPI Specification 2 | 3 | This repository contains the public preview of the [OpenAPI 3.1 specification](https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.1.0.md) for [Discord's API](https://discord.com/developers/docs/reference). Currently, the spec is only available for the most recent Discord API version ([v10](https://discord.com/developers/docs/reference#api-versioning-api-versions)). 4 | 5 | > ⚠️ The public preview of the OpenAPI spec is subject to breaking changes without advance notice, and should not be used within production environments. 6 | 7 | ## Usage 8 | 9 | ### Spec Files 10 | 11 | Two versions of the spec are included—the standard spec and the preview spec: 12 | 13 | - [`openapi.json`](specs/openapi.json) is the standard spec that contains the stable, public API. 14 | - [`openapi_preview.json`](specs/openapi_preview.json) is the preview spec which contains unstable and/or experimental API features. **This should not be considered stable** or used in production environments. 15 | 16 | ### Integrating with Postman 17 | 18 | To use the spec with Postman, you can view the [public collection](https://www.postman.com/discord-api). 19 | 20 | ## Contributing 21 | 22 | OpenAPI spec contents are automatically generated, and therefore **we do not allow public contributions to this repo**. 23 | 24 | 🐛 For bug fixes or improvements, you can [open an issue](https://github.com/discord/discord-api-spec/issues). 25 | 26 | ## Spec conventions 27 | - This is a preview and it may be not correct. If you find discrepancies between the spec and our [docs](https://discord.com/developers/docs), other than the ones mentioned below, let us know, and follow the docs, not the spec. 28 | - Even though we define `anyOf` and `oneOf` unions, they all mean that only one type from the list can be used as a data format. E.g. `anyOf: {'Cat', 'Dog'}`, still means that you can either pass `Cat` or `Dog`, not `Cat+Dog`. This is signified by the custom extension `x-discord-union: oneOf`. We use `anyOf` when we technically can’t use `oneOf`. One of the reasons to do that is e.g. when all the fields are optional and the passed in data could be validated with more than one format. 29 | - We avoid over-specifying response fields and merely define field types, like `int32`, and we avoid defining specific minimums, maximums, etc. 30 | - Some fields typed as strings in our docs may be typed as ints in the spec. Our API accepts strings for int fields if they are parseable as ints. We think it’ll be more precise to spec these int-parseable strings as ints. 31 | 32 | ## Known issues 33 | - (almost) All nullable fields are additionally marked as optional and all optional fields are additionally marked as nullable. 34 | - Operations and fields don’t have descriptions. 35 | - Operations don’t have tags. 36 | - Flag fields don’t detail specific flag values and their meaning. 37 | - Optional query args are typed as nullable, even though it doesn’t make much sense. --------------------------------------------------------------------------------