Skip to content

add status and error fields to webhook records #150

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
j616 merged 2 commits into from
Sep 23, 2025
Merged

add status and error fields to webhook records #150

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
cf8cce8
add status and error fields to webhook records
danjhd Sep 19, 2025
be644e7
Add default value for webhook status
danjhd Sep 19, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 4 additions & 4 deletions api/TimeAddressableMediaStore.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -214,7 +214,7 @@ paths:
schema:
type: array
items:
$ref: "schemas/webhook-with-id.json"
$ref: "schemas/webhook-get.json"
"404":
description: "Webhooks are not supported by this API implementation"
post:
Expand Down Expand Up @@ -250,7 +250,7 @@ paths:
example:
$ref: "examples/webhook-get-200.json"
schema:
$ref: schemas/webhook-with-id.json
$ref: schemas/webhook-get.json
"400":
description: Bad request. Invalid parameters or unsupported event filtering or transformation.
"404":
Expand Down Expand Up @@ -292,7 +292,7 @@ paths:
example:
$ref: "examples/webhook-get-200.json"
schema:
$ref: "schemas/webhook-with-id.json"
$ref: "schemas/webhook-get.json"
"404":
description: The requested Webhook ID in the path is invalid, or Webhooks are not supported by this API implementation
put:
Expand Down Expand Up @@ -330,7 +330,7 @@ paths:
example:
$ref: "examples/webhook-get-200.json"
schema:
$ref: schemas/webhook.json
$ref: schemas/webhook-get.json
"400":
description: Bad request. Invalid parameters or unsupported event filtering or transformation.
"404":
Expand Down
19 changes: 19 additions & 0 deletions api/schemas/webhook-get.json
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,19 @@
{
"title": "Webhook Detail",
"description": "Describes a Webhook",
"type": "object",
"allOf": [
{
"$ref": "webhook-with-id.json"
},
{
"type": "object",
"properties": {
"error": {
"description": "Provides more information for the error status, as described by the [Error](../schemas/error#top) type",
"$ref": "error.json"
}
}
}
]
}
11 changes: 10 additions & 1 deletion api/schemas/webhook.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -86,6 +86,15 @@
"verbose_storage": {
"description": "Whether to include storage metadata in the `get_urls` property in `flows/segments_added` events. This option is the same as the `verbose_storage` query parameter for the /flows/{flowId}/segments API endpoint.",
"type": "boolean"
},
"status": {
"description": "Status of the Webhook. A disabled webhook will not POST events.",
"type": "string",
"default": "enabled",
"enum": [
Copy link
Contributor

@j616 j616 Sep 22, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this have "error" as an option to follow the pattern of Flow Delete Requests? I think the intention of that pattern is that the error object is only present when status is set to error. If we want to follow that pattern, and we want to make this user setable, we might want to think about the best way to indicate the values a client may set and the values a service instance may set. We should also probably describe what a client should do if a webhook enters the error status. e.g. could they set it back to enabled to try again if they fix an issue on the receiving end? Would there be any benefit to having the separate created and started states of the Flow Delete Requests here too? Or is it fair to assume the startup time is negligible?

Copy link
Contributor Author

@danjhd danjhd Sep 22, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did not think about it to this depth, apologies. You have valid points, my response is "yes"! The difference between created and started might be a way of indicating that at least one POST has occurred since creation? Just thinking out loud. I am certainly not too opinionated on the enum values. I just thought creating this PR was better than just leaving you to iron out the details ;)

"enabled",
"disabled"
]
}
}
}
}
Loading