Reviving a script to update CORS origins in PR-environments, encountering issues with token grants

Hey :)
We are using PR-environments and need to update CORS origins manually for each environment.
Some time ago, we had a script that allowed us to update CORS origins, authenticated using a token generated in the API section of the management interface. At some point this script stopped working, and I am now trying to revive it.
However, no matter which token I create (deploy studio token, reader, writer), I always get this error back when calling `GET /v1/projects/projectId/cors`:



Is it possible to create a token that has this grant, and if so, how can we do it?

I think the issue may be that you're using V1 of the API. Can you try following this format?

Hey, RD! Thanks for the replyI've tried the new format as well, but I still get the same error message

I've posted a basic snippet of the call I'm trying to make
🙂

Thanks for confirming! I gave it a shot and I'm getting the same behavior. I'm asking internally for more clarity!

Great! (or not so great, but you know what I mean 😁) Will you let me know what they say?

Will do!

I just had a chat with our previous Tech Lead and apparently he reported this same issue around a year ago

OK got clarity here. The CORS endpoint requires a developer or admin token. The developer role is not available on the free plan, so you'll need to use an admin token if that's what you're on. You were likely using an admin token in the past, then logged out somewhere which invalidated the token, or on an older plan that has access to a developer role. You can get access to your admin role's token by running .

So we have to expose an actual admin user's token somewhere to be able to automate this? Seems very strange that this couldn't be an API token with a specific grant. We're not on "Free", but on an "Advanced" plan, where we can only have "Administrator", "Editor" and "Viewer" roles. It did work with my personal token (administrator role), like you said it would, but I don't know how comfortable I would be putting our personal auth tokens "out there", even if it's in a key vault. If that's the case I'm more inclined to doing this manually every time we open a PR.

Thank you for your help on this issue, RD 🙂 Hope you guys will think about adding this as an API token feature instead of personal tokens. Seems like an endpoint that would be used often with CICD.

If you upgrade your plan you'll have access to the developer role (which won't require you to expose a user's token).