docs: update SDK quickstart and request update guide

[AllenAJ]

• Added an Advocates Welcome Kit to help onboard new community members.
• Enhanced the "Updating a Request" guide with functional code examples.
• Updated the Node.js Quickstart with Viem integration and Request update logic.
• Updated FAQ and navigation to include advocate resources.

---

Maintainer Changes

The following modifications were made during review:

• Removed Advocates Welcome Kit - Program details will be maintained elsewhere; technical docs will focus on SDK/API usage
• Fixed viem tab in Node.js quickstart - Replaced non-functional code with note explaining viem-to-ethers patterns are for browser wallets
• Restored addStakeholders row in updating-a-request.md table
• Fixed Discord link to use consistent format (request.network/discord)
• Applied *Identity naming convention - Changed payerAddress/signerAddress/payeeAddress to payerIdentity/signerIdentity/payeeIdentity in IIdentity object examples. This aligns with the SDK's semantic distinction: *Identity for signing/access control, *Address for payment routing.
• Fixed repo URL typo - Corrected quickstart-node.js to quickstart-node-js

Summary by CodeRabbit

• Documentation
  • Enhanced the "How to update a request" guide with comprehensive code examples, detailed action references, and clarified Node.js implementation guidance for signature providers and request confirmation handling.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

Two documentation files are updated to enhance Request Network SDK guides: the quickstart guide now includes a section on updating requests with code examples, and the dedicated updating-requests guide is restructured with a new actions summary table and comprehensive examples demonstrating initialization and request operations.

Changes

Cohort / File(s)	Summary
Request Update Documentation docs/advanced/request-network-sdk/get-started/quickstart-node.js.md, docs/advanced/request-network-sdk/sdk-guides/request-client/updating-a-request.md	Enhanced documentation for updating requests: added dedicated "Update a request" section in quickstart with code example and signatureProvider requirements; restructured updating-a-request guide with Markdown actions table, initialized client examples, and operation demonstrations (accept, cancel, increase/reduce expected amount)

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately summarizes the main changes: updates to the SDK quickstart guide and the request update guide documentation.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[MantisClone]

Hello @AllenAJ, thank you for submitting your first pull request to the docs.request.network repository. We value your contribution and encourage you to review our contribution guidelines to ensure your submission meets our standards. Please note that every merged PR is automatically enrolled in our Best PR Initiative, offering a chance to win $500 each quarter. Our team is available via GitHub Discussions or Discord if you have any questions. Welcome aboard!

[MantisClone]

Thank you for your submission! As you prepare for the review process, please ensure that your PR title, description, and any linked issues fully comply with our contribution guidelines. A clear explanation of your changes and their context will help expedite the review process. Every merged PR is automatically entered into our Best PR Initiative, offering a chance to win $500 every quarter. We appreciate your attention to detail and look forward to reviewing your contribution!

[greptile-apps]

Greptile Overview

Greptile Summary

Enhanced SDK documentation by adding functional request update examples to both the Node.js quickstart and the detailed updating guide. The viem tab was clarified to direct Node.js users to ethers v5 instead of the browser-specific adapter patterns.

• Node.js Quickstart: Added "Update a request" section with accept example
• Updating a Request Guide: Expanded from stub to comprehensive guide with all update operations (accept, cancel, increase/decrease amount)
• Viem Tab: Replaced placeholder with clear explanation about when to use ethers v5 vs viem adapters

Issues Found:

• Multiple undefined variables (payerAddress, payeeAddress, signerAddress, epkSignatureProvider) in code examples will prevent copy-paste execution
• Examples need variable definitions or clearer placeholder comments

Confidence Score: 3/5

• Safe to merge with minor fixes - documentation improvements are valuable but examples need variable definitions
• The PR successfully adds much-needed documentation for request updates, but the code examples contain undefined variables that will confuse users trying to run them. These are documentation issues, not breaking changes to production code.
• Pay attention to updating-a-request.md - it has the most undefined variables that need fixing

Important Files Changed

Filename	Overview
docs/advanced/request-network-sdk/get-started/quickstart-node.js.md	Added request update section with example code; viem tab clarified. One undefined variable (payerAddress) needs fixing.
docs/advanced/request-network-sdk/sdk-guides/request-client/updating-a-request.md	Expanded from stub to full guide with examples for all update operations. Multiple undefined variables prevent code from running as-is.

Sequence Diagram

sequenceDiagram
    participant User
    participant App
    participant RequestClient
    participant SignatureProvider
    participant RequestNode
    participant IPFS
    
    Note over User,IPFS: Update Request Flow
    
    User->>App: Initiate request update (e.g., accept, cancel)
    App->>RequestClient: fromRequestId('REQUEST_ID')
    RequestClient->>RequestNode: Fetch request data
    RequestNode-->>RequestClient: Return request data
    
    App->>RequestClient: request.accept(identity) / cancel() / etc.
    RequestClient->>SignatureProvider: Sign update transaction
    SignatureProvider-->>RequestClient: Return signature
    
    RequestClient->>IPFS: Store updated request data
    IPFS-->>RequestClient: Return IPFS CID
    
    RequestClient->>RequestNode: Submit update with CID
    RequestNode-->>RequestClient: Acknowledge update
    
    App->>RequestClient: request.waitForConfirmation()
    RequestClient->>RequestNode: Poll for confirmation
    RequestNode-->>RequestClient: Confirmed
    
    RequestClient-->>App: Updated request data
    App-->>User: Update successful

Loading

[greptile-apps]

Additional Comments (4)

1. docs/advanced/request-network-sdk/get-started/quickstart-node.js.md, line 197-200 (link)

   logic: Uses mainnet chain but the rest of the quickstart uses Sepolia. Should be consistent.

   _{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!}

2. docs/advanced/request-network-sdk/get-started/quickstart-node.js.md, line 205-207 (link)

   logic: Chain should match Sepolia for consistency with the rest of the quickstart.

   _{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!}

3. docs/advanced/request-network-sdk/get-started/quickstart-node.js.md, line 211-213 (link)

   logic: Should use sepolia instead of mainnet for consistency.

   _{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!}

4. docs/advanced/request-network-sdk/get-started/quickstart-node.js.md, line 210-214 (link)

   logic: The viem WalletClient.transport is not directly compatible with ethers Web3Provider. Check the implementation in quickstart-browser.md:274-284 which properly extracts account and chain info from the walletClient before creating the provider.

_{5 files reviewed, 4 comments}

_{Edit Code Review Agent Settings | Greptile}

[coderabbitai]

Actionable comments posted: 1

📜 Review details

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between c6a93ce and 7c6248a.

📒 Files selected for processing (5)

• docs/SUMMARY.md
• docs/advanced/request-network-sdk/get-started/quickstart-node.js.md
• docs/advanced/request-network-sdk/sdk-guides/request-client/updating-a-request.md
• docs/faq.md
• docs/general/advocates-welcome-kit.md

🧰 Additional context used

📓 Path-based instructions (1)

**/*

⚙️ CodeRabbit configuration file

**/*: - Only comment on issues that would block merging — ignore minor or stylistic concerns.

• Restrict feedback to errors, security risks, or functionality-breaking problems.
• Do not post comments on code style, formatting, or non-critical improvements.
• Keep reviews short: flag only issues that make the PR unsafe to merge.
• Limit review comments to 3–5 items maximum, unless additional blockers exist.
• Group similar issues into a single comment instead of posting multiple notes.
• Skip repetition — if a pattern repeats, mention it once at a summary level only.
• Do not add general suggestions; focus strictly on merge-blocking concerns.
• If there are no critical problems, respond with minimal approval (e.g., 'Looks good'). Do not add additional review.
• Avoid line-by-line commentary unless it highlights a critical bug or security hole.
• Highlight only issues that could cause runtime errors, data loss, or severe maintainability issues.
• Ignore minor optimization opportunities — focus solely on correctness and safety.
• Provide a top-level summary of critical blockers rather than detailed per-line notes.
• Comment only when the issue must be resolved before merge — otherwise, remain silent.
• When in doubt, err on the side of fewer comments — brevity and blocking issues only.
• Avoid posting any refactoring issues

Files:

• docs/advanced/request-network-sdk/get-started/quickstart-node.js.md
• docs/general/advocates-welcome-kit.md
• docs/SUMMARY.md
• docs/faq.md
• docs/advanced/request-network-sdk/sdk-guides/request-client/updating-a-request.md

🪛 LanguageTool

docs/general/advocates-welcome-kit.md

[style] ~20-~20: The noun “invitation” is usually used instead of ‘invite’ in formal writing.
Context: ...ols * Notion: You will receive an invite to our private Advocates workspace. * ...

(AN_INVITE)

🪛 markdownlint-cli2 (0.18.1)

docs/general/advocates-welcome-kit.md

47-47: Bare URL used

(MD034, no-bare-urls)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)

• GitHub Check: Greptile Review

[MantisClone]

Regarding the Greptile feedback about addStakeholders being removed from the updating-a-request.md table - please keep this action in the Summary of Actions table. It's a valid update action for encrypted requests:

| **addStakeholders** | Grant 1 or more third parties access to view an encrypted request | Payee, Payer, or Third Party |

We'll add this back in a follow-up commit.

[MantisClone]

I've pushed a fix commit (087dc01) to your branch that:

1. Replaces the viem tab in quickstart-node.js.md with a note explaining that viem-to-ethers patterns are for browser wallets, and pointing users to the ethers v5 approach
2. Restores the addStakeholders row in the updating-a-request.md table

The rest of the PR looks good - the Advocates Welcome Kit and the Update a Request examples are helpful additions. Thanks for the contribution!

[MantisClone]

@greptileai review

[greptile-apps]

_{2 files reviewed, 6 comments}

_{Edit Code Review Agent Settings | Greptile}

[MantisClone]

Fixed. Changed to *Identity to follow the SDK's naming convention: *Identity for signing/access control contexts, *Address for payment routing contexts.

This aligns with the established pattern in the SDK API reference (signerIdentity is used in accept.md, cancel.md, increaseexpectedamountrequest.md, reduceexpectedamountrequest.md) and the quickstart docs (payerIdentity, payeeIdentity).

[MantisClone]

Congratulations, your pull request has been merged! Thank you for your valuable contribution to Request Network. As a reminder, every merged PR is automatically entered into our Best PR Initiative, offering a quarterly prize of $500. Your work significantly supports our project's growth, and we encourage you to continue engaging with our community. Additionally, if you want to build or add crypto payments and invoicing features, explore how our API can reduce deployment time from months to hours while offering advanced features. Book a call with our expert to learn more and fast-track your development.