Skip to content

docs: add API v1 to v2 migration guide (#276) - #346

Open
i-amdaveee wants to merge 1 commit into
Pidoko257:mainfrom
i-amdaveee:docs/api-v1-v2-migration-guide
Open

docs: add API v1 to v2 migration guide (#276)#346
i-amdaveee wants to merge 1 commit into
Pidoko257:mainfrom
i-amdaveee:docs/api-v1-v2-migration-guide

Conversation

@i-amdaveee

Copy link
Copy Markdown

closes #276

Add API Migration Guide from v1 to v2 (#276)

Adds docs/API_V1_TO_V2_MIGRATION.md — a client-facing guide for moving from the current stable v1 API to v2. Linked from the existing API_VERSIONING.md summary section.

Context: v2 is not yet shipped

The v2 routes are mounted at /api/v2/* but every handler currently returns 501 Not Implemented ("V2 API is coming soon"). The breaking changes exist as scaffolding and route-stub comments (src/routes/v2/, src/middleware/apiVersion.ts), not as live behavior.

So this guide is deliberately forward-looking: clients do the prepare ralize response parsing) and the adapt/cut-over steps when the beta ships.v1 examples are the real current responses; v2 payloads are marked provisional until the beta contract is frozen.

What's included

  • Breaking changes at a glance — table of 6 changes with impact flags
  • Before/after examples for each: response envelope (`{version, data, meect, renamed search/filter params, webhooks vs polling, removal of legacyunversioned endpoints, auth
  • A defensive unwrap() parser that handles both v1 and v2 during transitio
  • Migration checklist — Prepare / Adapt / Cut over phases
  • Timeline — anchored to v2 GA (beta → GA → deprecation at +180d → sunseicy in API_VERSIONING.md
  • Early-adopter feedback section documenting the human validation step - FAQ and references to the relevant source files
    ### Acceptance criteria
    - [x] Guide covers all breaking changes
  • Includes migration examples - [x] Timeline is clear
  • Collected feedback from early adopters — human step, happens during the v2 beta; the guide documents who/when/what to collect and marks v2 examples provisional until that loop closes

Reviewer notes

Two pre-existing inconsistencies in API_VERSIONING.md surfaced while writiut out of scope for this docs PR:

  1. It states /api/version returns "supported": ["v1"], but the middlewar["v1", "v2"]. My guide shows ["v1", "v2"]` to match the code.
  2. I couldn't find a route handler for /api/version anywhere in src/ — the endpoint may not actually be wired up.

Docs-only change; no code touched.

Add docs/API_V1_TO_V2_MIGRATION.md — a client-facing guide for moving from
v1 (current stable) to v2. Documents all planned breaking changes with
before/after examples, a phased migration checklist, and a deprecation
timeline anchored to v2 GA.

v1 examples reflect the real current responses (deposit shape and the
{data, pagination} list envelope from transactionController.ts). v2 is
mounted at /api/v2 but currently returns 501, so the guide is written as
forward-looking (prepare now, adopt at beta) and v2 payloads are marked
provisional until the beta contract is frozen.

Linked from the existing API_VERSIONING.md summary section.
@drips-wave

drips-wave Bot commented Jul 30, 2026

Copy link
Copy Markdown

@i-amdaveee Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add API Migration Guide from v1 to v2

1 participant