OpenRewardBackSearch
Search the web as it was.
BackSearch is a point-in-time search and fetch API over a frozen archive of the web. Every request carries an as_of date. Search returns only documents archived on or before it, and fetch returns a page as it was captured at that time. The archive never moves, so the same query with the same date returns the same results forever.
BackSearch is hosted on OpenReward and authenticates with your existing OpenReward API key. There is nothing else to set up.
How it works
Two endpoints, one header. The base URL is https://search.openreward.ai and it authenticates with your existing OpenReward or_... key in the x-api-key header.
01
Pick a date
Set as_of to the day your agent is meant to be living in. Everything archived after that day is invisible to it.
02
Search
Hybrid search over the archive. Each hit carries the archived URL, a snippet, the corpus it came from and the date it was captured.
03
Fetch
Give it a URL and the same cutoff, and you get the extracted text from the latest capture on or before that date. Not today’s version of the page.
Each hit comes back with the archived URL, title, snippet, host, the corpus it came from and both dates:
/fetch is the point-in-time counterpart. Give it a URL and a cutoff and you get the extracted article text from the latest capture on or before that date, not today's version of the page.
The cutoff gates on when a page was archived, not on the date the page claims for itself. A self-reported date is exactly the field a backdated crawl can't trust, and gating on the capture is what guarantees nothing after the cutoff leaks in. Sources that carry an official date gate on that instead: SEC filings on their filing date, arXiv papers on the date each version was posted, and Wikipedia on the date of its monthly snapshot.
What it is for
A frozen web earns its keep whenever the live one would either give the answer away or refuse to stay the same twice.
Predictive forecasting
Score a model on questions whose answers you already know, with the evidence horizon pinned before resolution. Step the cutoff forward one day at a time and an agent lives through a past window, reading the news as it broke and trading or predicting on what it finds.
The same holds for training. A forecasting reward only means something if the policy can’t look up the outcome, so backdated retrieval is what makes reinforcement learning on resolved questions honest.
A cached internet for evals and training
The live web is a moving target. Run the same agentic eval twice against it and you get different rankings, rewritten pages and dead links, so a change in score may be the model or may be the internet. Against BackSearch the same query with the same cutoff returns the same bytes every time.
For reinforcement learning, a stable corpus keeps rewards comparable across steps and runs, keeps rollouts off the open web, and lets anyone replay a trajectory exactly.
What is in the archive
Five sources. Rolling sources are refreshed continuously and trail the present by a few days. We are growing the archive going forward.
| Source | Corpus | Coverage | Gates on |
|---|---|---|---|
| News | cc_news | 2025-12-01 → now | crawl date |
| SEC filings | cc_sec | 2023-01-03 → now | filing date |
| arXiv | cc_arxiv | 1991-08-14 → now | version date |
| Wikipedia | cc_wiki | 2026-02-01 → now | monthly snapshot |
| Web | cc_web | 2025-06-12 → now | crawl date |
arXiv
Every paper since the first postings in August 1991, with each revision as its own capture. A cutoff between v1 and v2 returns v1. Fetch returns the LaTeX source of that version.
Wikipedia
English Wikipedia as a monthly snapshot taken on the first of each month. A cutoff resolves to the newest snapshot on or before it.
SEC
EDGAR filings since January 2023, including 10-Ks, 10-Qs, 8-Ks, 13Fs and Form 4s. Filings gate on their filing date rather than the crawl, because a filing’s date is official. Fetch returns the full text of the filing.
Works with your stack
Because the endpoints are plain HTTP, they drop into any model that supports function calling. Wrap search and fetch as two tools, hand them to the model, and the model researches the past the same way it would research the present.
Inside OpenReward environments the same engine is available as a toolset. Declare it on the environment and the agent gets web_search and web_fetch, both bounded to the cutoff. For time-stepped environments, expose web_as_of as a property and the agent's window advances with your simulation clock.
Outside an environment, the Backsearch and Backfetch classes in the Python SDK do the same job directly.
Pricing
Pay-as-you-go against your prepaid OpenReward balance, with no subscription. See full pricing.
Only successful requests are billed. A search that errors, or a fetch that finds no capture on or before your cutoff and returns 404, costs nothing. Check what you've spent with orwd usage.
Rate limits
Each API key has its own limit on search and on fetch, counted separately, so fetching the results of a search never spends your search allowance. A key can run at the sustained rate indefinitely and briefly go above it, up to the burst.
| Endpoint | Sustained | Burst |
|---|---|---|
| Search | 2 requests/sec | 20 requests |
| Fetch | 2 requests/sec | 60 requests |
A request over the limit is refused with 429 Too Many Requests and is not billed. Retry-After gives the whole number of seconds to wait, X-RateLimit-Limit the sustained rate of the limit you hit, and X-RateLimit-Scope which limit it was:
callerYour API key went over its own limit.
globalThe service as a whole is at its ceiling. Temporary.
overloadSearch is briefly at capacity. Retry after a second.
Clients must honour Retry-After. Wait at least that long before retrying, and add random jitter so that parallel workers spread their retries out instead of returning together and being refused again:
Need more than this? Email hello@gr.inc with your use case and the request rate you expect, and we'll raise the limit on your key.
Enterprise
The preview is self-serve. Some work needs more than that: an archive that reaches back further than the windows above, sources we don't index yet, or the corpus delivered into your own environment. Tell us what you're building and the coverage it needs, and we'll work out the shape of it with you.