Overview
Fetch turns URLs into LLM-ready content. You send up to 20 URLs in one call, and you get back one result per URL. Two things make up the model:- A request is a list of URLs plus what to do with them: which representations to return, which tier to bill, and how long one URL may take.
- A result is the outcome for one URL — the content if the page could be fetched, an error code if it could not, and what was observed on the way (where redirects landed, what the origin’s status code was).
A failed page is not a failed call
The call succeeds or fails on the request, not on the pages. A malformed body, an unusable parameter, a missing API key or an exhausted balance is a rejection: nothing is fetched and nothing is billed. Once the request is accepted, every URL gets a result. A page that could not be fetched arrives inside the same200 with status = "error" and an
error.code. That way an origin’s own 404 stays distinguishable from the
endpoint not existing. See Handle errors.
Results and correlation
Results come back in the order the URLs were requested, butrequested_url is the key — it is echoed back byte for byte, never
normalized and never replaced by the post-redirect URL. Join on it rather than
on position. That is also why two identical URLs in one request are rejected: a
repeated key is ambiguous.
Where redirects actually landed is final_url.
Formats
formats selects which representations to return, by name. Leaving it out
returns Markdown. Each requested format arrives in its own field on the result,
so a format the page could not produce is simply unset — branch on status,
not on whether a content field is present.
Next steps
To learn more about Seltz Fetch, check out the following topics:- Quickstart — Fetching your first page
- Handle errors — Telling a rejected request from a failed page
- Reference — Endpoint, SDK methods, limits and errors