Hi @Matt_Bowser ,
There might be some confusion with how the opt_fields
query param works for our webhooks.
For context, the opt_fields
option for our Establish a webhook is meant for the response from creating that webhook not for the webhook events that your target URL receives.
So let’s say you made a call to our Establish a webhook endpoint. With the following request body:
{
"data": {
"resource": "<PROJECT_GID>",
"target": "<YOUR_TARGET_URL>"
}
}
You will get a response like the following:
{
"data": {
"gid": "<WEBHOOK_GID>",
"resource_type": "webhook",
"resource": {
"gid": "<PROJECT_GID>",
"resource_type": "project",
"name": "Test Project"
},
"target": "<YOUR_TARGET_URL>",
"active": true,
"is_workspace_webhook": false,
"created_at": "2023-05-19T21:36:29.054Z",
"last_failure_at": null,
"last_failure_content": "",
"last_success_at": "2023-05-19T21:36:29.386Z",
"filters": []
}
}
Now let’s say you do this again but this time specify target
in the opt_fields
query params. The result you will get back from this creation request will look like:
{
"data": {
"gid": "<WEBHOOK_GID>",
"target": "<YOUR_TARGET_URL>"
}
}
Now you probably want to ask how would you receive information about what the fields changed to and from → We recommend that you extract the gid of the resource the webhook event sent back and make another API call to get that information. Our webhooks are specifically designed not let users specify which properties they want back from our events for security reasons because we don’t want attackers to intercept webhook event responses and see sensitive data. Instead we rely on our developers to use the information they received from the event to look up the information they need. (See my comment here on this forum thread)
I hope this makes sense. Let me know if I mis-understood your question.