RAG pipelines are only as good as what they retrieve, and model snapshots go stale the day they ship. Search-engine result APIs give you links without answers; model APIs give you answers without the live retrieval a consumer surface runs. Grounding on captured AI-surface answers gives you both, current, source-backed answer text your pipeline can quote, verify against, or decompose, in one contract per surface.
Real endpoints, real field names, nothing below is pseudocode.
step 1 / 4
Add ?mode=sync (or Prefer: wait) to block for inline Envelopes instead of polling, built for a pipeline step where a user is waiting. Sync and async are the same endpoint and body, with no sync surcharge.
curl -sS -X POST "https://api.aisearchapi.dev/v1/search?mode=sync" \
-H "Authorization: Bearer $AISEARCH_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"query": "current EU AI Act enforcement status",
"surfaces": ["perplexity"],
"regions": [{ "country": "DE" }]
}'
# → 200 with the terminal Envelope inlinestep 2 / 4
Ask for ?view=flat and skip the nesting: surface, status, text and markdown, the fields a grounding step consumes. The full Envelope with provenance is one query-param away when you need it.
{
"surface": "perplexity",
"status": "completed",
"text": "the answer as plain text",
"markdown": "the answer as markdown"
}step 3 / 4
Use answer.markdown as grounded context; any sources the surface cited are already inline in that markdown, ready to surface to your users. Because the shape is identical across surfaces, swapping or ensembling grounding surfaces is a config change, not a new parser.
step 4 / 4
A surface with no answer completes as surfacePresent:false, never a fabricated answer your RAG step would ingest as truth, and a capture that could not run fails loud with a machine-readable reason. Honest empties are a feature in a grounding pipeline, branch on them.
Every surface returns the same canonical Envelope, so these fields mean the same thing whether the capture came from ChatGPT, Perplexity or an AI Overview.
answer.markdownAlways-populated, normalized markdown, drop-in grounded context for a generation prompt, with the surface’s inline citations intact.
answer.textThe same answer as plain text, for pipelines that tokenize or chunk before generation.
provenance.capturedAtFreshness stamp per capture: your pipeline knows exactly how current its grounding is.
provenance.surfacePresentA truthful empty instead of a hallucination-shaped blank, branchable in code.
job.status + warningscompleted / partial / failed with machine-readable reasons, grounding steps need failure semantics, not mystery nulls.
Sync mode is bounded server-side and designed for single-surface, single-region calls where a human is waiting; if the wait runs long it degrades gracefully to a 202 you poll. Real browser captures take longer than a cached-index lookup, if you need sub-second SERP snippets and no answer layer, a classic SERP API is the better fit and we say so. Sync concurrency is plan-limited; high-QPS grounding should mix sync for interactive paths with async + webhooks for the rest.
Terms used here, defined precisely: Envelope · Absence-is-data · Provenance
A search API returns links and snippets; your pipeline still has to read, rank and synthesize them. A captured Perplexity or ChatGPT answer has already done live retrieval and synthesis on the real surface, and arrives with its citations attached, one hop to grounded, source-backed context. Many pipelines use both: google_search for breadth, an answer surface for synthesis.
It runs the same real-browser acquisition inline, so it is bounded by genuine surface latency, captures take longer than an index lookup, and we will not quote a fake number. The honest engineering answer: use sync for the interactive path where the grounding is the product, cache aggressively, and push everything else through async + webhooks.
That failure mode is designed out: an absent answer is an explicit surfacePresent:false with a surface_absent warning (and costs nothing), and a capture that could not complete is an explicit failed status with a machine-readable reason. Your pipeline branches on contract fields instead of guessing whether an empty string means "no answer" or "broken scraper".
Yes, the same captures work offline: batch-submit query sets, store the Envelopes, and you have dated, source-attributed (evidence.sources), provenance-stamped answer data for evals and fine-tuning corpora. Opt into the proof-of-page HTML snapshot (include.html:true, browser surfaces) to keep an auditable page reference alongside each stored Envelope.
500 free credits, charged only on successful captures. The whole workflow above runs on two endpoints.