feat: Data API frontend (rescued from development before reset)

[rdahis]

Purpose

Rescue the Data API frontend work onto a main-based branch before development is reset.

The feature was developed in Feb–May 2025 and never reached production: its commits exist only on origin/development, which diverged from main under the old workflow and is scheduled to be reset.

Draft on purpose. Per Git Flow this must be validated via PRs into development and staging first. Those will be opened once the branches are reset; this PR stays in draft until then and merges into main last.

Description

7 commits cherry-picked with -x from origin/development, oldest→newest, original authorship preserved:

commit	subject
a1bb17c8	feat: init data API docs
cea0ddb8	feat: user page for Data API keys
2cea36db	feat: data API in user area
afcfcdf8	chore: required -> isRequired
6bc7322f	chore: adjustments to authentication and pricing communication
6bdeba3f	feat: bring back user Data API page, add credits modal
345b0ec8	updates to data API page

Adds the /data-api-docs page, the Data API section of the user area, the credits modal and Stripe credit-payment endpoint, and the endpoint/category API routes.

Two commits from the range were deliberately dropped:

• e3b5ed0e — byte-identical duplicate of 6bc7322f (the same change was committed twice, once on the mainline and once on the feature branch).
• 8ce54ff5 — became empty; it only stripped two comments that no longer exist after the resolutions below.

Already partly on main

next/public/locales/{en,es,pt}/dataAPI.json were already on main at their initial a1bb17c8 state — they arrived via PR #1152 (feat/accesses). The later copy refinements in 6bc7322f and 345b0ec8 were still missing and are included here.

Conflict resolutions worth reviewing

• pages/user/[username].js — main had already migrated sectionSelected from array indices to string ids. The incoming index-based render block (choices[sectionSelected].value === …) was stale and would have broken the page, so 6bdeba3f's string-id version was taken, matching main.
• pages/api/user/getUser.js — the GraphQL field set was unioned rather than taken from either side. 6bdeba3f re-added the keys block from scratch after a revert and dropped name, but its own DataAPI.js still renders key.name; taking it literally would have shipped a silently blank field. This is the one place the result differs from a literal cherry-pick and is worth a look.
• locales/es/user.json — add/add conflict against main's new survey block; both keys kept, JSON validated.

Auth-related hunks in [username].js conflicted because main moved the token from a query parameter to a Cookie header. main's version was kept in every case — the incoming side was the older, less safe form.

Testing and evidence

Verified so far: all six locale JSON files parse; DataAPI is exported and imported correctly; relative imports in the new files resolve; no conflict markers remain. Not yet run: a build or any browser check. Both should happen on the development PR, along with an end-to-end check of the credits flow against the backend.

Next steps

1. Hold in draft until development is reset.
2. Open PRs into development and staging; validate there.
3. Merge into main last.

Depends on the backend PR in basedosdados/backend — the user area needs the keys GraphQL field to render.

🤖 Generated with Claude Code