Use cases
Public financial documents, and a record of how you got them
Financial data collection covers two very different things. One is licensed market data from a vendor with a contract. The other is reading documents that are already public, on a schedule, from a machine. We are useful for the second and have nothing to do with the first.
What we do not offer
We are not a market data vendor and not a licensed financial adviser. Nothing fetched here is investment advice, and we cannot tell you whether a particular target's terms of use permit your collection — that is a question for the target's terms and your own counsel. We also do not resolve CAPTCHAs or entitlement walls, so a paywalled vendor terminal stays out of reach.
The targets this suits
Public disclosure is mostly published as plain documents on ordinary web servers, and those servers are generally not hostile to automated readers as long as you are not greedy.
Regulator publication pages
Filing indexes and disclosure listings, most of which expose a stable URL scheme and often a JSON or CSV variant.
Issuer investor-relations pages
Results announcements, press releases and the dated index page that lists them, which is the cheapest thing to poll.
Statistical and central-bank series
Public series downloads and documented open APIs. These are designed to be read by programs and usually say so.
Exchange notices
Suspension, listing and corporate-action notices published as web pages rather than distributed on a feed.
Text in, text out — which rules out PDFs
The egress node decodes the response body to text, replacing bytes it cannot decode. For HTML, XML, JSON and CSV that is exactly what you want. For a PDF filing it is not: what arrives is a mangled string, not a document you can process.
Where a regulator offers an HTML or structured variant of the same filing, fetch that. Where only the PDF exists, fetch it with something else and use us for the index pages that tell you a new filing appeared.
The part of the trail we do keep
Every served request writes a usage record you can query back over the API, and invoices are issued at period close against those records. If you need to show that a collection job ran when you say it ran, that is the artefact that exists on our side.
What does not exist on our side is the content. Nodes do not log target URLs or response bodies, so the document archive and the timestamps you attach to it are yours to keep. For anything with an audit requirement, store the response body together with the URL and the timestamp at the moment you receive them.
Where this is the wrong tool
There is no market data here. No quotes, no ticks, no order books, no reference data, no security identifiers, no adjustment for splits or corporate actions, and no point-in-time reconstruction of what a number looked like on a past date. Those are vendor products with licensing attached, and a fetch API is not a substitute for one.
Nor do we interpret anything. No extraction of figures from narrative text, no sentiment scoring, no language models. You get the document.
Questions
- Do you provide real-time market prices?
- No. We fetch URLs. A price you can read on a public page you can fetch, at whatever staleness that page has, but there is no feed, no streaming and no licensed data behind it.
- Can I fetch a PDF filing?
- Not usefully. Bodies are decoded as text, so binary formats come back corrupted. Use us for the HTML or JSON index that announces the filing, and fetch the PDF itself directly.
- Will a datacenter address get blocked by regulator sites?
- Usually not — public disclosure sites are built to be read. If a target does challenge cloud addresses, you will see its status in the response rather than a silent failure, and no amount of rotation within our three nodes will change the outcome.
Get a key
Create an account and mint an API key in the dashboard. The full endpoint reference — request shapes, parameters and error codes — is published at https://api.roamingproxy.com/v2/docs.