0

So I have implemented the Asana Webhooks API as described in their documents. I can pass it a project ID and request a new webhook be created. The API successfully sends a authentication request to my application which returns the Security header as described in the Docs. Asana then returns the expected success response, outlining the newly created Webhooks unique ID.

Now if i take this ID and then query the Asana API to show me all configured webhook's on either the parent Workspace or the project resource directly it returns an empty data JSON Object or reports the resource doesn't exist, suggesting the Webhook Ive just created wasn't actually created, despite giving me the expected success response.

Also If I then make a change to a project it doesn't fire the webhook and I don't receive any events on my application.

Strangely everything was working on Friday but today (Monday) I'm experiencing these issues.

Any pointers would be good, Ive been working as the Docs suggest in terms of my request structure and am authenticating using a PAT, Ive even tried a newly created token.

Thanks,

Olly Warren
  • 5
  • 2

1 Answers1

0

Our webhooks use the handshake mechanism to make sure that it's possible to call you back, but there's always the possibility that subsequent requests can fail. Additionally (although we don't document this very well - there's an opportunity for us) we should immediately try to deliver a (probably) empty event after the handshake (it looks like {"events":[]}. This is kind of like a "second callback" that contains anything that has changed since you created the webhook.

If this fails - or if any subsequent request fails often enough - the webhook will get trashed. "Failure" in this context means returns HTTP response codes other that 200 or 204.

As for why you're having trouble querying the webhook itself, I wasn't able to repro the issue, so we'd have to dive deeper. It should be fine if you:

  • Specify the workspace
  • Optionally specify the resource

I tested this out, and it seemed fine. You also might want to directly query the webhook by id with the /webhooks/:id endpoint - note to use the id of the webhook returned by create, and not the id in the resource field.

If you created the webhook (specifically, your PAT or OAuth app was the one making the create request) you should see the information just fine. If you can get the webhook by id, you should see last_failure_at and last_failure_content fields which would tell you why the webhook was unable to make the delivery.

Finally, if you would like to contact us at api-support@asana.com and let them know more details (for instance, the ID of the webhook you're trying to look at) we can look at those fields from our side to see if we can identify what's going on.

Matt
  • 10,434
  • 1
  • 36
  • 45
  • "This is kind of like a "second callback" that contains anything that has changed since you created the webhook. If this fails - or if any subsequent request fails often enough - the webhook will get trashed. "Failure" in this context means returns HTTP response codes other that 200 or 204. " - Does this include the Security Header?? If not this might be my issue as my API only responds is the security header is present, I assumed it was sent on all requests. – Olly Warren May 11 '17 at 12:44
  • If by "security header" you are referring to the handshake header "X-Hook-Secret", that is only sent during the handshake process - that is, it's never sent after a successful handshake has established the webhook. The header 'X-Hook-Signature' is sent for all requests *after* the handshake request, including this first "nothing has probably changed yet" first callback. So the handshake has "X-Hook-Secret", all others have "X-Hook-Signature" – Matt May 19 '17 at 18:47
  • Thanks Matt, I figured out my issue was with the first callback, because I was expecting the X-Hook-Secret in every request and refusing the requests without it. So now the webhooks stay established. – Olly Warren May 23 '17 at 16:24