Hello, Mr. Einstein, big fan of your work!
I tested out what you’re seeing, and unfortunately couldn’t get it to reproduce I tried running curl and setting the header to route to the new API:
curl --header "Authorization: Bearer $ASANA_PERSONAL_ACCESS_TOKEN" \ --header "Asana-Fast-Api: true" \ "https://app.asana.com/api/1.0/workspaces"
and got
{
“data” : [ {
“id” : 15793206719,
“name” : “Asana, Inc”
}, … ]
}
So I think it’s not simply the fact that it’s the new API, but perhaps something else or some combination of things. What are you using to make the actual call - are you using, say, one of our client libraries, or making calls in a browser? (There is a known thing we’re evaluating for in-browser integrations which might be related here).
Regardless, I can let you know what’s going on with the intermittent-ness. We’re trying to do a slow, controlled migration of our API, and as a part of doing that, we’re partitioning out our requests to some percentage going to each version of the API. This partition is happening based on the user’s credentials; so if you’re using a personal access token, you may see something different than someone else using a different access token, and if it’s an oauth app, every time you get a new refresh token (I think every hour or so) you might be partitioned into a different bucket. Finally, any time we notice that something in our process internally is not solid with regards to managing our new API infrastructure, we might go back to 100% usage of the old API, so everything’s a moving target
What you can do is force using our old API by setting that header we mentioned to false, that is, the header should be Asana-Fast-Api: false
. This lets you choose which API you hit: true is the new one, false is the old one, and unset is whichever bucket you happen to land in.
Hopefully this helps! If you can let me know any other information we can use to try to reproduce what you’re seeing, I’d appreciate it!