Canonry calls model providers' APIs directly so we can control the request and preserve the evidence behind each answer. A cheaper answer is less useful if we cannot explain why your brand appeared or disappeared.
Three routes, different evidence
The same model name can hide different search tools, request settings, and response formats.
- Canonry
- Provider API
- Answer + native evidence
- Tracking tool
- Router
- Provider API
- Mapped response
- Tracking tool
- Consumer app
- Visible answer + links
- Direct integrations expose the provider's supported controls and response fields.
- Routers simplify access and can improve availability. The integration must verify what survives translation and fallback.
- Browser scraping records one session in the consumer app. The visible page may omit underlying search details.
A direct API does not reproduce the consumer app. Canonry has a separate browser adapter for that surface.
Where cheaper access can weaken a report
A routing decision can affect more than the bill:
- A fallback can change which provider serves the request.
- An unsupported parameter can be ignored.
- A different search backend can change the sources available to the model.
- A simplified response can lose detail needed to explain a result.
OpenRouter documents provider selection, fallbacks, and parameter support. Its search integration supports native search for some models and external search for other configurations.
Routers can preserve useful evidence. The problem is assuming equivalence without checking. If a service cuts costs by changing the model or search behavior, its old and new scores need a fresh comparison baseline.
The same applies to scraping: a dataset containing only answer text and visible links cannot explain search behavior it never recorded.
A retrieved page is not always a citation
Imagine a model searches for roofing companies, finds several pages, and uses only one to support its answer. The distinction looks like this:
The model issues a roofing query.
Several pages become available.
A source supports an answer passage.
The final answer references that source.
Canonry keeps these signals distinct:
- A mention means the answer names the brand.
- A retrieved source means a page appeared in the search evidence.
- A citation connects a source to the answer, using the evidence that provider returns.
For Gemini, we preserve source chunks, answer-support mappings, and issued search queries. Citation selection prefers chunks referenced by the support mappings. Counting every retrieved page as a citation can inflate the result.
What each integration retains
| Provider | Evidence we preserve | Parsing detail |
|---|---|---|
| Gemini | Answer, source chunks, support mappings, search queries | Prefer sources tied to answer passages. |
| OpenAI | Answer, URL annotations, search queries | Search-tool source lists alone are not final citations. |
| Claude | Answer, final-text citations, search queries | Search-tool errors are failures, not silent misses. |
| Perplexity | Answer and source objects, with citation-list fallback | No documented returned search-query telemetry. |
Missing evidence also needs a label:
- No returned search queries does not prove that no search happened.
- A failed search does not prove that the brand was absent.
- Discarded support mappings cannot be reconstructed from a URL list.
This is the granularity we need when investigating a change in visibility.
Location is a request setting worth checking
For a Phoenix roofing company, the report should explain how Phoenix entered the request.
| Canonry integration | How location is supplied |
|---|---|
| OpenAI | Structured user_location on the search tool. |
| Claude | Structured user_location on the search tool. |
| Gemini | Location context added to the prompt. |
These methods have different limits. Changing the location method changes the test setup; neither method guarantees every local buyer sees the same answer.
What we pay to preserve
We maintain separate integrations because we need to:
- Choose a model that supports the required search behavior.
- Retain answer text and available source evidence.
- Record model identity and document location handling.
- Test citation parsing, missing fields, and provider errors.
- Balance token costs, search costs, latency, and quotas so measurements can be repeated.
A successful text completion does not establish that all of this works. Our model-selection criteria cover the complete request and response.
Direct APIs take more integration work. We accept that cost so an agency can inspect the evidence before asking a client to change their website.