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 (UTC)
unevenlabs	🔴 Failed	–	Sep 1, 2026, 10:57 PM

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

[github-actions]

Claude finished @ipeleg's task in 1m 58s —— View job

---

Code review — docs(drift): draft from internal source

• Gather PR diff and context
• Review references/api/api_core_concepts/input-validation.mdx
• Review references/api/changelog.mdx
• Check style-guide conformance (AGENTS.md) and link resolution
• Post review

The change is coherent: deprecation → removal, with tense updated on the migration prose and the changelog lead switched from **Deprecated** to **Breaking**. I verified there are no other references to the signature endpoints anywhere in the repo, no MDX stub or docs.json entry to retire, and every internal link in the touched text resolves. Four things worth a look before merge.

---

1. The changelog entry was rewritten in place, erasing the deprecation record

references/api/changelog.mdx:6-8 — the 2026-09-01 entry previously announced the deprecation; it now announces the removal under the same heading. That deprecation text has already been built into the generated root changelog.mdx:14-16, so once the hourly sync runs, readers who saw "deprecated, keeps working for now" will find only "removed" in its place, with no trace of the intermediate state.

If both really landed the same day and the deprecation entry was a draft that never reached readers, this is the right edit and you can ignore it. If the deprecation shipped, §4.5's newest-first log argues for a second entry rather than an overwrite. Your call — flagging because it's not recoverable from the diff alone.

No action needed on root changelog.mdx itself: it's generated, and per §4.6 the sync PR will pick this up.

2. Two near-identical <Warning> callouts now say the same thing

input-validation.mdx:6-8 and input-validation.mdx:225-227 both state that the endpoints were removed and return 404. Under the deprecation playbook (§4.3) a callout on the page was the convention, but a removal is a breaking change, and §4.2 says the opposite: "No inline <Warning> callout on the updated page. The changelog is the record." — with a narrow exception for a one-line <Info> carrying the date and a changelog pointer.

The duplication is the concrete problem either way: the second warning sits directly above a section whose heading and first paragraph already say it. I'd keep the top-of-page one (integrators landing here from a broken call need the signal immediately) and drop the one at line 225, or convert it per the §4.2 exception. Fix this →

3. Elliptical verb mismatch in the rewritten lead-in

input-validation.mdx:229:

It had several problems that the deterministic flow does not:

The elided verb after "does not" is present-tense "have", which no longer matches "had". Switching to an explicit verb reads cleanly — "It had several problems that the deterministic flow avoids:" — and keeps the past-tense bullets below it consistent. Fix this →

4. Migration instruction still reads as optional

input-validation.mdx:236 — "To migrate, replace the GET /requests/:requestId/signature/v2 call with includeProtocolData: true … you remove a network round trip in the process." That framing was written when migration was elective. Now that the call 404s, the round-trip saving isn't a benefit anyone is weighing — anyone reading this section is already broken. Minor, but the closing clause is worth trimming.

---

Content I could not verify

The 404 claim itself comes from the internal source PR — I have no access to the OpenAPI spec or the source diff, so someone with that context should confirm the endpoints return 404 rather than 410 or a spec removal. That's checklist item 1 in the PR body.

Nothing internal-only leaked into the draft: the only identifiers added are the two public endpoint paths and a status code.
· branch docs-drift/src-48d881da5a-9db742e

[greptile-apps]

Greptile Summary

This change updates request-signature migration documentation to say the legacy endpoints have been removed and return 404, while directing integrators to deterministic offline verification. Repository history confirms the approved wording announced a future retirement rather than a completed removal. The published removal and HTTP-status claims should be reverted until retirement timing and post-retirement behavior are explicitly confirmed.

Confidence Score: 4/5

Not safe to merge until the endpoint-removal statements match the approved retirement status.

One independently verified documentation defect remains: the page states completed removal and 404 behavior although the documented scope describes a future retirement.

Files Needing Attention: references/api/api_core_concepts/input-validation.mdx needs its removal and 404 wording corrected; matching migration and changelog statements should also be kept consistent with the confirmed retirement status.

T-Rex Logs

What T-Rex did

• T-Rex produced a proof for a posted P1 finding and attached evidence sources including a scope query script and related logs to support the removal claim.
• T-Rex produced a general-contract-validation-proof with a reproducible evidence path, including the scope query script, its output log, and before/after removal line-7 state logs.
• T-Rex produced a second P1 finding proof as noted in the review comment (no artifacts attached).

_{Ran code and verified through T-Rex}

Comments Outside Diff (1)

1. General comment

   Removal and 404 claim is not supported by the approved retirement scope

   • Bug
     • At references/api/api_core_concepts/input-validation.mdx:7, PR docs(drift): draft from internal source #441 states that both request-signature endpoints "have been removed and now return 404". The reachable INT2-1380 review branch instead says they "are deprecated and will be retired" and tells readers not to use them in new integrations. The PR-head commit independently changes the migration warning and API changelog from availability/deprecation to removal/404. Thus the claim asserts post-retirement behavior although the repository-visible approved scope supplies advance notice only and does not establish retirement timing or resulting HTTP behavior.
   • Cause
     • The generated drift commit e0c4b1a replaced the previously reviewed deprecation language with definitive removal/404 wording without repository-visible evidence of an approved completed retirement.
   • Fix
     • Restore the advance-notice wording (deprecated, do not use for new integrations, will be retired) unless an approved source explicitly confirms retirement has occurred and that both endpoints return 404; only then update all matching warning and changelog statements together.

   _{Ran code and verified through T-Rex}

_{Reviews (1): Last reviewed commit: "docs(drift): draft from internal source" | Re-trigger Greptile}

[greptile-apps]

Removal claim precedes approved retirement

This warning states that both signature endpoints have already been removed and return 404, but the approved INT2-1380 wording says they are deprecated and will be retired. The same unsupported post-retirement claim is repeated in the migration warning below. Restore the advance-notice wording unless an approved source confirms that retirement has happened and establishes the resulting HTTP behavior; otherwise, existing callers may prematurely remove a still-supported fallback without a published retirement date.

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!

Artifacts

Evidence query source for the input-validation removal claim

• This executable query reads the repository history and branch scope plus GitHub PR docs(drift): draft from internal source #441 metadata and captures the result, ending with the takeaway: the evidence path is reproducible.

Executed scope evidence output for PR 441

• This captured command output identifies the target line, approved review-branch wording, PR metadata, and the removal-changing commit, ending with the takeaway: the removal/404 assertion is outside the evidenced scope.

Approved review branch line 7 before the removal assertion

• This executed capture shows the approved branch's line 7 says the endpoints are deprecated and will be retired, ending with the takeaway: only advance notice is documented.

PR 441 head line 7 after the removal assertion

• This executed capture shows the PR head's line 7 says the endpoints have been removed and return 404, ending with the takeaway: it asserts unproven post-retirement behavior.

_{Ran code and verified through T-Rex}