How long is a file available in TON for?


When dealing with the audience API, we upload a file with the hashed emails in TON then we request for the audience change to be made using the link we got from the TON API after the upload. The TON link is shared across a few audiences so after the TON upload there will be a few calls for the audience change using the same TON link. However, sometime, if the audience change call occurs a bit later, we see a connection reset and the audience change request fails because of this.
I’m thinking this is because after a small period the file is deleted from TON hence this behaviour?
Is my thinking correct? and if so, how long is a file available in TON for after uploading it?
If that is not the case, what can cause the connection reset during an audience change REST request?


Hi @liviutudor! Maybe you’re trying to change the audience many times simultaneously? And so one of the calls gives “connection reset”?

If not, please post the call to change the audience that gives the error, and the raw HTTP response, so we can make sure nothing is wrong with the request.


Is that the case then that when multiple changes are applied to the audience at the same time the REST service does a connection reset?
I remember if a certain rate limit for HTTP requests was hit the service would indicate that in the HTTP response – has that been changed in favor of a connection reset?
I am not changing the same audience multiple times, however, we are applying changes to multiple audiences with the same TON file handle – does this cause a connection reset?


BTW inspecting the code we set the X-TON-Expires header to 5 days which I think rules out my initial hypothesis…


What do you mean by “TON file handle”? A TON file is given by that “location” returned by Twitter, so by “the same TON file handle” I understand “the same file”.

Rate limited requests return an error that states that the request is rate limited - this has not changed, and it has nothing to do with “connection reset”. By “connection reset” I understand that the server closed the connection because it didn’t like something, like too many simultaneous requests - for me, this seems like a good and probable reason to return “connection reset”.

Then, I assume you are not making the change requests later than 5 days, right?


Right, sorry, wrong terminology – I mean TON file location – the location returned by the TON service after uploading a file. So to clarify yes we upload a single file to TON and use the returned TON file location to apply as a change to multiple audiences – so your understanding of using the same file is correct.

We are not seeing any HTTP responses indicating the request rate has been hit – so that is not responsible then for what we are seeing. Instead, when applying the audience file change (after file uploaded into TON) we experience a HTTP connection reset. The (Java) HTTP libraries we use throw an IOException stating connection was reset.

Lastly all of this (file upload and applying changes to audiences) happen in an interval of say 5-6 hours – so less than 5 days indeed.


@liviutudor the maximum duration you can set the expiration for TON locations is 10 days.

Python SDK:

Ruby SDK:


OK so then using a max expiration of 5 days shouldn’t cause this, then what? Is it just the case that the TON file is used in too many (distinct) audience updates?


It sounds like a networking error between your server and Twitter’s. It’s unlikely that this is actually an issue in your implementation or the API.

In your code, what’s the timeout (might be a default) set to for your request to Twitter’s APIs?
When you see this connection reset failure, does the the request time exceed that timeout?

It may just be a matter of configuring your HTTP request object correct so that it will tolerate longer running requests.


OK that is very plausible as I can’t find any patterns here – I will put in a wait/retry mechanism around these errors, I wanted to make sure first there aren’t restrictions when re-using the same TON file location across multiple audience change requests.
Thanks for clarifying this!