Why is adding a new team missing from the API?

Why is adding a new team not a part of the API?

I’ve seen this question asked in 2018, but no one from Asana addressed the status or reasoning behind this omission.

1 Like

@Ross_Grambo any idea why adding a team isn’t available in the API?

Were you able to find the existing thread? Might be better than creating a new one.

Hey Bastien,

Here is the original thread on the subject Create teams with the API

I started a new thread because it was only mentioned that it was unavailable. And despite several people chiming in about how it’s a feature they’d like to have, no one commented afterwards about the development status, or why it was omitted.

Also, I’m seeing that you actually CAN create a team via an HTTP post request. So the backend is there, the developers creating the client libraries just didn’t create methods for this. Why?

Any Python users who need to make a team…

import requests

data = {

"name": 'Test - New Team'


r = requests.post(‘https://app.asana.com/api/1.0/organizations/{}/teams’.format(workspace_gid), data=data, auth=(PERSONAL_ACCESS_TOKEN, ‘’))


1 Like

Hey @Clay_Porter yes, this works! We don’t officially recommend anything that’s not documented, however, so developers are taking on some level of risk when using this. The way we think about it is “We haven’t done the review of whether this is ship-worthy, so if, for instance, it has a performance issue, we reserve the right to shut down this endpoint without notice”. If it’s worth the risk to you to include it in your script, then go for it.

A bit more about our undocumented endpoints:

Asana created our API with 2 goals in mind:

  • Open up a platform for external developers
  • Enable an external interface for our native mobile apps to use

Many of our undocumented endpoints are used by our mobile app. Not to give you the impression that there’s a whole secret “dark API” out there - there are only a very few of these endpoints. In addition they often have a purpose more mundane than clandestine; for instance, turning on the radio in a mobile context is relatively expensive power-wise, so some endpoints exist to prefetch more data in a single call than we expose in our public API, minimizing radio usage.

I suspect that this endpoint is undocumented for more of a use case thing: it was probably built knowing what business logic was needed in our mobile app, which is slightly different than for general developers. Is it also able to solve the right goals for a public API context? Is it secure? Is it stable when a whole fleet of servers hits it at once? This is why we’d want to do a review of it before publicizing it, to make sure that we can give some assurance of it working for developers.

However, thanks for bringing this up, because signal that people want this is a major data point for prioritizing this review from our API team. I’ll forward on that people are eager for this so they can decide where to prioritize the review!


Hi @Matt_Bramlage, thanks for the thorough explanation and context around this and other undocumented endpoints. I will keep in mind the risk when considering their use.