docs(nav): restructure navigation, remove legacy pages, retire Portal#88
docs(nav): restructure navigation, remove legacy pages, retire Portal#88rodrigopavezi wants to merge 1 commit intodocs/fix-remaining-issuesfrom
Conversation
Revamp the docs scaffolding to align with the current product surface (Dashboard, Secure Payment, v2 API). This is the structural pass; new use-case pages and content refresh land in subsequent branches. Removed (legacy): - EasyInvoice demo page, release notes, screenshots, source-code references - RequestScan resource page (URLs in payload examples preserved for now) - Migrate-to-v2 guide and v1-to-v2 comparison link - request-network-api/ directory (api-portal, create-and-pay-requests) - Outdated use-case pages: payroll, subscriptions, payouts, payment-detection, checkout, invoicing, payment-processing-demo Portal sweep: - Replaced "Get your API Key"/portal.request.network navbar button with "Open Dashboard"/dashboard.request.network - Replaced Portal footer link with Dashboard + Pay - Substituted Portal text/URLs with Dashboard equivalents across authentication, webhooks, getting-started, integration-tutorial, webhooks-events, secure-payment-integration-guide, crypto-to-fiat-payments NEAR: - Unlinked from nav; kept the file with a top-of-page note that NEAR support is paused. Page preserved for reference. Cross-refs: - Rewired broken links from deleted use-case pages to the upcoming no-code-payment-links / programmatic-payment-links / multi-chain-checkout / batch-payouts / webhook-reconciliation pages so Phase B doesn't have to retouch every API-features file
Greptile SummaryThis PR is a structural documentation overhaul that retires the Portal product in favour of the Dashboard, removes legacy pages (EasyInvoice, RequestScan, migrate-to-v2, outdated use-cases), and rewires internal cross-references to point at upcoming Phase B use-case pages.
Confidence Score: 4/5Safe to merge with awareness that several cross-reference links will produce 404s until Phase B use-case pages land. The Portal-to-Dashboard renaming is thorough and consistent across nearly all files. Two defects exist: forward-pointing links to five Phase B use-case pages that don't exist yet will 404 on merge, and a stale numbered list in the getting-started guide still describes old Portal UI steps rather than the new Client ID flow. api-setup/getting-started.mdx (stale Portal UI steps in the API Key Generation section) and any file that gained a card linking to a Phase B use-case page: resources/community.mdx, api-features/conversion-payments.mdx, api-features/create-requests.mdx, api-features/standard-payments.mdx, api-features/partial-payments.mdx, api-features/batch-payments.mdx, api-reference/webhooks.mdx. Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[User visits docs] --> B{Which tab?}
B -->|Use Cases| C[use-cases/welcome]
C --> D[Card: /use-cases/no-code-payment-links - 404]
B -->|API| F[api-setup/getting-started]
F --> G[API Key Generation section - stale Portal UI steps]
B -->|API Features| H[api-features pages]
H --> I[Used-In cards to /use-cases/no-code-payment-links - 404]
H --> J[Used-In cards to /use-cases/programmatic-payment-links - 404]
H --> K[Used-In cards to /use-cases/batch-payouts - 404]
B -->|API Reference| L[api-reference/webhooks]
L --> M[Card to /use-cases/webhook-reconciliation - 404]
Reviews (1): Last reviewed commit: "docs(nav): restructure navigation, remov..." | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| @@ -326,7 +326,7 @@ Request Network is committed to fostering a welcoming, inclusive, and respectful | |||
|
|
|||
There was a problem hiding this comment.
Multiple files updated in this PR now point to use-cases pages that don't exist in the repository: /use-cases/no-code-payment-links, /use-cases/programmatic-payment-links, /use-cases/multi-chain-checkout, /use-cases/batch-payouts, and /use-cases/webhook-reconciliation. Confirmed with a glob — only use-cases/welcome.mdx exists after this PR merges. Any user who clicks these links will hit a 404 immediately. The same pattern appears in api-features/conversion-payments.mdx, api-features/create-requests.mdx, api-features/partial-payments.mdx, api-features/standard-payments.mdx, api-features/batch-payments.mdx, and api-reference/webhooks.mdx.
| ### API Key Generation | ||
|
|
||
| 1. Log in to [Request Portal](https://portal.request.network) | ||
| 1. Log in to [Request Dashboard](https://dashboard.request.network) | ||
| 2. Navigate to "API Keys" section | ||
| 3. Click "Create new key" | ||
| 4. Copy and securely store the key |
There was a problem hiding this comment.
The step title was updated to "Get API Keys / Generate your Client ID from the Dashboard" in the Quick Setup section, but this lower section still describes the old Portal flow — "API Keys" section and "Create new key" — which no longer matches the Dashboard's Client ID workflow. This will confuse users who follow this guide.
| ### API Key Generation | |
| 1. Log in to [Request Portal](https://portal.request.network) | |
| 1. Log in to [Request Dashboard](https://dashboard.request.network) | |
| 2. Navigate to "API Keys" section | |
| 3. Click "Create new key" | |
| 4. Copy and securely store the key | |
| ### Client ID Generation | |
| 1. Log in to [Request Dashboard](https://dashboard.request.network) | |
| 2. Navigate to the **Client IDs** section | |
| 3. Click **Create new Client ID** | |
| 4. Copy and securely store the Client ID |
1 participant
Revamp the docs scaffolding to align with the current product surface
(Dashboard, Secure Payment, v2 API). This is the structural pass; new
use-case pages and content refresh land in subsequent branches.
Removed (legacy):
payment-detection, checkout, invoicing, payment-processing-demo
Portal sweep:
"Open Dashboard"/dashboard.request.network
authentication, webhooks, getting-started, integration-tutorial,
webhooks-events, secure-payment-integration-guide, crypto-to-fiat-payments
NEAR:
support is paused. Page preserved for reference.
Cross-refs:
no-code-payment-links / programmatic-payment-links / multi-chain-checkout
/ batch-payouts / webhook-reconciliation pages so Phase B doesn't have
to retouch every API-features file