Feature request: implement API access token management

[Kingvic300]

Description

frontend/src/features/ProfilePage.tsx lists an "API access tokens" account link that only shows a toast:

const ACCOUNT_LINKS = [
    ...
    { id: 'tokens', icon: Key, label: 'API access tokens', toast: 'Token management not implemented' },
    ...
] as const;

There is no concept of API tokens (as distinct from login JWTs) anywhere in the backend — no model, no issuance/revocation endpoints.

Verified

Confirmed via direct read of frontend/src/features/ProfilePage.tsx lines 33-37 and the ACCOUNT_LINKS.map render block (~line 555).

Suggested fix

If programmatic/API access is a real product goal (relevant given the CLI already exists and currently needs a full login JWT — see Txio-labs/txio#29), add a proper API-token model (separate from session JWTs, scoped, revocable) with issue/list/revoke endpoints, then wire this link up.

Note

One of several account-link stubs on this page (Billing, API tokens, Notifications), filed separately since each represents a distinct feature area.

[midenotch]

I've reviewed the task and have a clear implementation plan. Looking forward to contributing with a quality PR.

[MissHarah]

I have gone through the issue and i can get it done. please assign it to me

[bukeeastrey]

Hi! I'd like to work on this issue if it's available. I'll first review the existing authentication and API architecture to ensure the implementation fits the current design, then implement the API access token management flow with the necessary UI, backend changes, and tests. Please assign it to me if no one is working on it. Thanks!

[Bigmehelen]

I would like to work on this issue please assign me to this issue

[grantfox-oss]

🦊 GrantFox — @Bigmehelen has been assigned to this issue as part of the Official Campaign | FWC26 campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes Txio-labs/txio-backend#3)
2. Your PR will be reviewed by the Txio-labs maintainers

Good luck! Track your progress on GrantFox.

[grantfox-oss]

🎉 This issue has been marked as completed on GrantFox as part of the Official Campaign | FWC26 campaign!

@Bigmehelen's PR Txio-labs/txio#184 was approved and merged by @Kingvic300.

🏆 @Bigmehelen: You earned 35 FoxPoints for this contribution! Your current tier: Explorer (153 total points). Track your full progress on GrantFox.

👏 Great work, @Bigmehelen! Keep contributing to Txio-labs.

[Kingvic300]

Reopening — the fix was never actually delivered

Re-verified against latest main (commit cd6834e). The API Keys tab is still a pure client-side mock:

• frontend/src/components/AuthModal/tabs/ApiKeysTab.tsx:27-42 — handleCreateKey generates a key with `sui_sk_${Math.random().toString(36)...}` (non-cryptographic, low-entropy) and only calls onApiKeysChange. No fetch/apiService call anywhere in the file.
• frontend/src/components/AuthModal/AuthModal.tsx:23,56 — apiKeys is local useState<ApiKey[]>([]), never hydrated from or persisted to any backend or storage.
• No backend route exists: grep -ril "api.?key" backend/api/src returns only config/env-var matches — no /api-keys endpoint. frontend/src/services/api.ts has zero references to API keys.

Repro: Profile → API Keys → Create Key → a plausible key (sui_sk_...) is shown with "Copy this key now, it will not be shown again" — it's never sent anywhere and will never authenticate anything. Refresh the page and the "created" key vanishes (state reset).

This is more deceptive than a stub button — it hands the user a fake secret that looks legitimate. Reopening rather than filing a duplicate since the original issue title/scope still exactly describes current behavior.

Timeframe

Claim window: 96 hours. If this issue is claimed/assigned, please submit a fix within 96 hours of assignment — after that window it may be released back up for grabs.

Community

Questions about this issue or the campaign? Join https://t.me/txioCommunity