Skip to main content
Runs that produce files — video, images, generated speech — come back with an output_downloads array alongside output. Each entry is a link on Goro’s own domain that downloads the file when opened. No API key. The token is the authorization, which is what makes these links something you can hand to a person, put in an email, or open on a phone that has never signed in to Goro.

​
What a run returns

output_downloads is absent entirely when a run produced no files, which is most of them. An endpoint that returns scraped rows has exactly the result shape it always had. The provider’s own URL stays in output, untouched. Use it when you want to stream the file into a video player or fetch it yourself; use the download link when a person is going to click it.

​
Why not just use the provider’s URL

Three things the raw link cannot do. It is not our address. It is a hostname nobody recognises, on a CDN we do not control. If Goro changes providers, every link already handed out is a dead end. A files.usegoro.ai link keeps working across that. It does not reliably download. Whether clicking a URL saves a file or opens a player is decided by the Content-Disposition header, which is set by the server holding the file. On a link this route serves, that header is ours. It expires on somebody else’s schedule and says nothing when it does. A Goro link expires on our clock and, when the file really is gone, answers with a sentence explaining which retention ran out.

​
Nothing is re-hosted

The file stays exactly where the provider put it. Goro does not copy generated media into its own storage, and this route did not change that: it resolves the token to a run you own, reads the URL that run already recorded, and either redirects you to it or streams it through with a download header attached. That is a deliberate limit rather than an optimisation. Re-hosting output would mean a new bucket, a new retention clock and a standing store of customer files that the Privacy Policy would have to start describing. It does not exist, so there is nothing to describe.

​
Playing instead of saving

Add ?inline=1 to get a redirect to the file where it actually lives, with no download header and Goro out of the path:
Use it to embed a video, to stream rather than save, or for a very large file on a slow connection where a proxied download might not finish. Seven days from when the run returned it, and shorter in practice, because the file itself has to still exist: The practical rule: collect what you need soon after the run. A link that outlives its file answers 410 with an explanation rather than a broken download.

​
Errors

These are HTML pages, not JSON envelopes, because a person clicked the link.

​
Security

A download link is a capability: whoever holds it can fetch that one file until it expires. Treat it the way you would treat any signed URL.
  • The token names a run id and an index, never a URL, so it cannot be edited to point Goro at an address it did not produce.
  • It is signed, so a token built by hand does not verify.
  • It resolves only inside the workspace that owns the run.
  • It is scoped to a single output item, not to the run.
  • Responses are sent private, no-store, so nothing in between keeps a copy.

Send a file the other way

Uploads, handles, and the page a user opens to hand your agent a file.