docs(verify): fix broken cross-refs surfaced by mintlify broken-links#92
docs(verify): fix broken cross-refs surfaced by mintlify broken-links#92rodrigopavezi wants to merge 10 commits intodocs/revamp-screenshotsfrom
Conversation
- api-reference/endpoints-overview.mdx: replace 4 dead /api-reference/... internal links with the canonical https://api.request.network/open-api/ group anchors. Those internal anchors don't exist on this site (they belonged to a tag-driven generator that's no longer wired up). - api-features/secure-payment-pages.mdx: redirect the POST /v2/secure-payments Card to /api-reference/secure-payments which is the actual page. Remaining mintlify broken-links output: - 24 references to /images/dashboard/*.webp and /images/secure-payments/*.webp — these are the screenshots that Phase D's capture pipeline will produce (see scripts/capture-screenshots.ts). Expected and documented. - 5 references in AGENTS.md to /quickstart, /auth, /rate-limits and two /images/*.png paths — AGENTS.md is internal AI-agent guidance, not user-facing docs. Out of scope for this revamp.
Captured 8 screenshots from staging via the new screenshots Playwright project in request-e2e-tests (which reuses the Synpress + DashboardHelper setup). Dashboard (8): - login-evm.webp, login-tron.webp — unauthenticated /login screens (captured from a fresh Chromium context to defeat the fixture's pre-authenticated state) - home-with-destination.webp — Receiving Route panel - manage-destination.webp — destination + Client IDs section - get-paid-list.webp, get-paid-new.webp, get-paid-detail.webp — incoming payment request flows - pay-list.webp — outgoing payouts list Secure Payment (1): - connect-wallet.webp — wallet picker modal (MetaMask, Coinbase, WalletConnect) Manual / not yet captured (logged by the spec): - dashboard/home-empty, create-destination, generate-client-id, client-id-details — require a fresh wallet without an existing destination, or specific dialogs mid-flow - secure-payments/connect-wallet-tron, payment-options, payment-options-crosschain, advanced-view, payment-success — require a connected payer wallet (Buyer account) + a paid request The mintlify broken-links report should drop from 24 image-related warnings to ~16 after this commit.
…nt options Extended the screenshots Playwright project to capture wallet-gated and mid-flow shots that the first pass marked MANUAL. Dashboard (4): - home-empty.webp — "No route configured" empty state with CTA (captured by deactivating the destination then restoring it) - create-destination.webp — Create Payment Destination dialog mid-flow - generate-client-id.webp — Generate New Client ID dialog with form - client-id-details.webp — Client ID Details dialog with copy button Secure Payment (2): - payment-options.webp — chain × token selector with same-chain indicator and "Choose this currency" CTA (captured after payer wallet connects via Synpress) - advanced-view.webp — same screen with the "show details" expansion showing recipient, reference, amount breakdown Mintlify broken-links: 17 → 11 (5 are AGENTS.md, out of scope). Still deferred (3 shots, intentionally MANUAL): - secure-payments/connect-wallet-tron — needs a Tron-destination link + TronLink browser extension - secure-payments/payment-options-crosschain — needs payer balance on a chain different from the destination - secure-payments/payment-success — needs a real on-chain payment (gas)
Extended the screenshots Playwright project with an actual end-to-end on-chain payment flow (Sepolia, 0.01 fUSDC, Buyer wallet). The capture runs through PaymentHelper.connectWallet → confirmAddressVerification → approveTokenIfNeeded → confirmPayment → waitForPaymentSuccess and snaps the success screen. Result: payment-success.webp shows the green checkmark, $0.01 USD paid, recipient/reference/amount table, "via Token Transfer FUSDC on Sepolia", the on-chain reference hash, and "View on Etherscan" / "View on BlockScout" buttons. Mintlify broken-links: 11 → 9 (5 AGENTS.md out-of-scope + 4 references to the 2 deferred shots). Still deferred (2 shots, intentionally MANUAL): - secure-payments/connect-wallet-tron — needs TronLink installed in the test browser + a Tron-signed-in dashboard session + a Tron destination - secure-payments/payment-options-crosschain — needs the payer wallet to hold balance on a chain different from the destination. Sepolia is the only supported testnet so cross-chain on testnet isn't available; this would need a mainnet setup.
… crosschain Drop the four <Frame> blocks pointing at uncaptured screenshots and replace them with descriptive text. The two shots — connect-wallet-tron and payment-options-crosschain — require setups beyond the staging-wallet auto-capture flow (TronLink + Tron-signed-in session, multi-chain payer balance) and are deferred indefinitely. Touched: - tools/secure-payments.mdx: tron-wallet step now references the EVM modal + a sentence about Tron wallets replacing the list; crosschain step describes the banner-text difference instead of showing a separate shot. - use-cases/multi-chain-checkout.mdx: same treatment, condensed. Mintlify broken-links: 9 → 5 (all 5 remaining are AGENTS.md, out of scope).
… claims There is no Dashboard UI for webhook CRUD. Webhooks are managed programmatically via the Auth API (POST/GET/PUT/DELETE /v1/webhook with the x-client-id header) and tested via POST /v1/webhook/test. The earlier Phase A Portal sweep mistakenly retargeted these claims at the Dashboard instead of the auth-api endpoints — fix that across every page that mentions webhook setup. Touched: - api-reference/webhooks.mdx — replaced "Setup in Dashboard" + "Portal Testing" sections with the actual create/manage/test curl flows; cards updated; troubleshooting tips reference auth-api endpoints. - api-features/webhooks-events.mdx — Development Tools card now points at the auth-api webhook endpoints instead of the Dashboard. - api-reference/authentication.mdx — split the Dashboard (Client IDs) vs Auth API (webhooks) responsibilities clearly. - api-setup/getting-started.mdx — webhook setup now uses curl against /v1/webhook; "ensure webhook is enabled in the Dashboard" → use PUT /v1/webhook/:id. - api-setup/integration-tutorial.mdx — replaced the Dashboard webhook-creation walkthrough (and its two screenshots) with curl; test-event step uses POST /v1/webhook/test. - api-features/secure-payment-integration-guide.mdx — prereq updated. - use-cases/webhook-reconciliation.mdx — ngrok comment fixed. Also removed the now-orphaned Dashboard webhook UI screenshots (webhook-step-1.webp, webhook-step-2.webp).
Audited the docs against /Users/rodrigopavezi/Workspace/{request-api,
request-auth-api,request-dashboard,request-secure-payment} and corrected
every claim that no longer matches reality.
tools/dashboard.mdx
- Sign-in: Tron tab is feature-flagged (VITE_TRON_ENABLED), not
unconditionally co-equal — clarified
- Token table now matches the Dashboard's actual TOKENS_PER_CHAIN: Tron
exposes USDT only (not USDC), Arbitrum exposes USDT0 (not USDT). Added
a note that the underlying API supports a wider set
- Client ID dialog: only label + allowedDomains are collectable from the
UI; advanced fields (fees, operator, expiries, destination binding)
are API-only — corrected the misleading bullet list
- Pay tab: Dashboard UI today is single-recipient only on both EVM and
Tron. Removed the "many recipients" claim and dropped the EVM/Tron
matrix in favour of pointing to the API for batch
tools/secure-payments.mdx + use-cases/multi-chain-checkout.mdx
- Wallet list trimmed to the actual walletConfig in
components/wallet/ConnectWalletModal.tsx: MetaMask, Coinbase, Wallet-
Connect, Ledger, Phantom, Rabby. Dropped the misleading "any injected
EIP-1193 (Bitget, OKX, …)" claim — unrecognised IDs are filtered out
- Added a Smart-Accounts section to tools/secure-payments.mdx — the
Pimlico/Account-Abstraction integration was documented in api-features/
secure-payment-pages.mdx but missing from the tools tour
use-cases/quickstart.mdx
- Tron token table: USDT shown as native Dashboard option, USDC noted as
API-only (since the Dashboard UI doesn't expose USDC-on-Tron today)
- Arbitrum row clarified to show the USDT entry is USDT0
use-cases/no-code-payment-links.mdx
- Reworded "7 EVM chains or Tron" → "7 EVM chains plus Tron" and
qualified the token list (varies by chain)
api-features/recurring-payments.mdx
- Removed Gnosis (not supported), corrected list to match the actual
PayeeDestinationNetworkName enum: Ethereum, Arbitrum, Optimism, Base,
Polygon, BSC + Sepolia
- Added a note that recurring is EVM-only because it relies on EIP-2612
permit signatures (which Tron doesn't support)
api-features/client-id-management.mdx
- Response example now includes operatorWalletAddress,
defaultPreApprovalExpiry, defaultAuthorizationExpiry, payeeDestinationId
- Fixed Client ID prefix: cli_ (not ci_)
…cing pages Removed leaks of internal-only context that customers shouldn't need to care about, while keeping all the customer-visible behavior accurate. tools/dashboard.mdx - Sign-in section no longer references the build-time Tron feature flag. Customers see whatever's deployed at dashboard.request.network — the flag is operational, not product surface. - "auth-api" lowercase service-name reference → "Auth API" (proper noun) - EVM/Tron sign-in copy simplified — no more `personal_sign` / `tronWeb.trx.signMessageV2` jargon, just "sign the message when prompted" resources/supported-chains-and-currencies.mdx - Dropped the link into our internal request-api source tree (TOKENS_PER_CHAIN). Replaced with a customer-actionable note about using the addresses with the Auth API destination endpoint. release-notes/request-api.mdx - Removed the "see commit history in the request-api repository" line and the GitHub-issues helper link. The release-notes page itself is the canonical source for customers; the internal repo isn't.
…ages The Card href examples (/quickstart, /auth, /rate-limits) and Frame img examples (/images/dashboard.png, /images/analytics.png) were Mintlify template placeholders that didn't resolve in this site. Replaced with real, current pages and screenshots we ship: - /use-cases/quickstart - /api-reference/authentication - /api-reference/webhooks - /images/dashboard/home-with-destination.webp - /images/dashboard/generate-client-id.webp Net effect: AGENTS.md still demonstrates Mintlify components, but the examples now reference live URLs/images, and \`mintlify broken-links\` reports zero broken links across the whole site.
The SDK (Legacy) tab was already unlinked from docs.json nav by an earlier branch in this stack. Now removing the page itself plus the remaining inbound references that were still pointing at it: - Deleted sdk-legacy/overview.mdx and the directory. - use-cases/welcome.mdx: dropped the "SDK (Legacy)" card; the Resources card now stands alone. - resources/lifecycle-of-a-request.mdx: replaced the SDK reference with a pointer to the Quickstart. - glossary.mdx: redirected three "for details see SDK (Legacy)" links to the relevant API-features pages (payment-detection, crosschain-payments). mintlify broken-links: still zero.
Greptile SummaryThis PR fixes broken cross-references surfaced by the Mintlify broken-links checker, replaces Dashboard-UI webhook instructions with accurate Auth API curl flows, corrects several factual inaccuracies in the docs (token lists, supported networks, Client ID fields), and adds a set of captured screenshots that eliminate the majority of remaining image-path warnings.
Confidence Score: 4/5Safe to merge; changes are documentation-only with no runtime or contract impact. All changes are documentation and image assets. The factual corrections (token lists, network support, wallet config, Client ID prefix) are well-grounded in the PR description's source-audit rationale, and the USDT0 address has been verified against Arbiscan. One minor inconsistency exists in the integration tutorial's new env-file example, where the added placeholder label says API key but the variable holds a Client ID — a small potential reader confusion but nothing that breaks the integration. api-setup/integration-tutorial.mdx — the env-file placeholder in the new webhook section is inconsistently labeled compared to the credential setup section earlier in the same page. Important Files Changed
Sequence DiagramsequenceDiagram
participant Dev as Developer
participant Auth as auth.request.network
participant API as api.request.network
participant App as Your App
Note over Dev,Auth: Webhook Registration (corrected flow)
Dev->>Auth: "POST /v1/webhook<br/>x-client-id header + JSON url body"
Auth-->>Dev: 201 Created — id + one-time signing secret
Note over Dev,App: Developer stores signing secret in env file
Note over API,App: Live payment event
API->>App: "POST to registered URL<br/>HMAC-signed payload<br/>event: payment.confirmed"
App-->>API: 200 OK
Note over Dev,Auth: Webhook management
Dev->>Auth: GET /v1/webhook (list)
Dev->>Auth: PUT /v1/webhook/:id (toggle active)
Dev->>Auth: DELETE /v1/webhook/:id (remove)
Dev->>Auth: POST /v1/webhook/test — fire test delivery
Auth->>App: Test event (x-request-network-test: true header)
Reviews (1): Last reviewed commit: "docs(sdk-legacy): remove SDK (Legacy) se..." | Re-trigger Greptile |
| @@ -471,7 +470,16 @@ RN_API_URL=https://api.request.network/v2 | |||
| RN_WEBHOOK_SECRET=<THE_SECRET_WE_JUST_CREATED> | |||
| ``` | |||
There was a problem hiding this comment.
Placeholder label contradicts the variable's purpose
The new .env block uses <YOUR_API_KEY> as the placeholder for RN_API_KEY, but earlier in the tutorial (the "Get your API credentials" section) the same variable is defined with <insert-your-client-id> and the prose explicitly says "The Client ID is your API credential". A reader who reaches the webhook section first, or skims it in isolation, will see a curl command that sends $RN_API_KEY via the x-client-id header immediately followed by a .env snippet calling it an "API key" — the two names conflict, making it ambiguous whether to paste a Client ID or a separate API key. Change <YOUR_API_KEY> to <YOUR_CLIENT_ID> for consistency.
| // .env | |
| RN_API_KEY=<YOUR_CLIENT_ID> | |
| RN_API_URL=https://api.request.network/v2 | |
| RN_WEBHOOK_SECRET=<THE_SECRET_WE_JUST_CREATED> |

docs(verify): fix broken cross-refs surfaced by mintlify broken-links
internal links with the canonical https://api.request.network/open-api/
group anchors. Those internal anchors don't exist on this site (they
belonged to a tag-driven generator that's no longer wired up).
Card to /api-reference/secure-payments which is the actual page.
Remaining mintlify broken-links output:
— these are the screenshots that Phase D's capture pipeline will produce
(see scripts/capture-screenshots.ts). Expected and documented.
/images/*.png paths — AGENTS.md is internal AI-agent guidance, not
user-facing docs. Out of scope for this revamp.
docs(images): capture Dashboard + Secure Payment screenshots
Captured 8 screenshots from staging via the new screenshots Playwright
project in request-e2e-tests (which reuses the Synpress + DashboardHelper
setup).
Dashboard (8):
(captured from a fresh Chromium context to defeat the fixture's
pre-authenticated state)
payment request flows
Secure Payment (1):
WalletConnect)
Manual / not yet captured (logged by the spec):
client-id-details — require a fresh wallet without an existing
destination, or specific dialogs mid-flow
payment-options-crosschain, advanced-view, payment-success — require
a connected payer wallet (Buyer account) + a paid request
The mintlify broken-links report should drop from 24 image-related
warnings to ~16 after this commit.
docs(images): capture 6 more screenshots — dialogs + payer-side payment options
Extended the screenshots Playwright project to capture wallet-gated and
mid-flow shots that the first pass marked MANUAL.
Dashboard (4):
(captured by deactivating the destination then restoring it)
Secure Payment (2):
and "Choose this currency" CTA (captured after payer wallet connects via
Synpress)
showing recipient, reference, amount breakdown
Mintlify broken-links: 17 → 11 (5 are AGENTS.md, out of scope).
Still deferred (3 shots, intentionally MANUAL):
TronLink browser extension
chain different from the destination
docs(images): capture payment-success via on-chain Sepolia payment
Extended the screenshots Playwright project with an actual end-to-end
on-chain payment flow (Sepolia, 0.01 fUSDC, Buyer wallet). The capture
runs through PaymentHelper.connectWallet → confirmAddressVerification →
approveTokenIfNeeded → confirmPayment → waitForPaymentSuccess and snaps
the success screen.
Result: payment-success.webp shows the green checkmark, $0.01 USD paid,
recipient/reference/amount table, "via Token Transfer FUSDC on Sepolia",
the on-chain reference hash, and "View on Etherscan" / "View on
BlockScout" buttons.
Mintlify broken-links: 11 → 9 (5 AGENTS.md out-of-scope + 4 references
to the 2 deferred shots).
Still deferred (2 shots, intentionally MANUAL):
test browser + a Tron-signed-in dashboard session + a Tron destination
hold balance on a chain different from the destination. Sepolia is the
only supported testnet so cross-chain on testnet isn't available; this
would need a mainnet setup.
docs(content): replace deferred shot refs with text for tron-wallet + crosschain
Drop the four blocks pointing at uncaptured screenshots and replace
them with descriptive text. The two shots — connect-wallet-tron and
payment-options-crosschain — require setups beyond the staging-wallet
auto-capture flow (TronLink + Tron-signed-in session, multi-chain payer
balance) and are deferred indefinitely.
Touched:
describes the banner-text difference instead of showing a separate shot.
Mintlify broken-links: 9 → 5 (all 5 remaining are AGENTS.md, out of scope).
docs(webhooks): document Auth API as the only path; drop Dashboard UI claims
There is no Dashboard UI for webhook CRUD. Webhooks are managed
programmatically via the Auth API (POST/GET/PUT/DELETE /v1/webhook with
the x-client-id header) and tested via POST /v1/webhook/test. The earlier
Phase A Portal sweep mistakenly retargeted these claims at the Dashboard
instead of the auth-api endpoints — fix that across every page that
mentions webhook setup.
Touched:
Testing" sections with the actual create/manage/test curl flows; cards
updated; troubleshooting tips reference auth-api endpoints.
at the auth-api webhook endpoints instead of the Dashboard.
vs Auth API (webhooks) responsibilities clearly.
/v1/webhook; "ensure webhook is enabled in the Dashboard" → use
PUT /v1/webhook/:id.
webhook-creation walkthrough (and its two screenshots) with curl;
test-event step uses POST /v1/webhook/test.
Also removed the now-orphaned Dashboard webhook UI screenshots
(webhook-step-1.webp, webhook-step-2.webp).
docs(audit): align with current source in all four repos
Audited the docs against /Users/rodrigopavezi/Workspace/{request-api,
request-auth-api,request-dashboard,request-secure-payment} and corrected
every claim that no longer matches reality.
tools/dashboard.mdx
unconditionally co-equal — clarified
exposes USDT only (not USDC), Arbitrum exposes USDT0 (not USDT). Added
a note that the underlying API supports a wider set
UI; advanced fields (fees, operator, expiries, destination binding)
are API-only — corrected the misleading bullet list
Tron. Removed the "many recipients" claim and dropped the EVM/Tron
matrix in favour of pointing to the API for batch
tools/secure-payments.mdx + use-cases/multi-chain-checkout.mdx
components/wallet/ConnectWalletModal.tsx: MetaMask, Coinbase, Wallet-
Connect, Ledger, Phantom, Rabby. Dropped the misleading "any injected
EIP-1193 (Bitget, OKX, …)" claim — unrecognised IDs are filtered out
Pimlico/Account-Abstraction integration was documented in api-features/
secure-payment-pages.mdx but missing from the tools tour
use-cases/quickstart.mdx
API-only (since the Dashboard UI doesn't expose USDC-on-Tron today)
use-cases/no-code-payment-links.mdx
qualified the token list (varies by chain)
api-features/recurring-payments.mdx
PayeeDestinationNetworkName enum: Ethereum, Arbitrum, Optimism, Base,
Polygon, BSC + Sepolia
permit signatures (which Tron doesn't support)
api-features/client-id-management.mdx
defaultPreApprovalExpiry, defaultAuthorizationExpiry, payeeDestinationId
docs(content): scrub internal implementation details from customer-facing pages
Removed leaks of internal-only context that customers shouldn't need to
care about, while keeping all the customer-visible behavior accurate.
tools/dashboard.mdx
Customers see whatever's deployed at dashboard.request.network — the
flag is operational, not product surface.
personal_sign/tronWeb.trx.signMessageV2jargon, just "sign the message whenprompted"
resources/supported-chains-and-currencies.mdx
(TOKENS_PER_CHAIN). Replaced with a customer-actionable note about
using the addresses with the Auth API destination endpoint.
release-notes/request-api.mdx
and the GitHub-issues helper link. The release-notes page itself is
the canonical source for customers; the internal repo isn't.
docs(agents): point AGENTS.md component examples at real pages and images
The Card href examples (/quickstart, /auth, /rate-limits) and Frame img
examples (/images/dashboard.png, /images/analytics.png) were Mintlify
template placeholders that didn't resolve in this site.
Replaced with real, current pages and screenshots we ship:
Net effect: AGENTS.md still demonstrates Mintlify components, but the
examples now reference live URLs/images, and `mintlify broken-links`
reports zero broken links across the whole site.
docs(sdk-legacy): remove SDK (Legacy) section entirely
The SDK (Legacy) tab was already unlinked from docs.json nav by an
earlier branch in this stack. Now removing the page itself plus the
remaining inbound references that were still pointing at it:
card now stands alone.
a pointer to the Quickstart.
to the relevant API-features pages (payment-detection,
crosschain-payments).
mintlify broken-links: still zero.