Endpoint "Get translation download status"

I am calling an endpoint to get translation download status, where documentation says that if get 200 OK, then response format should have data/attributes/ etc.

However i got 200 with the resource file content. Is this expected? Are we getting the other data response format if document is not ready for download yet(“pending”)?

Hello Daniel,

Could you please share the resource_translations_async_download_id you’re using for this request?

Hi, this is the id = 354276cf-089d-46c6-bbbc-9849bc023981

Hello @Daniel_Dimitrov,

The 200 code indicates that the response is pending, processing, or failed.

Since I can’t see the full contents of the response you received, I can’t say for sure, but if you receive pending or processing in the response, you should retry until you receive a 303 redirect, which will contain the file location in the Location header.

If the request has failed, the response should include an error explaining why.

Your ID has expired or been completed since I received a 404 error when accessing it.

I tested with an example resource, and I have confirmed this behavior.

I hope this helps!

I tried it just now with same ID 354276cf-089d-46c6-bbbc-9849bc023981 and again received http status code 200 with the whole resource translated. As you can see from my screenshot above, i am again getting 200 and response is totally different from you mention in the documentation.

According to your documentation, in case of 200 this means that it’s still pending, processing and format should be:
{
“data”:
{
“id”: “…”,
“attributes”: { …}
}
}
but see screenshots - my response is totally different than yours.
I never hit 303 with any status, but directly receiving the response. Don’t think your documentation is accurate, or i am misssing something.

Also, same question was raised in this thread and I don’t see any comment that is resolved:

Correct me pls if I am wrong.
Thanks

Hello Daniel!

Thank you for sharing all these details — let me clarify what’s happening here.

The behavior you’re seeing is actually expected and matches how this endpoint works under the hood. When the translation file is still being prepared, the API returns a 200 OK with a JSON body that includes the status attribute (pending, processing, or failed). Once the file is ready, the API responds with a 303 See Other and a Location header that points to the actual file download URL.

However, most HTTP clients — including curl, Postman, and even the Transifex API Explorer on the developer site — follow that redirect automatically by default for testing convenience. This means that instead of seeing the raw 303 and Location in your response, your tool automatically makes a second request to the file URL and shows you the final result: a 200 OK with the translated file content. That’s why you don’t see the status JSON anymore once the file is ready.

To confirm this behavior, you can run the same curl request but disable auto-follow for redirects. For example:

curl -i --max-redirs 0 \
  --header 'accept: application/vnd.api+json' \
  --header 'authorization: Bearer <your token>' \
  'https://rest.api.transifex.com/resource_translations_async_downloads/354276cf-089d-46c6-bbbc-9849bc023981'

This will show you the raw 303 response and the Location header pointing to your file, exactly as described in the documentation.

Regarding the other thread you mentioned, the same question has been addressed there as well. It’s the same explanation: the redirect happens automatically, so you see the downloaded file directly instead of the intermediate status response.

In summary, if you see a 200 OK with the file content, it means the file is ready and you’re seeing the final download result. If it’s still being prepared, you’ll get the JSON status instead. If you want to handle the flow step-by-step, just disable automatic redirects so you can capture and manage the Location header yourself.

I hope this clears things up! Let me know if you’d like any help with an example script or implementation tips.

Thanks again for bringing this up! :rocket:

Thanks a lot for the clarification. I am using .NET http client and by giving AllowAutoRedirect=true it returned 303, which is now expected behavior.

1 Like