Sunset Portal and migrate remaining functionality to Dashboard

[MantisClone]

Problem

Portal (email/password auth) and Dashboard (SIWE/wallet auth) are two separate systems for managing the same functionality — API keys, client IDs, and webhooks. Maintaining both creates confusion for users and duplicated effort for the team. Portal's UX is not sellable as a product.

Proposed Solution

Once the following prerequisites are complete, sunset Portal entirely:

1. Dashboard has API key (client ID) management UI — https://github.com/RequestNetwork/request-dashboard/issues/40
2. Webhooks can be created programmatically via client ID — https://github.com/RequestNetwork/request-auth-api/issues/42

After these ship:

• Deprecate Portal with a sunset notice and timeline
• Redirect Portal users to Dashboard
• Remove Portal deployment infrastructure

Migration

No automatic migration path. Existing Portal users will need to:

1. Sign in with their wallet on Dashboard
2. Create new client IDs
3. Set up new webhooks (programmatically via API)
4. Update their integrations to use the new client IDs

API Key Auth Mechanism

The legacy API key auth mechanism (separate from client IDs) will likely be deprecated in favor of client IDs, but this needs deeper analysis before removal since some existing integrations may depend on API key auth. Do not remove API key support until a full audit of active API key usage is completed.

Considerations

• Cryptos/Interaction is the most notable existing Portal user. They are creating requests without payments (300/month, no payments going through) — their usage pattern is unusual and may not need special accommodation.
• Portal is not costing money (hosted, not paid SaaS). No urgency to remove infrastructure — focus on feature parity first.
• Related: https://github.com/RequestNetwork/request-dashboard/issues/37 (immediate fix — remove hardcoded client ID)
• Based on Feb 25-26 Tech Daily discussions.

[MantisClone]

Priority escalation: Portal/Dashboard session interference is hitting integrators now

Moving this to Sprint 50 / Sprint Backlog / High P2.

What's happening

Portal and Dashboard share the same cookie domain (auth.request.network). Stale Portal session cookies conflict with Dashboard SIWE auth, producing contradictory errors:

• GET /v1/payee-destination → 403 "Wallet session required"
• POST /v1/auth/wallet/challenge → 400 "Already logged in"

Workaround: delete cookies. But integrators shouldn't have to know that.

Who's been affected

• An external integrator hit this during onboarding (Mar 4-5). Got the 403/400 contradiction and an uncaught error on the Portal UI. @tristanwallaert-netizen walked them through clearing cookies.
• Another integrator avoided it by using wallet auth from the start. But they were one Portal login away from the same broken state.

Why this matters now

We decided in Sprint 50 planning to accelerate Portal deprecation rather than fix the session interference directly. That's the right call — but it means this issue is the forcing function. The longer Portal stays up alongside Dashboard, the more integrators will hit this during onboarding, which is the worst possible time for friction.

Tracking

Filed https://github.com/RequestNetwork/request-auth-api/issues/52 to document the specific cookie conflict bug. It will be resolved by Portal sunset.

Note: https://github.com/RequestNetwork/request-auth-api/issues/49 (disable secure payment creation for email/password platforms) is related but separate — it addresses disconnected platform/destination associations, not the cookie conflict.