docs(drift): draft from internal source

[pedromcunha]

Drafted from an internal source repo, requested by @ipeleg.

This PR was auto-generated by the reusable-docs-draft-pr workflow from a Claude-drafted update in the source repo. It is opened as a draft — please review, edit as needed, and mark ready for review before merging.

Review checklist

• Content matches the behavior shipped in the source PR
• No internal-only details (service names, file paths, unreleased names, security internals) leaked into the draft
• Conforms to CLAUDE.md style rules
• Cross-references and internal links resolve
• Any Needs human input items from the source comment are addressed

---

Generated by reusable-docs-draft-pr.yml in relayprotocol/agents-config.

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated
unevenlabs	🟢 Ready	View Preview	Sep 30, 2026, 4:20 PM

💡 Tip: Enable Automations to automatically generate PRs for you.

[github-actions]

Claude finished @ipeleg's task in 47s —— View job

---

Code review — PR #484

• Read the PR diff and AGENTS.md style rules
• Checked migrating-to-requests-v3.mdx for statements that conflict with the change
• Checked references/api/changelog.mdx for a matching entry
• Posted findings

The PR changes one line in references/api/api_guides/migrating-to-requests-v3.mdx:320. It widens the v3 Access scope from "only requests that your integrator owns" to "requests owned by your integrator, plus requests that were created without an API key."

I can't check the new behavior from this repo, so the source PR should confirm it. The edit also leaves the page contradicting itself, and it has no changelog entry.

---

1. The migration checklist still says the old scope — migrating-to-requests-v3.mdx:552

Results include only requests that your integrator owns, from all of your API keys.

Line 320 now says v3 also returns requests created without an API key, but this Step still says "only." AGENTS.md §4.2 requires statements that depend on the change to be updated in the same PR. Suggested wording:

Results include requests owned by your integrator (from all of your API keys), plus requests that were created without an API key.

Fix this →

2. No changelog entry for a change in who can see which requests — references/api/changelog.mdx

Under AGENTS.md §4.4, a fix that changes observable behavior needs an entry in references/api/changelog.mdx. There are two possibilities:

• The API changed: add a ## 2026-09-30 — … entry with a **Behavior change** lead, newest-first.
• The API always worked this way and the docs were wrong: a docs-only fix is fine. Please say so in the PR description.

The heading has to follow the ## YYYY-MM-DD — <summary> shape. Otherwise scripts/build-changelog.mjs silently leaves it out of the unified changelog.

3. The new sentence is unclear about which keyless requests are included — line 320

"plus requests that were created without an API key" can be read as every keyless request on the platform, not just ones connected to your integration. Since this sentence defines access scope, please confirm the rule in the source PR and state it exactly. Two related questions:

• Do keyless requests count toward apiKeyId filtering (line 358)? Presumably they drop out once a filter is applied.
• Keyless requests have no owning integrator. So they probably never return authenticated fields such as data.referrer, data.apiKeyName or data.blockedAddresses, even with includeAuthenticatedData=true. One clause saying so would stop readers from expecting them.

4. Minor style point — line 320

The em dash joins two independent sentences into one long one. The original's period read more cleanly (§2.10):

…for your other keys. If you use more than one key, you do not have to change your integration.

---

PR checklist

• Internal details: nothing internal leaked.
• Links: no links were added or changed.
• Style: the only issue is the em dash in point 4.
• Matches the shipped behavior: I can't verify this here. Points 1 and 2 should be fixed before merge.

[greptile-apps]

Confidence Score: 4/5

[Low risk] Updates migration guide documentation text.

The PR appears safe to merge after the non-blocking access-scope inconsistency is corrected.

Findings

1.  Conflicting access scope ▶

Summary

The PR expands the Requests v3 migration guide’s access-scope description to include requests created without an API key and retains its sibling-key guidance.

• The new scope description needs to be reconciled with the guide’s migration checklist.
• Greptile automatically discovered a related ticket that helped explain the purpose of this PR: clarify Requests v3 access across an integrator’s API keys.

_{Reviews (1) · Last reviewed commit: "docs(drift): draft from internal source"}

[greptile-apps]

Conflicting access scope. This sentence says v3 returns requests created without an API key, but the migration checklist still says results include only requests owned by the integrator. Readers following the checklist cannot tell whether unkeyed requests should appear. Please reconcile the two statements and explain how an unkeyed request is associated with an integrator. Greptile automatically discovered a related ticket stating that the guide should explain how access scope applies to all associated Requests v3 data, which informed this comment.

Source Used: Linear — Update Requests v3 migration guidance

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!