> For the complete documentation index, see [llms.txt](https://docs.tryterra.co/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.tryterra.co/help-center/help-topics/webhook/large-payloads-and-chunking/presigned-url-expiry.md).

# Why does a payload data URL fail with 400 expired-token?

The url in each ping or SQS s3\_payload message is a signed download link whose lifetime starts when the message is generated, not when your worker reads it.

The `url` in each Ping [webhook](https://docs.tryterra.co/unified-api/managing-user-health-data/receiving-data-updates) or SQS `s3_payload` message is a signed download link that **expires a few minutes after the message is generated**, not after your worker reads it. A `400` / expired-token error means the link was fetched too late, often because the message waited in a queue.

Each message carries:

* `expires_in`: the time in seconds you have to fetch the link. Read it from the message rather than assuming a fixed lifetime.
* `payload_reference`: the reference of the delivery, which you can log to trace a message you couldn't fetch.

What to do:

* **Fetch the data as soon as the message is consumed**, and scale your consumer so messages don't sit in the queue.
* Store the data itself, not the URL.
* If your queue regularly falls behind, use a Push webhook, which carries the payload inline with nothing to expire.

The lifetime can't be extended. To recover a payload whose link expired, resend it from payload history in the dashboard: the resend produces a new message with a fresh link.