Question about attachment url fields

Hi everyone, I have some questions about attachements + download url.

We plan to save data into cache, so it must be in “invariable”.

According to the documentation here:

The only available url fields are:

In my case, they looks the same, they are temporary AWS S3 secure download link, with an expiration.

So I can’t use them for caching as they only last about 1 hour.

Also, I suppose that the asasa API must throw tons of queries to AWS S3 API to get these temp url, so it certain slow down all requests containing attachments in return.

There’s also that undocumented field, called “permanent_url”, that points to an asana url, and this one is redirected to the aws S3 temporary link, on-demand.

I suppose that I should always use that instead, to lower the charge on the api, AND to get a static url that should never change.

Is that “permanent_url” the best to use finally, even if it’s undocumented?

Thank you!

Signed S3 URLs are generated without calling the AWS servers, so I wouldn’t worry about it slowing down requests.

The main problems I’ve run into are to do with non-S3 attachments (Google Drive, One Drive) as the links require that the user log in to the relevant service to gain access to the file. This makes API access tricky, although I am hopeful that there is a solution using the official APIs rather than the download link intended for browsers.

Are you sure? how can they do that? These urls have a specific token that is only valid for about 1 hour…
They certainly keep it in cache for if I query the same document multiple times in the same period, but if it’s the first query without cache, I really think they need to call AWS for each document url I request.
For now, we decided to only keep permanent_url in cache, we’re sure they will not expire.

Yep, signed URLs just include an expiry time and a cryptographic signature. You can generate then offline:

However, that’s somewhat off topic, I think your approach of storing the permanent Asana URL is the right one.