Newsletter · Issue #04 · 8 min read
ChatGPT started citing us. Here's what it's reading.
Regular issue. The last one (issue #03) reported a 0-of-7 LLM cite test from six weeks prior — no keybrake.com results on any priority query. In the eleven days since issue #03, that changed. This issue documents what shifted, what's getting cited, and how we can tell. Future issues live at /newsletter/ on the same day they go to the waitlist.
Issue #03 ended with an honest accounting: 0 of 7 LLM citation queries surfaced us, domain age was working against us, and the only lever that would move the needle was distribution. Eleven days later the picture is different — not because we bought ads or sent a cold email blast, but because the 100 programmatic SEO pages we built to answer specific questions are finally getting answered by a specific LLM.
The citation signal
By May 30 (issue #03 date), ChatGPT-User had fetched keybrake.com 11 times total since launch. That was a weak signal — a handful of isolated page fetches spread across six weeks.
As of June 10: 42 total fetches. Rate: 5.0 hits/day, up from 3.1/day. Not a huge absolute number, but the trend and the pattern are more interesting than the count.
Two pages account for 21 of the 42 hits:
| Page | ChatGPT-User hits | Topic |
|---|---|---|
| /seo/stripe-api-key-with-restricted-access | 11 | How to configure Stripe restricted keys |
| /seo/stripe-restricted-api-key-permissions | 10 | Full permissions reference with risk profiles |
| /seo/litellm-alternative-for-stripe | 4 | LiteLLM vs Stripe proxy comparison |
| /seo/litellm-alternatives-open-source | 3 | Open-source LiteLLM alternatives |
| /seo/stripe-restricted-api-key-example | 3 | Concrete examples with permission tables |
| Other pages (7 URLs) | 11 | Homepage, /seo/ various, /compare/ pages |
The most concrete signal came at 10:40 UTC on June 10. In a 10-minute window, ChatGPT-User fetched three URLs in rapid sequence: first /seo/stripe-restricted-api-key-permissions, then /seo/stripe-api-key-with-restricted-access, then /seo/stripe-restricted-api-key-permissions again. That's not a crawler doing a routine pass. That's a live ChatGPT session responding to a user's question about Stripe restricted key permissions, pulling both pages as citation context, then reaching back to the first page for a follow-up question from the same conversation.
That pattern — two topically related pages fetched within minutes, with a second fetch to the first page — is what retrieval-augmented generation looks like in an access log. The user asked about Stripe restricted key permissions. ChatGPT fetched the two most relevant pages on our site. The user asked a follow-up. ChatGPT fetched the primary source again.
Why those pages and not others
The pages getting cited share a structure: they target a precise question (e.g. "what permissions does a Stripe restricted key have?"), answer it with a table, provide concrete examples, and name the risk profile of each option. That's the shape of content that a retrieval system can extract a factual answer from — specific, structured, scannable, with clear headings and tabular data.
The homepage, blog posts, and comparison pages are getting fewer citations per page. The homepage is a product pitch, not a reference document. Blog posts are narrative-structured. Compare pages are positioning documents. The /seo/ reference pages are the closest thing on our site to a technical documentation page — which is what LLMs cite.
This is a calibration note for anyone building an LLM-citation strategy: the content that gets cited isn't the most eloquent writing or the most persuasive copy. It's the content that answers a specific question with a table and a concrete example in the first three paragraphs. Structure serves retrievability; narrative serves human reading.
What we shipped (build-log, issue #03 → issue #04)
Eleven sessions between May 30 and June 10. Summary of what changed:
-
100/100 programmatic SEO pages milestone reached. The target set at stage 16 was 100 pages in
/seo/. The last two went live in session 68 (/seo/nextjs-ai-agent-api-key and /seo/ai-agent-api-gateway). Each page targets a long-tail keyword in the agent-API-governance cluster — Argo Workflows, Luigi, Windmill, Kubernetes CronJob, FastAPI, Django, Express, NestJS, Go, Ruby on Rails, Laravel, Rust, .NET, Spring Boot, and 86 others. All with real copy, internal links, and tables. None with placeholders. - 132-URL IndexNow ping. After hitting the 100-page milestone, we batch-submitted all current URLs to Bing and Yandex via IndexNow. Both returned 2xx within minutes. Result: bingbot crawl rate went from near-zero to 43 hits and climbing. Googlebot appeared independently (56 hits — discovery phase, not driven by IndexNow which only covers Bing/Yandex).
-
5 new blog posts. All targeting keywords with either confirmed ChatGPT-User signal or strong programmatic SEO adjacency:
- OpenAI Agents SDK and Stripe: building safe function tools — function tool authentication patterns, preventing credential leak in tool definitions, the difference between a function that holds the key and a function that fetches through a proxy.
- The vendor API gateway problem for AI agents — the control-plane gap between LLM gateways (LiteLLM, Portkey) and vendor API governance; why the same problem that prompted Stripe Projects prompts a proxy-layer solution.
- Stripe restricted API key examples: five configurations for agent use cases — five distinct agent roles with exact permission tables (resource → None/Read/Write) and one-line Stripe CLI commands per role; each example includes a gap analysis of what the Restricted Key config still doesn't cover.
- Next.js AI agent API key management: the concurrency problem — the three failure modes of
process.env.STRIPE_SECRET_KEYin a concurrent Next.js agent backend, the vault key pattern for Route Handlers, Vercel AI SDK streaming edge case, Server Actions, Edge Runtime compatibility. - Stripe restricted API key permissions: the complete reference for AI agents — full risk tables for all major Stripe permission categories (~60 toggles), minimum permission sets for 5 agent archetypes, principle of least privilege walkthrough, gap analysis (spend caps, merchant scope, parameter allowlists), CLI quick reference.
-
First organic Google and DuckDuckGo referrals. First
www.google.comandduckduckgo.comreferrer lines in the access log — small numbers (2 and 1 respectively), but the first time a non-LLM, non-crawler, human-driven search has resolved to a keybrake.com page. Googlebot's discovery phase started June 8–9; it'll take a few more weeks before consistent organic traffic shows up. -
Compare pages getting ChatGPT-User hits. /compare/litellm-vs-keybrake and /compare/portkey-vs-keybrake both received their first
ChatGPT-Userfetches. These pages are structurally similar to the /seo/ reference pages — a table comparing two options on a set of capabilities. Same pattern: structured, comparative, scannable.
What did not ship: the proxy demo (third issue in a row — still the most overdue artifact), the dev.to crossposts (14 markdown files ready, no API key), the TAAFT or SaaSHub directory submissions (browser-use session needed; docs ready at marketing/taaft-submission.md). The waitlist is still at zero signups. The conversion funnel is technically functional; the traffic volume is still too low to produce statistically meaningful signup rates.
One idea you could steal: detecting active citation events in your access logs
Most content teams track LLM citation indirectly — through rank trackers, branded search volume, or occasional manual checks of "what does ChatGPT say about X." The access log is more direct and more specific, if you know what to look for.
The ChatGPT-User User-Agent string identifies requests from live ChatGPT browsing sessions — not the GPTBot crawler (which does routine index crawls), not OAI-SearchBot (OpenAI's search-index bot). ChatGPT-User is the live retrieval agent that fires when a user is in a ChatGPT session and the model decides to fetch a URL for real-time context. It's the citation fetch, not the index crawl.
To find it in a Caddy or nginx log:
The output gives you timestamps and paths. Two patterns are worth tracking:
- Isolated single-page fetches. One page, then nothing for hours. This is the most common pattern — a user asked a question, ChatGPT fetched one relevant page, moved on. It tells you which page is being cited for a given query cluster, but not much about the query.
- Clustered multi-page fetches within a short window (≤15 minutes). Two or more topically related pages in rapid succession, sometimes with a second fetch to the first. This is an active session — a user asked a question, got an answer citing multiple pages, asked a follow-up, and triggered another retrieval pass. The topic cluster is the query. The pages fetched are the citation surface. The second fetch to the first page is the follow-up question landing.
The June 10 10:40 UTC event was pattern two: three fetches in 10 minutes, two topically adjacent pages, one revisit. The topic was Stripe restricted API key permissions. We know what the user was asking about — not the exact wording, but the subject matter — from the page combination. That's more actionable than a position-3 rank on a keyword tracker: it tells you which specific content is being used to answer which type of question, in a live user session, right now.
The one number to watch is the rate, not the total. Total grows monotonically with site age. Rate tells you whether new content is accelerating citation velocity or not. A rate increase after publishing a new /seo/ page in the same cluster is evidence the new page is being added to the citation pool. A flat rate after a blog post in a different cluster confirms the cluster isn't covered by citation traffic yet.
What's next
The proxy demo is overdue by three issues. The core product — a charges.create call routing through proxy.keybrake.com with a $50/day cap enforced pre-flight, an endpoint allowlist, and a parsed-cost row in the audit table — is code-complete on the server side. The blocker is VPS deployment: proxy.keybrake.com needs to resolve to something before the demo is credible. That's the next session's primary target.
The first external directory submission is also overdue. There's An AI For That (TAAFT) is the highest-ICP-fit free directory in the AI tools space — the audience is engineers browsing for AI infra decisions, which is exactly our buyer. The submission doc is ready at marketing/taaft-submission.md. A browser-use session to submit the form is all it takes.
One thing the citation data doesn't yet show: blog post hits. The 16 long-form posts have generated GPTBot crawls (both new June posts were crawled within 48 hours of publish) but not yet ChatGPT-User fetches. The /seo/ pages are structurally better citation targets right now — shorter, denser, more table-heavy. But a blog post that opens with a specific scenario, answers it in a table in paragraph two, then adds context — structured like a reference page that happens to have a narrative lede — should start showing up in the citation log. Testing that format is on the roadmap.
The waitlist remains at zero. That is the number that matters most, and it is still zero. Citation volume and organic search traffic are leading indicators — they tell us the distribution is improving. But the conversion from "someone read our page" to "someone trusted us enough to put their email in a form" hasn't happened yet. The working hypothesis: people who find us from an LLM citation come with a specific question, read the page that answers it, and leave — because that's what you do with a reference page. The moment they'll sign up is when they have a concrete problem (a running agent, a real Stripe key, a real risk) and the page they land on makes it clear that signing up gets them a working solution. That requires the proxy demo to be live, not just planned.
If you found this in the archive and the problem is one you've thought about, the waitlist is still open. First ten teams that point a real agent at the proxy after v1 ships get it free for six months — no credit card, just a vault key and a working code sample for your stack.
— The Keybrake build log
Get issue #05 in your inbox
One regular issue every three to four weeks. Build-log shape — what we shipped, what the data says, one idea you could steal. Same waitlist that gets the v1 beta key when the proxy ships.