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.

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 mentioned in Premium Versus Free Field, we hope to make this available via the API at some point, and we apologize for the difficulty here.

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).