Summary
The frontend dashboard (per README: 'soon, a dashboard for viewing balances, transaction history, and exporting') needs backend endpoints — but WhatsApp is the identity system, so the web dashboard needs its own auth story.
Description
Design an auth flow that ties a web session back to a WhatsApp-verified phone number — e.g. the bot sends a one-time login link/code on request, exchanged for a short-lived session token, since there's no password/OAuth identity today.
Design the API surface: GET /api/wallet (address, contract ID, export status), GET /api/balances, GET /api/transactions (paginated, backed by the transactions table).
Specify authorization: a session can only read its own phone number's data.
This issue is API design + the auth flow; implementing the endpoints and the frontend consuming them are separate, dependent issues.
Deliverables
- Auth flow design (WhatsApp-initiated session)
- API surface spec for wallet/balances/transactions endpoints
- Authorization model documented
Dependencies
Summary
The frontend dashboard (per README: 'soon, a dashboard for viewing balances, transaction history, and exporting') needs backend endpoints — but WhatsApp is the identity system, so the web dashboard needs its own auth story.
Description
Design an auth flow that ties a web session back to a WhatsApp-verified phone number — e.g. the bot sends a one-time login link/code on request, exchanged for a short-lived session token, since there's no password/OAuth identity today.
Design the API surface:
GET /api/wallet(address, contract ID, export status),GET /api/balances,GET /api/transactions(paginated, backed by thetransactionstable).Specify authorization: a session can only read its own phone number's data.
This issue is API design + the auth flow; implementing the endpoints and the frontend consuming them are separate, dependent issues.
Deliverables
Dependencies