docs: add missing feature documentation for recent API changes#86
docs: add missing feature documentation for recent API changes#86rodrigopavezi wants to merge 4 commits intodocs/fix-implementation-discrepanciesfrom
Conversation
Batch 1 (Critical): Fix documentation that describes removed APIs. crosschain-payments.mdx: - Remove old payment-intent signing flow (Steps 4-5) - Document new direct calldata execution model via GET /pay - Add transactions[] array response format with metadata fields - Replace EIP-712 signing example with viem sendTransaction example - Add breaking change warning banner - Document chain/token query parameters for route selection secure-payments.mdx: - Split GET /:token into metadata-only endpoint - Add new GET /:token/pay endpoint for executable calldata - Add new POST /:token/intent endpoint for crosschain tracking - Add GET /v2/secure-payments lookup-by-requestId endpoint - Document paymentOptions crosschain balance response - Document destination field with ERC-7828 info - Update POST to show destinationId format - Add per-endpoint auth table
… docs Batch 2 (High): New feature documentation for undocumented features. - Create payee-destinations.mdx: ERC-7828 interop addresses, CRUD endpoints, integration with secure payments and client IDs - Create client-id-management.mdx: frontend vs backend client IDs, domain whitelisting, fee config, destination binding, orchestrator pattern - Update secure-payment-pages.mdx: add crosschain support section and smart account payments section (Alchemy Account Kit, gas-sponsored UserOps) - Update docs.json: add Payee Destinations group, Client ID Management page in API Setup, wallet-authentication in API Reference, Payouts group, and Advanced group for commerce payments
Batch 3 (Medium): Additional feature documentation. - Create wallet-authentication.mdx: SIWE challenge/verify flow for EVM and Tron wallets, session management, email/password auth - Create payouts.mdx: single, batch, and recurring payout endpoints with examples and links to recurring payments docs - Update secure-payment-integration-guide.mdx: add destinationId usage section, crosschain payments on secure pages section, fix secure payment URL from secure.request.network to pay.request.network
Batch 4 (Lower priority): Feature-flagged and enhancement docs. - Create commerce-payments.mdx: authorize-capture-void escrow flow with preview/beta warning, lifecycle diagram, endpoint overview - Update query-payments.mdx: replace bullet lists with full ParamField documentation for all query parameters, add response schema with example JSON and field reference table
Greptile SummaryThis PR adds documentation for a significant set of new and redesigned API features across the Request Network platform, covering crosschain payments, secure payments, payee destinations, client ID management, wallet authentication, payouts, and commerce payments (preview). Key changes:
Confidence Score: 4/5Two P1 issues should be resolved before merge: the undefined The bulk of the documentation is accurate, well-structured, and a clear improvement over the previous state. Two P1 findings hold the score below 5: (1) the viem code snippet references an undeclared
Important Files Changed
Sequence DiagramsequenceDiagram
participant Dev as Developer/Frontend
participant AuthAPI as auth.request.network
participant API as api.request.network
participant Chain as Blockchain
Note over Dev,AuthAPI: Wallet Authentication (SIWE)
Dev->>AuthAPI: POST /v1/auth/wallet/challenge
AuthAPI-->>Dev: challengeId + message
Dev->>Dev: wallet.sign(message)
Dev->>AuthAPI: POST /v1/auth/wallet/verify
AuthAPI-->>Dev: session cookie
Note over Dev,API: Payee Destination Setup
Dev->>AuthAPI: POST /v1/payee-destination
AuthAPI-->>Dev: destinationId (ERC-7828)
Note over Dev,API: Secure Payment Creation
Dev->>API: POST /v2/secure-payments
API-->>Dev: token + securePaymentUrl
Note over Dev,Chain: Crosschain Payment Execution
Dev->>API: GET /v2/secure-payments/:token
API-->>Dev: paymentOptions per chain
Dev->>API: GET /v2/secure-payments/:token/pay
API-->>Dev: transactions array with calldata
Dev->>Chain: sendTransaction approval
Dev->>Chain: sendTransaction bridge/payment
Dev->>API: POST /v2/secure-payments/:token/intent
API-->>Dev: intentId recorded
Chain-->>API: bridge confirmation webhook
|
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| value: BigInt(approvalTx.value || 0), | ||
| }); | ||
| // Wait for confirmation before proceeding | ||
| await publicClient.waitForTransactionReceipt({ hash: approvalHash }); |
There was a problem hiding this comment.
publicClient is undefined in the code example
publicClient.waitForTransactionReceipt(...) is called on line 179 but publicClient is never imported or instantiated. Only walletClient is created in this snippet. In viem, reading/waiting for receipts requires a separate createPublicClient call.
This will throw a ReferenceError: publicClient is not defined for any developer who copies and runs the example.
The proper fix is to also import and create a publicClient:
import { createWalletClient, createPublicClient, custom, http } from "viem";
import { arbitrum } from "viem/chains";
const walletClient = createWalletClient({
chain: arbitrum,
transport: custom(window.ethereum),
});
const publicClient = createPublicClient({
chain: arbitrum,
transport: http(),
});| "status": "pending", | ||
| "paymentType": "single", | ||
| "createdAt": "2026-03-15T10:00:00.000Z", | ||
| "expiresAt": "2026-03-15T10:15:00.000Z" |
There was a problem hiding this comment.
expiresAt in example contradicts the documented default expiry
The response example shows "expiresAt": "2026-03-15T10:15:00.000Z" — only 15 minutes after createdAt. But secure-payment-integration-guide.mdx states: "Secure payment links expire after one week by default."
The example value should either reflect the actual default (7 days after creation) or include a note explaining that expiresAt can be customised.
| "expiresAt": "2026-03-15T10:15:00.000Z" | |
| "expiresAt": "2026-03-22T10:00:00.000Z" |
|
|
||
| ## Recurring Payouts | ||
|
|
||
| Create automated payment schedules where the payer authorizes a series of payments with a single ERC-712 signature. |
There was a problem hiding this comment.
ERC-712 should be EIP-712
The correct name for the typed structured data signing standard is EIP-712 (Ethereum Improvement Proposal 712). "ERC-712" is not the official designation and may cause confusion for developers searching for documentation or verifying the standard.
| Create automated payment schedules where the payer authorizes a series of payments with a single ERC-712 signature. | |
| Create automated payment schedules where the payer authorizes a series of payments with a single EIP-712 signature. |
1 participant
Summary
Adds documentation for features implemented across
request-api,request-auth-api,request-dashboard, andrequest-secure-paymentthat had zero or incorrect documentation.Batch 1 — Critical (fix incorrect docs)
transactions[]array/:token) and calldata (/:token/pay). Add crosschain support, intent recording, and lookup endpointsBatch 2 — High (new feature docs)
Batch 3 — Medium (additional features)
Batch 4 — Lower (feature-flagged/enhancement)
Navigation updates (docs.json)
Test plan
npx mintlify devto verify all pages render