SWAP Admin V1/V2 transition
I contributed to V2 screen and API changes while existing task data remained.
Work context
When V2 screens and the Fleet API were introduced to the SWAP operations Admin, legacy task lookup paths remained. The data and screens did not change at one instant.
As SWAP FE Part Lead, I contributed to the Admin V2 release through major feature development, technical review, and code review. I worked on connecting subscription, task, and factoring screens, version-aware navigation, permissions, and operations menus with the new paths.
Since September 2025, I have handled technical decisions, development, and review for SWAP FE. V2 was a team release; I helped coordinate how screens, APIs, and operations paths fit together.
Decisions and implementation
- 01
New screens and legacy lookups
Legacy task data still needed a lookup path while V2 task screens were introduced.
Within the Admin V2 transition, I worked on the coexistence of new Fleet API screens and legacy paths. At release time, task details attempted V2 first and queried V1 if the request failed.
- 02
Version-based navigation
The entry point for a task could differ from the version of its actual data.
The transition included checking the version on the legacy detail screen and routing V2 tasks to their corresponding detail screen.
- 03
Related operations paths
Changing only subscription and task screens could break staff menus, access permissions, payment lookup, and bulk-work flows.
I contributed to the transition of operations features including permissions, the sidebar, payment lookup, and bulk work.
Open task detail → Try V2 first → Fall back to V1 if the request fails
A summary of the task-detail lookup flow during the transition.Implementation details
For Admin V2, we connected navigation to the data version and integrated new API responses while detail and contract workflows still used legacy APIs.
- 01Open details
Fetch task data from the legacy URL
- 02Check version
Use the task version in the response
- 03Move to V2
Navigate to the new detail route with replace
- 04Continue operations
Keep new and legacy API workflows available
Version-based routing
The legacy task detail checked the version in the response and sent V2 data to the new detail screen. Navigation used replace so the transitional entry URL did not add another browser-history entry.
Filter and pagination state
The factoring list managed filter and page state together and omitted empty filter values from lookups. A filter change returned to the first page; the Fleet API’s total count and page were connected to table pagination.
Mixed API boundaries
New lists used Fleet API page responses, while related detail, contract, and attachment workflows still had legacy API paths. I contributed to the team release connecting new entry screens for subscriptions, tasks, and factoring, with loading and error boundaries for the factoring V2 list built using Suspense and ErrorBoundary.
Verification and results
- Admin V2 release
The Admin release including subscription, task, and factoring V2 screens and Fleet API integration was merged in December 2025.
- Coexisting task details
At release time, task details queried V2 first and had a V1 lookup path when the request failed. The production error rate for this path was not measured separately.
Contributed to the Admin V2 screen and API transition while old and new task data coexisted.
This describes the transition of SWAP's operations Admin. I describe the lookup path used at the time without claiming a measured error rate or completion of the entire service migration.
Reflections
Navigation and lookup while legacy data remained mattered as much as connecting the new API and screens. This experience covers the SWAP operations Admin transition.
Based on career records and implementation evidence. Diagrams reconstruct the work for explanation; private product screens and data are excluded.