Webhook Discussion

[mahatoankitkumar]

Table structure - (### Updated)

• id UUID PRIMARY KEY (Can be removed if we use name as primary key)

• name VARCHAR(255) NOT NULL (Name to identify the webhook's purpose)

• description TEXT (Optional description of the webhook)

• enabled BOOLEAN NOT NULL DEFAULT true (Whether the webhook is currently active)

• url TEXT NOT NULL (The destination URL where the webhook will send requests)

• method VARCHAR(10) NOT NULL DEFAULT 'POST' (HTTP method (POST, GET, etc.))

• version TEXT NOT NULL (To generate the payload in multiple formats.)

• service_headers TEXT[] NOT NULL (Service-specific headers stored as array)

• authorization json (Authentication credentials/tokens)

• events TEXT[] NOT NULL ( Events/topics that trigger this webhook)

• max_retries INTEGER NOT NULL DEFAULT 0 (Maximum number of retry attempts for failed webhooks, currently can be set to 0 till we have retry logic implemented)

• status VARCHAR(50) NOT NULL DEFAULT 'active' (Last status of the webhook (e.g., active, failed), not sure if we would want this)

• last_triggered_at TIMESTAMP (When the webhook was last triggered)

• created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP

• updated_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP

API Structure -

1. Create a Webhook
   Endpoint: POST /webhooks
   { "name": "test", "description": "Triggered on experiment created", "enabled": true, "url": "https://example.com/webhook", "method": "POST", "custom_headers": {"x-tenant": "dev"}, "service_headers": [configVersion], "authorization": {"Auth": "Bearer token123"}, "events": ["ExperimentCreated"], "max_retries": 0 }
   Response: 201 Created (Webhook)

2. Get a List of Webhooks
   Endpoint: GET /webhooks
   Response: 200 OK ([Webhook])

3. Get a Single Webhook
   Endpoint: GET /webhooks/{id}
   Response: 200 OK (Webhook)

4. Update a Webhook
   Endpoint: PUT /webhooks/{id}
   { "name": "test", "description": "Triggered on experiment updated", "enabled": true, "url": "https://example.com/webhook2", "method": "POST", "custom_headers": {"x-tenant": "dev"}, "service_headers": [configVersion], "authorization": {"Auth": "Bearer token123"}, "events": ["ExperimentUpdated"], "max_retries": 0 }
   Response: 200 OK (Webhook)

5. Delete a Webhook
   Endpoint: DELETE /webhooks/{id}
   Response:204 No Content

[knutties]

@mahatoankitkumar - the stripe webhook reference is a good one - you have covered most of them.

1. Should we add API version (in case we need to generate the payload in multiple formats - based on the readiness of the merchant) ?
2. Does this mean we can call multiple webhook endpoints per event or the application will do the check if there is already a webhook associated with this endpoint ?
3. Service headers field is not that intuitive (we should add it always right - why does client have to choose this) ?

[mahatoankitkumar]

Should we add API version (in case we need to generate the payload in multiple formats - based on the readiness of the merchant) ?

Did thought of this, Can be added

Does this mean we can call multiple webhook endpoints per event or the application will do the check if there is already a webhook associated with this endpoint ?

Yes the application can check that while creation of the webhook

Service headers field is not that intuitive (we should add it always right - why does client have to choose this) ?

Yeah agree

[mahatoankitkumar]

@knutties Do we need
metadata (Set of key-value pairs that you can attach to an object. This can be useful for storing additional information about the object in a structured format.)
and
secrets (The endpoint’s secret, used to generate webhook signatures. Only returned at creation.) as columns here?
And was thinking do we need both enabled and status or we can eliminate one?