Shortcomings of Zendesk Webhooks

Expanded API Support via Custom Authentication for Zendesk Webhooks

Zendesk announced Custom Headers and API Key support for its Webhooks. And fixed my previous list of shortcomings a 100%

Internal NoteThomas Verschoren

For a long time Zendesk had the Targets feature to notify external API endpoints of changes within Zendesk. Last year, they moved those Targets over to more common HTTP Webhooks supporting POST,GET,DELETE and PUT together with a Basic Auth or Bearer Auth header.

However, more and more while developing integrations I run into limits of this feature.

Two examples

Zendesk Sell

Zendesk Sell has an ancient looking contact form for capturing leads. It works but it looks terrible and is completely separate from existing contact forms on Guide or the Zendesk widget.

So, for a while I’ve playing with the idea of

1. Creating a Sales form in Zendesk Guide
2. Adding a trigger that notifies a webhook when a ticket in the Sales form is created
3. Have the trigger call the Sell API and create a lead.

This way, all contact points are integrated within the Guide Forms, and we can leverage Answer Bot to deflect recurring questions.

Zendesk Sell has an extensive API to create leads that theoretically is compatible with the Webhooks feature.

curl -v -X POST https://api.getbase.com/v2/leads \ 
-H "Accept: application/json" \ 
-H "Content-Type: application/json" \ 
-H "Authorization: Bearer $ACCESS_TOKEN" \ 
-d '{ "data": { "first_name": "Mark", "last_name": "Johnson", "organization_name": "Design Services Company", ... } }'

However, note the Content-Type: application/json line. When trying to contact Sell via a Webhook the test mode gives the following error:

"error": { 
	"code": "invalid_header", 
    "message": "invalid request header", 
    "details": "The header 'Accept' is malformed, missing, or has an invalid value."
}

So, without being able to add additional headers, this API is unusable. Luckily there’s a native Support to Sell integration on the marketplace, but it’s a prime example of Webhook limitations.

Cloudflare Zero Trust

Cloudflare is a big player when it comes to offering serverless functions and zero-trust security. This year they even released an API gateway that makes offering secure and responsive API endpoints a breeze.

However, connecting many companies leveraging Cloudflare to “expose” internal APIs to the world do so by using Cloudflare Zero Trust and Service tokens.

And, you guessed it, Service tokens require adding two header lines when making a request:

CF-Access-Client-Id: <Client ID> 
CF-Access-Client-Secret: <Client Secret>

Which, currently, is not compatible with Zendesk Webhooks.

Asana

And finally, one last one we ran into lately: Asana, where once again the requirement for two additional header items defining accepted content-types are impossible to submit, and thus impossible to use.

curl -X POST https://app.asana.com/api/1.0/tasks \ 
-H 'Content-Type: application/json' \ 
-H 'Accept: application/json' \ 
-H 'Authorization: Bearer {access-token}' \ 
-d '{"data": {"field":"value","field":"value"} }'

Workaround

Mentioning issues is one thing. Fixing them is another.

Currently my workaround is the following:

1. I create a Cloudflare Worker as a proxy for each webhook I need in Zendesk
2. My Webhooks in Zendesk POST to the Worker
3. The Worker processes the request, appends a header and forwards the request to the real API
4. The API responds to the request call
5. The Worker relays the response to Zendesk

See this Worker as a generic example.

Zendesk Feature Request

A more structural solution would be Zendesk adding support for custom headers in Webhooks.

If you like to see this too, please upvote this community post and add your feedback.