Before the integration, open the record.

A useful brief is specific:

“We need to retrieve our tracked questions, complete AI answer text and cited URLs through authenticated API access, then reproduce our weekly measures in our own reporting system.”

Add the decisions your report must support. An agency may need to explain why a client disappeared from a shortlist. A brand team may need to review inaccurate product descriptions. Both require evidence the headline score cannot supply on its own.

A file export can also contain detailed evidence. It differs from an API in how your team retrieves it, authenticates access and handles repeat delivery. Ask about each separately.

Current documentation makes that distinction concrete:

• Ahrefs’ Brand Radar AI Responses endpoint documents response text and links with URLs and titles. Its comparison status called “no_change” means the prompt was answered on both dates; the documentation explicitly says this does not establish that its text, mentions or citations stayed the same. Ahrefs API reference
• Scrunch describes separate query and response APIs. Its response API FAQ lists full answer text, individual citations and URLs, plus response metadata. That is a useful starting point for requesting the actual record and its field definitions. Scrunch API FAQ
• Otterly’s export guide lists raw AI response exports in CSV and JSON, alongside other report formats and a Looker Studio connector. That page documents export options; use separate API documentation to establish programmatic retrieval requirements. Otterly export guide

These are examples of documented capabilities, checked October 19, 2026. Each still needs testing against your procurement requirements.

Ask for a response to one of your own non-confidential questions. Use the engine surface and geography you intend to track. If the supplier sends a standard sample, establish whether it comes from the same endpoint and plan you are considering.

The record below is a proposed buyer-side format. Every value is illustrative, including the fictional HarborDesk brand and .example URL. It is not an actual vendor response or a Gist API specification. A supplier can use different field names if the mapping is documented.

{
  "schema_version": "1.0",
  "record_id": "obs_20261019_q17_s1_a1",
  "collection_id": "weekly_20261019",
  "slot_id": "q17_v3_engineA_repeat1",
  "attempt_id": "attempt_1",
  "question": {
    "id": "q17",
    "version": 3,
    "text": "Which help desks support shared inboxes?"
  },
  "engine": {
    "provider": "Example provider",
    "surface": "provider_api",
    "model": null,
    "model_state": "not_disclosed"
  },
  "context": {
    "country": "US",
    "language": "en",
    "web_search_requested": true,
    "web_search_observed": true,
    "conversation": "new",
    "personalization": "none_configured"
  },
  "requested_at": "2026-10-19T09:00:00Z",
  "observed_at": "2026-10-19T09:00:08Z",
  "ingested_at": "2026-10-19T09:01:12Z",
  "status": "completed",
  "answer_outcome": "answered",
  "error": null,
  "answer": {
    "text": "HarborDesk supports shared inboxes.",
    "format": "plain_text",
    "truncated": false
  },
  "citation_capture": "complete",
  "citations": [
    {
      "source_id": "src_1",
      "kind": "inline",
      "url": "https://harbordesk.example/shared-inbox",
      "title": "Shared inbox",
      "anchor": {
        "role": "supported_text",
        "unit": "unicode_code_point",
        "start": 0,
        "end": 35,
        "text": "HarborDesk supports shared inboxes."
      }
    }
  ],
  "retrieval_sources": {
    "availability": "not_provided",
    "items": null
  }
}

The answer is deliberately short so you can check the entire record. Its citation anchor covers characters 0 through 34; the end value is exclusive. A production test should also use longer answers and non-ASCII text.

The fields that protect your report

Identity: record_id identifies one recorded collection result. collection_id groups a collection batch. slot_id identifies the planned question–engine–repeat slot; attempt_id distinguishes collection attempts. Ask how failed attempts and retries are represented, including whether a rerun produces a new answer and a new charge. Fetching an existing record twice should not count as two observations.

Question version: store the exact submitted text. If the wording changes, create a new version. Keep any supplied system instructions or conversation context available for comparison, with appropriate access controls.

Collection context: “ChatGPT” alone may be too broad. Establish whether the data came from a consumer interface, an official model API or another collection method. Request the surface and model version when available, along with geography and language. Mark undisclosed settings as unknown. Keep API results and consumer-interface results in separate comparison series.

Search settings: web_search_requested records what the request asked for. web_search_observed records whether the returned collection evidence establishes that search was used; set it to null when that is undisclosed. Requesting search does not prove it occurred, and a citation alone should not be treated as proof of a particular retrieval event.

Times: requested_at records when collection was requested; observed_at records when the answer or outcome was captured; ingested_at records when your system received it. A batch ID is an identifier, not an event time. Specify UTC timestamps, and document any provider fields that contain only a date or an update time. Do not invent missing precision.

Status: distinguish completed, partial, failed and pending collection work. Keep the answer outcome separate: answered, no_answer or refused, for example. A successfully checked surface with no AI answer is different from a collection failure. Document error codes and whether partial text is retained. Neither a failure nor an absent answer should become an eligible answer with zero mentions.

Full text: answer.text should preserve the collected answer rather than a vendor-written summary. Agree on format and truncation rules. Store vendor-derived sentiment or brand classification in separate fields with a method version when available.

Citation mapping: keep the cited URL and source identifier attached to the answer. If you need claim-level review, ask for the relevant text span or citation marker and its indexing convention. Some suppliers may provide only an answer-level source list. Treat that as a documented limitation against your needs; do not invent the missing mapping.

This level of detail is possible in some documented outputs. For example, DataForSEO’s ChatGPT LLM Responses reference describes text sections and citation annotations with URLs, start/end indexes and annotated text. Its documentation also explains that annotations can be null when web search is not requested, or empty even when web search is enabled. Its published example indexes the citation’s link markup; do not assume those offsets identify every claim the source supports. DataForSEO response reference

Sources: keep cited sources separate from a broader retrieval-source list. If the latter is unavailable, say so. An empty array should mean a known empty result under the agreed schema; null should have a documented meaning such as unavailable. A cited URL does not, by itself, prove that the source supports the answer’s claim.

Estimate your collection workload before comparing plans. Twenty questions across three surfaces, with five repeats and four collection dates, produce 1,200 planned collection slots.

Those are not necessarily 1,200 API calls. One collection may require job creation, status checks and paginated retrieval. Historical downloads or particular fields may carry separate charges. Ask for the applicable units, concurrency limits, overage treatment and any restrictions on the plan you are buying.

Have the supplier price the same workload you piloted, including the retention period and history you need. Confirm who owns the integration when the schema changes.

Start with public, non-confidential prompts. Before adding private client information, request the supplier’s data-processing and security documentation, plus its retention and deletion policies. Confirm permitted use with your own team.

The review should establish who can access stored questions and answers, whether they are used for model training, which subprocessors receive them and where they are stored. Include backup retention, deletion timelines and what happens to your exports when the contract ends. Check project or client isolation, available read-only scopes, and how access is revoked or rotated.

For an agency, also confirm that the agreement permits the intended client reporting and redistribution. An API returning data does not settle your rights to reuse it. Give the relevant owner the actual documents, rather than converting marketing language into a compliance conclusion.

Some teams need a warehouse pipeline. Others mainly need an evidence-backed set of actions they can hand to a content owner each week.

Gist GEO’s documented Opportunities include subtasks with impact and effort labels, with Markdown and PDF handoffs. If that is your immediate job, bring a real question to a Gist GEO demo and inspect the action handoff before commissioning a custom reporting build. See the product workflow.

If API access is essential to your requirements, ask any supplier, including Gist, for its current endpoint documentation and an actual sample record. Make the purchase decision against the fields and pilot results your team needs.

Publisher disclosure: This article is published by Gist, the company behind Gist GEO. Product documentation was checked on October 19, 2026. The proposed record is vendor-neutral and does not establish Gist API availability or compatibility.