#Feature Request - Adding operation and endpoint metadata to webhook payloads

7 messages · Page 1 of 1 (latest)

knotty igloo
#

The Suggestion:
I would like to suggest that IGDB includes two specific fields in the JSON payload of every webhook: the operation type (create, update, or delete) and the source endpoint name (e.g., games, covers, etc.).

The Problem:
Currently, to differentiate between different entities and operations, I have to set up a unique listener URL for every combination of endpoint and action. Since there are approximately 71 endpoints, multiplying them by the 3 operations (create, update, and delete) would require me to create approximately 213 different listener endpoints. Managing this many listeners is extremely inefficient and creates unnecessary infrastructure and networking complexity.

The Solution:
If the operation and the endpoint were included directly in the payload, I could use a single open port and a single listener URL to receive all responses. This would allow me to handle all the routing logic internally in my application code, rather than having to configure and maintain over 200 separate listeners.

Benefits:
This change would greatly simplify infrastructure management and make it much more scalable. It is the only practical way to handle multiple webhooks without creating massive overhead in the development and deployment process.

Example:

{
"operation": "update",
"endpoint": "games",
"timestamp": 1711486400,
"id": 12345,
"name": "Elden Ring",
"summary": "Rise, Tarnished...",
"platforms": [6, 130, 167]
}

winged rain
#

Hello! 👋

Thank you for your suggestion!

I've taken note of your concerns and will create tickets to explore what we can do here.

The current webhook implementation makes some changes more involved than others, especially since existing users have built their integrations around the current behavior.

I agree that having to set up a unique listener URL for every combination of endpoint and operation is cumbersome.

One concern with your proposed example is that modifying the webhook payload could break existing integrations. However, looking at the current code, I believe we can achieve the same goal by including additional HTTP headers with each webhook request instead.

The plan would be to add two new headers to every webhook delivery:

  • X-IGDB-Operation for the operation type (create, update, or delete)
  • X-IGDB-Endpoint for the source endpoint name (e.g., games, covers, etc.)

This way, you could use a single listener URL and route internally based on those headers, without us needing to alter the payload structure that existing users depend on.

I'll create tickets to track. Thanks again for the feedback!

gleaming arrow
#

I would agree with the approach of modifying HTTP headers to indicate the endpoint and method of webhook notifications. This would be aligned with how Twitch EventSub handles this.

knotty igloo
knotty igloo
gleaming arrow
knotty igloo
#

Thanks