Hey there @Kevin_Lieser,
You are right, the secret we provide is 32 hex characters long, and webhook signatures (which we pass as with the X-Hook-Signature header) is 64 characters long. (We have a note to fix this in our next pass through our documentation, sorry for any confusion 
)
As far as the activation handshake problem, this is most commonly encountered when attempting to set up the webhook from within the same thread as will respond to incoming webhook deliveries.
The ordering of the webhook handshake goes like this:
client server (Asana)
|-- POST /api/1.0/webhooks --->|
|
|<--- POST {yourcallback} ---- |
| |
|--- 200 OK [with secret] ---> |
|
<--------- 200 OK -------------|
That is, the callback happens inside of the original request before the original request returns.
This is great for getting assurance that the webhook is established, because the return from the first request will be either success or failure depending on what happened with the handshake. However, this also means that your server needs to be able to respond to the incoming handshake request before the first request returns.
This has implications for single-threaded servers that block on the return of the first request - namely, they are blocked! They can’t respond to the second request until that first request returns. That means the handshake really does encounter a server that isn’t responding.
The solution is to kick off the first request in a thread, which frees up the second thread to occur, or to run multiple servers in parallel somehow (like Apache’s mpm_worker_module ) so that a server in process 2 can handle the handshake while process 1 is blocked.
Hopefully this makes sense!
We don’t have a specific way to get a particular user’s inbox, but you can query for incomplete tasks for a particular user. I’d approach getting task counts like this:
If you’re using an authorization for a particular user (say, a personal access token) you can get all their workspaces by making a request to the /users/me endpoint:
curl --header "Authorization: Bearer $ASANA_PERSONAL_ACCESS_TOKEN" "https://app.asana.com/api/1.0/users/me"
This will return, amongst other things, the list of workspaces for that user.
A note of warning: this may not always be quite so simple; at some point in the future, each authorization may be scoped to a single workspace. This means that integrations will have to authorize and get credentials for each user-workspace pair. This is still under development, so the exact implementation is still in progress, but it’s good to know for the future.
(We’re considering the implications of having some API endpoints, like the /users/me one, have the ability to see cross-workspace data like this, so this may never end up changing for you. Just calling it out.
For each workspace, get the list of incomplete tasks for that user in that workspace:
curl --header “Authorization: Bearer $ASANA_PERSONAL_ACCESS_TOKEN” “https://app.asana.com/api/1.0/tasks?assignee=[user_id]&completed_since=now&wo
rkspace=[workspace_id]&limit=100”
The tricky or unintuitive part of this is the “completed_since=now”, which will return incomplete tasks. It’s sort of like “tasks that will be completed at a date later than now”, but is definitely something that looks odd at first glance.
Then you just count those tasks, and you’re good to go! Hopefully this helps - and saves you from having to pull all the data from Asana for several entire workspaces every time you want to count a user’s open tasks 
