Color codes in API

[anon33457153]

Since this is the top search result when looking for Asana Hex color codes, and there is no Asana created document that I could find . I thought I would add to it. These are the color codes (both RGB and HEX) I pulled out of the CSS today for the custom fields. A side note, a few of these don’t actually map out correctly if you use a color picker on the site, I’m not sure what is up with that.

–color-customization-aqua-background
Aqua | Hex #9ee7e3
–color-customization-aqua-background-rgb
Aqua | rgb 158, 231, 227
–color-customization-background
No Color - White (Gray in color picker) | Hex #c7c4c4
–color-customization-blue-background
Blue | Hex #4573d2
–color-customization-blue-background-rgb
Blue | rgb 69, 115, 210
–color-customization-blue-green-background
Blue-Green | Hex #4ecbc4
–color-customization-blue-green-background-rgb
Blue-Green| rgb 78, 203, 196
–color-customization-cool-gray-background
Cool-Gray | Hex #6d6e6f
–color-customization-cool-gray-background-rgb
Cool-Gray | rgb 109, 110, 111
–color-customization-green-background
Green | Hex #5da283
–color-customization-green-background-rgb
Green | rgb 93, 162, 131
–color-customization-hot-pink-background
Hot-Pink | Hex #f26fb2
–color-customization-hot-pink-background-rgb
Hot-Pink | rgb 242, 111, 178
–color-customization-indigo-background
Indigo | Hex #8d84e8
–color-customization-indigo-background-rgb
Indigo | rgb 141, 132, 232
–color-customization-magenta-background
Magenta | Hex #f9aaef
–color-customization-magenta-background-rgb
Magenta | rgb 249, 170, 239
–color-customization-orange-background
Orange | Hex #ec8d71
–color-customization-orange-background-rgb
Orange | rgb 236, 141, 113
–color-customization-pink-background
Pink | Hex #fc979a
–color-customization-pink-background-rgb
Pink | rgb 252, 151, 154
–color-customization-purple-background
Purple | Hex #b36bd4
–color-customization-purple-background-rgb
Purple | rgb 179, 107, 212
–color-customization-red-background
Red | Hex #f06a6a
–color-customization-red-background-rgb
Red | rgb 240, 106, 106
–color-customization-yellow-background
Yellow | Hex #f8df72
–color-customization-yellow-background-rgb
Yellow | rgb 248, 223, 114
–color-customization-yellow-green-background
Yellow-Green | Hex #aecf55
–color-customization-yellow-green-background-rgb
Yellow-Green | rgb 174, 207, 85
–color-customization-yellow-orange-background
Yellow-Orange | Hex #f1bd6c
–color-customization-yellow-orange-background-rgb
Yellow-Orange | rgb 241, 189, 108

[Shawn_Taylor]

My goodness, how great would it be to just ask for ‘custom_fields.enum_value.color.hex’ and avoid all this

[Shawn_Taylor]

If anyone wants it!

.aqua{color:#9ee7e3;}

.white{color:#c7c4c4;}

.blue{color:#4573d2;}

.blue-green{color:#4ecbc4;}

.cool-gray{color:#6d6e6f;}

.green{color:#5da283;}

.hot-pink{color:#f26fb2;}

.indigo{color:#8d84e8;}

.magenta{color:#f9aaef;}

.orange{color:#ec8d71;}

.pink{color:#fc979a;}

.purple{color:#b36bd4;}

.red{color:#f06a6a;}

.yellow{color:#f8df72;}

.yellow-green{color:#aecf55;}

.yellow-orange{color:#f1bd6c;}

[Phil_Seeman]

Thanks, @Shawn_Taylor - always good to have updated color lists as they do change from time to time.

[Shawn_Taylor]

you bet! For the record, all I did was take @anon33457153 's list and make it css.

[Ryan_Nowakowski]

Please update this list in the spec? Missing enum values breaks some OpenAPI generated SDKs.

[Ludwig_V]

Looks like with the update to the Colouring in Asana recently, these have all changed and now if you try to update them using the API it will give you an error unless you switch to the new naming conventions

Fun thing, the names of the colours don’t visually correspond in some cases, for example what I’d consider “dark-blue” is called ‘light-blue’ and what I would consider ‘light-teal’ is ‘dark-teal’.

My personal favourite is that what I would consider light gray is actually none, and the dark gray is light-warm-gray.

List of colours as you see them displayed as options on projects in Asana, left to right, top to bottom:

’none’
’dark-red’
’dark-orange’
’light-orange’
’light-yellow’
’light-green’
’dark-green’
’light-teal’
’dark-teal’
’light-blue’
’dark-purple’
’light-purple’
’light-pink’
’dark-pink’
’light-red’
’light-warm-gray’

[Phil_Seeman]

@Ludwig_V

now if you try to update them using the API it will give you an error unless you switch to the new naming conventions

Yeah, I just ran into this today. Kind of an annoying breaking change…

[Ludwig_V]

I agree wholeheartedly!

I was also through off by the naming conventions, as noted they don’t visually correspond the way you would expected and I spent 2 hours trying to figure out why my colour updates weren’t working because the error return stating you’re using an invalid colour, lists many colours that aren’t valid such as dark-blue.

Ended up manually setting a few projects to each colour and submitting GET requests to verify each one individually.

[Ludwig_V]

@Phil_Seeman
I’m running into a very interesting issue now, curious if you’re running into the same issue now as well!

Summary
Some of my users are seeing projects in different colours that others.

I updated my automations to use the new colour coding system for projects, however, some users started reporting that the colours didn’t look right to them since the changes.

Upon further investigation within a Portfolio, I was able to verify that some users see the updated colours for projects. While others are viewing completely different colours within the same Portfolio.

Testing things further, I generated an API token for one of the affected users and used it to test a GET request for a specific Project GID.
Not only are some users able to view the colours completely differently, their API returns are different and use the old colour naming system!

• I’m going to refer to users who see the New Color Format as N Users.
• I’m going to refer to users who see the Old Color Format as O Users.

What is really throwing things off is that if an N User changes the colour, it doesn’t change the colour for an O user. Likewise, if an O user changes the colour, the N User would not see the colour change within Asana or the API.

Example
Colour Selection from UI for reference

• When I use my usual API token, Token A, to get the color value for Project 123. I currently receive “dark-brown” as a return instead of the “dark-yellow” of last week.
• When I use my alternative API token, Token B, to get the color value for Project 123. I currently receive “yellow” as a return.

I’m beyond confused what is going on, but to elaborate further using the color references from above, it appears that some users still see the “old” color values. I changed the color manually using my O User profile and token to see what the color value returns are.

I can also confirm it doesn’t matter if the user is viewing from the web-app or the desktop-app, they are either an N User or an O User it seems.

New Color Format = Old Color Format

’none’ = ‘none’
’dark-red’ = ‘red’
’dark-orange’ = ‘orange’
’light-orange’ = ‘yellow-orange’
’light-yellow’ = ‘yellow’
’light-green’ = ‘yellow-green’
’dark-green’ = ‘green’
’light-teal’ = ‘blue-green’
’dark-teal’ = ‘aqua’
’light-blue’ = ‘blue’
’dark-purple’ = ‘indigo’
’light-purple’ = ‘purple’
’light-pink’ = ‘magenta’
’dark-pink’ = ‘hot-pink’
’light-red’ = ‘pink’
’light-warm-gray’ = ‘cool-gray’

[Phil_Seeman]

Asana usually rolls out app changes gradually over time. My understanding is the color change had been rolled out to everyone, but it sounds like it likely has not yet.

Also it’s not likely but check and make sure neither user has the Settings > Display > Enable color blind friendly mode option enabled.

[Mikhail_Melikhov]

Hi @Ludwig_V thank you for raising this!

Project icon color is a per-user customization in Asana, meaning each user can set and view colors in a way that works best for them. Because of this, when testing with API tokens tied to different users, getting different color value responses is expected.

I understand how this can feel counter-intuitive, especially since the UI now includes a “Set for everyone” option that overrides individual settings. We’re aware this creates some confusion, and there’s active work underway to make color management more consistent between the UI and API, and to better align with user expectations.

Your feedback is valuable for us in shaping that experience, I’ll make sure it’s communicated.

[Ludwig_V]

Hi @Mikhail_Melikhov , thank you for your explanation!
That makes a lot more sense.

My team uses an automation that updates the color of the project based on a custom field changing. We use iDO’s POST external-action in the rules builder to trigger the script.

Example: Active = Light-Blue, Inactive = light-warm-gray

With the addition of the “Set for everyone” option on project colours, how do I interact with this from the API? I’d like to make it so that my automations correctly set the colour for all users, so we can use color for continued communication.

When using a GET on a specific project gid, I’m not seeing any field to toggle whether the colour field is for everyone or a single user?
I’d assume if from the UI, I can set it for everyone, that I’d be able to do the same from the API.

[Mikhail_Melikhov]

Hi @Ludwig_V , thank you for clarifying the intended usage.

Icon coloring was introduced to allow each user to maintain own color-coding that suits their mind. However, based on customer feedback and the expectation of consistency across workspaces, I’ve confirmed that upcoming updates will accommodate this. This means that the API color updates you’re currently making will behave as you expect.

That said, if you’re using colors to represent project states or properties, it may be worth considering a more semantic approach. For example, for binary states (active vs. inactive), the “archived” project property is a good fit.

For more granular states, a portfolio level custom field of a “select“ type, either single or multiple, would provide clearer and more scalable tracking.

I hope this helps in aligning your setup with both the current and upcoming functionality.

[John_Vu]

Hi everyone,

It looks like our product team changed some colors in the product. Here’s the mapping of API colors to Web colors.

Current API Colors              | Current Web Colors
--------------------------------|-----------------------
None                            | None
Dark Red                        | Red
Dark Orange                     | Orange
Light Orange                    | Yellow-Orange
Dark Brown, Light Yellow        | Yellow
Light Green                     | Yellow-Green
Dark Green                      | Green
Light Teal                      | Blue-Green
Dark Teal                       | Aqua
Dark Blue, Light Blue           | Blue
Dark Purple                     | Indigo
Light Purple                    | Purple
Light Pink                      | Magenta
Dark Pink                       | Hot Pink
Light Red                       | Pink
Dark Warm Gray, Light Warm Gray | Cool Gray

[Richard_Sather]

@Mikhail_Melikhov

However, based on customer feedback and the expectation of consistency across workspaces, I’ve confirmed that upcoming updates will accommodate this. This means that the API color updates you’re currently making will behave as you expect.

Hi @Mikhail_Melikhov , we are very much looking forward to the API being able to set the colour of a project to ‘Set for everyone’. My team have written an amazing custom script in a rule that works beautifully and all we are missing is colour the project (for all users) based on the colour of the department (which in our case is drawn from a single-select field’s option, from the task that the script converts into a project)

The customer and my team are really hoping that the default option can be set to ‘Set for everyone’. I cannot imagine this will break anyone’s workflow and I would expect this is what the majority of users are looking for.

Could you please give us a rough date when we can expect this change?

[Mikhail_Melikhov]

Hi @Richard_Sather , thank you for sharing your use case, that’s a great example of how teams are extending Asana with custom scripts.

To clarify: the plan isn’t to make “Set for everyone” a default option alongside existing, but rather to make it the only option going forward. The existing “Set for everyone“ checkbox will be deprecated and its behavior will be implied by default, both in the UI and via the API.

It’s hard to share specific dates, since introducing this change requires resolution of multiple dependencies, but I can confirm that this is in progress and should be available shortly once those dependencies are resolved.

[Richard_Sather]

That is awesome, @Mikhail_Melikhov ! Thank you for the prompt response and totally agree to deprecate the option.

[John34]

Thank you for this! We’ve recently starting facing issues with the API to retrieve and create colors as part of our migration tool. This is a life saver!

[Alex_Laughnan_Asana]

Hello @Ludwig_V and @Richard_Sather ! I’m Alex, the Tech Lead on Design System here at Asana and I wanted to cross-post an update that I published on Friday of last week: Asana Tags API colors new changes causing issues. - #4 by Alex_Laughnan_Asana

The API should now honor the color and icon property for the project or tag when you make a PUT request. As @Mikhail_Melikhov stated above, we’re not longer supporting “Set for everyone” in the UI and we’ve cleaned up the discrepancy in the API logic. Thanks for your patience!