Implementing an alternate host for Discord webhook requests
Discohook publishes a schema for describing alternate hosts (proxies) for a subset of Discord's webhook endpoints, documented here. Usually the purpose of such a system is to obscure or modify transceived information (such as webhook tokens), for use with frontends like Discohook.This is a work in progress.
Details of the schema may change without notice. Discohook, the web editor, will support this functionality sometime soon. To contribute, discussion is open on #101. Basic Implementation Steps#
Servers MUST pass through response bodies as given, or else return compatible data (i.e. >=V8 error responses, appropriate status codes, API models in the same shape and location)1.
Expose your desired routes matching upstream, e.g. Get Webhook With Token must be accessible at {your origin}/api/v10/webhooks/:id/:tokenRemember that some endpoints are not disallowable and servers MUST implement them.
API versioning: Right now, only v10 will likely be used by clients. Servers MAY support lower versions (not recommended), but they MUST actually use the specified version on the backend so as to fulfill the expected response types.
Webhook IDs MUST NOT be proprietary. That is, clients need to be able to identify webhooks by their Discord-generated Snowflake ID, which is also present in some message properties (such as webhook_id), and is used to determine proper authorship.
2.
Serve a file (application/json) matching the schema at /.well-known/discord-webhook-proxy. It SHOULD be accessible by HTTP GET to all origins, whereafter the client can determine by cors_origin_allowed whether their requesting origin is allowed by the server to use the described endpoints.
Modified at 2026-10-27 14:43:27