We have several updates this month, and several feature releases we’re looking forward to showing you in our next update post. Here are some of our latest changes:
Start Dates - We’re happy to announce that start dates are now available via the API! Start dates are a great premium feature we launched late last year, and now you can set them on tasks just like due dates.
Concurrent Requests Limiter - In order to provide transparency on how we rate-limit incoming requests, we recently expanded documentation on how our rate-limiting works, along with details on rate limits for concurrent requests.
Premium-Only Error Changes - We made changes to how we handle premium-only errors from our API. We wrote about this extensively in another blog post, including our apologies for shipping this without communicating the change properly, as well as our migration strategy (and our recommended migration path for developers).
@johnnygoodnow In regards to Start Dates, does the CSV export show the field of Start Date on every export whether a Premium or Free User. I donated a CSV to PDF converter to the Community and when Start Dates were added to the CSV export, it broke so I am fixing it. Just need to know if all CSV exports have a column for Start Dates. I know this is not the subject of API but it would be helpful to know.
It’s f-a-n-t-a-s-t-i-c to see proactive communication from the Developer Relations team. Or maybe you’re in the Platform Engineering team, not sure. Thank you for doing this. We’ve already gotten a couple of ticklers in our mind about what we want to do when we make an API request that forbidden.
About Rate Limits, is that per API developer (i.e. the developer of the Asana add-on), or is that per user account (the user that the API call is specifically being called from), or Organization (of the user on whose behalf the API request is made)? This is really important to understand, would you please clarify?
@johnnygoodnow In regards to Start Dates, it my understanding this is only available to premium users. With our add-in www.sendana.net if I were to add start dates does the API identify who is a premium user or free. I have to think about having a field that free users don’t have access to.
Hey @James_Carl , there’s not an association on whether a user is premium or not - premium is determined by the workspace/organization.
For example, you could have a workspace associated with your user that’s a free workspace (and not have access to features such as start dates), but you could also have a work organization you’re a member of that is a premium workspace that would allow for these features - both in the API and the web app.
Get the list of workspaces associated with a user that you want available in your application via the User endpoint and the Workspaces endpoints.
Try to perform a premium action in the applicable domain, and check the response code. If you get a 402 (which will be definitively 402 after next Tuesday - see Premium-Only API Error Changes for more context), then they can’t perform the action in that workspace/organization.
There are several ways to handle this: always show the feature and let the user know when it’s not available for a given domain, perform test actions when initializing a user and cache whether a workspace/org is premium for a certain amount of time, etc., and it’s really up to you for what’s the best way to go about it. In fact, several other developers (such as Instagantt) have already had to handle similar cases for Custom Fields.
As for your first question, it appears that Start Date is always a column in both Free and Premium. I wouldn’t expect that to change, but I’ll follow up with our team internally as we should ideally be more consistent about it with the API.
Thank you! We’re hoping with more of us on the team that we’ll be able to continue more proactive communication as we go forward; please feel free to always let us know if you ever have any feedback.
As for Rate Limits (great question by the way), @Diakoptis is correct - it’s per authenticated user for a given app. For a concrete example:
You create an OAuth application called “TurboTask9000”, and you have two users authenticate with OAuth with it - User A and User B.
User A uses the application with only a free domain (currently 150 requests/min)
User B uses the application in only a premium domain (currently 1500 requests/min)
If User A repeatedly goes over their API limits, but B does not (let’s say both users average 300 requests/min), we can choose to temporarily suspend User A’s API access via TurboTask9000. Once this happens, here’s the current state of the world:
User A can no longer make requests via TurboTask9000. However, if User A also has a small separate script running that uses a personal access token, that script will go uninterrupted (provided they are respecting rate limits). The same goes for other applications they’ve authorized.
User B would see no interruption via TurboTask9000.
When these suspensions happen, we usually contact the application developer to let them know of the user-app pair that’s been suspended to give them context about the situation, especially because the rest of the app’s users may report no problems (except that user in question of course). Our Developer Relations team also tries to help developers with mitigation strategies towards limiting API usage and respecting our rate limits, and I encourage you to seek out additional ideas in the community.
In the future we may continue to define our limits as well as other forms of automated management to maintain reliability and uptime for our servers, and we’ll continue to keep everyone posted about those changes here, our developer blog, and our developer newsetter (which you can sign up for on the blog).
Yes, all of our limits are per authentication token (i.e., per user per app). We have set the concurrent request limits based on what will protect the API’s stability and how many tokens would actually be affected by the limit. What is your use case that the current concurrent request limits are insufficient? From our data, the limits would have only affected on the order of 10 tokens.
Thank you for the answer. Our case is that, we get events payload via webhooks, and then make API calls to get detailed information for each event in the payload. Some of our users can create too many events in a short amount of time which results in payloads with around 40 - 50 events in it. If the user creates webhooks for more than one project and we get payloads for all of them around the same time, it easily reaches up to the limit. The number of users we are having this problem with is small at the moment, but it may increase in the future. Therefore, we wanted to know if it is possible to increase this limit.
I have a similar situation. You can filter the events by task actions. Group the actions and make only one request to get the task. Do not request stories one by one. Get them all on requesting the task object.
