docs.pinecone.io llms.txt: 3 dead .json spec links in OpenAPI section (/control_plane_api.json, /data_plane_api.json, /pinecone.json -> 404)

[wallidsaydi-creator]

llms.txt OpenAPI section: 3 dead .json spec links (/control_plane_api.json, /data_plane_api.json, /pinecone.json → 404)

Summary

The ## OpenAPI Specs section of https://docs.pinecone.io/llms.txt (lines 333–335, the last three entries) references three spec files that return 404:

- [control_plane_api](/control_plane_api.json)
- [data_plane_api](/data_plane_api.json)
- [pinecone](/pinecone.json)

Every other entry in that section (~35 links) points to live *.oas.yaml files under raw.githubusercontent.com/pinecone-io/pinecone-api/.... These three appear to be leftovers from a pre-versioning layout: the naming (control_plane / data_plane / unversioned pinecone) matches none of the current files — pinecone-io/pinecone-api contains no .json specs at all, only YYYY-MM/*.oas.yaml (+ .proto).

llms.txt is the entry point AI coding agents consume to navigate your docs. An agent following the OpenAPI section hits dead ends on exactly the links meant to give it ground truth about request/response shapes — the failure mode this file exists to prevent.

Verified evidence (2026-08-29, all live checks)

URL	Result
https://docs.pinecone.io/control_plane_api.json	404 (2 user agents, redirects followed, final URL = requested)
https://docs.pinecone.io/data_plane_api.json	404 (same protocol)
https://docs.pinecone.io/pinecone.json	404 (same protocol, cf-cache-status: EXPIRED → fresh from origin)
https://docs.pinecone.io/llms.txt	200 — trio present at lines 333–335, under ## OpenAPI Specs (line 291)
Control: sibling entries db_control_2026-07.oas.yaml, db_data_2026-07.oas.yaml, control_2024-04.oas.yaml	200 — section is otherwise healthy
https://docs.pinecone.io/llms-full.txt	200, clean — the trio exists only in llms.txt
pinecone-io/pinecone-api tree (cloned @ main)	0 .json files anywhere; no control_plane/data_plane filenames in any version dir

Suggested fix

The section already lists every current spec correctly, so the minimal fix is deleting the three stale entries, e.g.:

 - [nexus_2026-07.oas](https://raw.githubusercontent.com/pinecone-io/pinecone-api/refs/heads/main/2026-07/nexus_2026-07.oas.yaml)
-- [control_plane_api](/control_plane_api.json)
-- [data_plane_api](/data_plane_api.json)
-- [pinecone](/pinecone.json)

If the original intent was a "latest consolidated" entry, the current closest equivalents are the newest versioned specs (2026-07/db_control_2026-07.oas.yaml, 2026-07/db_data_2026-07.oas.yaml, …), but those are already listed — so removal is the cleanest resolution. Happy to open a PR if the source of these lines is in a public repo (the docs site appears Mintlify-generated; I didn't find a public docs-config repo in the org).

---

Context: I audit AI-agent documentation surfaces for exactly this failure class (stale/dead references in machine-consumed indexes). Recent fixes credited in this space: cloudflare-docs #32985 (merged — llms.txt hub link generation) and context7 #3060 (fix shipped in #3075). I do this as a $5 productized check (sample, profile) — this report is free either way.

[wallidsaydi-creator]

Re-verified today (2026-08-31, 48h after filing): all three entries still serve hard 404s under two user agents with redirects followed —

https://docs.pinecone.io/control_plane_api.json  -> 404
https://docs.pinecone.io/data_plane_api.json     -> 404
https://docs.pinecone.io/pinecone.json           -> 404

One extra observation that makes the fix lower-effort than it might look: every sibling entry in the same ## OpenAPI Specs section of llms.txt uses the raw.githubusercontent.com/pinecone-io/pinecone-api/refs/heads/main/... URL pattern and resolves fine (I spot-checked several, including the newest nexus_2026-07 batch). The three legacy entries are the only ones using site-relative paths — and their filenames match no file in the repo, so they're pre-versioning residue rather than redirects-in-waiting.

That means the minimal fix is either:

1. drop the three lines, or
2. point them at their modern equivalents (e.g. the versioned control_plane_*.oas.yaml files) using the same raw-github pattern as their siblings.

Happy to open a PR for either direction if useful — though I understand these three lines may be generated upstream rather than hand-maintained in this repo, in which case option 1 applied at the generator is the real fix.