Hi, I’m Sahil K., and I'm back with another story about API migration! Previously, I shared my experience with the Projects API Migration, an initiative that was both challenging and rewarding. If you haven’t checked it out yet, you can read about it [here].
This time, I am writing about the Admin CC Cards API Migration, the initiative I took last quarter (Q4), immediately after wrapping up the Projects API Migration. But, unlike the project's API migration, which involved migrating a single GET API with response transformation and some tweaks, this initiative was somewhat different.
For context, the term "Admin" here refers to administrative functionalities within the Fyle platform, primarily used by the organization’s admins to manage core configurations. And the CC Cards APIs specifically handle tasks related to managing credit card information securely for administrative operations.
While first starting, we didn’t even know the full scope of APIs to migrate at the outset. While I had a rough idea of what needed to be done, the exact number of APIs and the extent of the migration remained unclear in the beginning.
Here’s a detailed account of the journey—what we set out to achieve, the hurdles we faced, and how we navigated them.
The Journey Begins 🤠
The corporate card system is the backbone of Fyle’s expense management system. Over time, this system evolves, and APIs that once worked well may become inefficient, redundant, or incapable of supporting new functionalities. Last quarter, we decided to migrate the Corporate Cards APIs to our latest platform architecture to improve performance, scalability, and usability while eliminating redundancy.
The ED Document 📄
Every great project begins with a solid foundation, and for me, that was the Engineering Design (ED) document. Starting from a blank slate, I started documenting the API usage in the Admin CC cards area, just to get an idea of the scope and laid out the roadmap for the migration.
I went one by one to all cc transaction pages and performed every single action, whether it be as small as clicking a hyperlink or pressing every single button on that page, in order to document which API call was going out. So by the end of the first week, we figured out 40+ different API calls were going out but not all of them were required to be migrated, a few were out of scope and few were already migrated. After a quick syncup, we got our count of how many APIs to migrate and which actions to migrate. So we decided to migrate 10+ APIs in total and completely discard one unnecessary API call.
The actions to migrate were divided into two categories:
Card-Related Actions: Assign Card, Unassign Card, Delete Card Etc.
Transaction-Related Actions: Assign Transactions, Re-assign Transactions, Delete Transactions, Etc.
There was plenty of work to do, involving designing the APIs and using them in the front end.
Key Highlights of the ED Document
Comprehensive Analysis: The document detailed all existing API structures, including endpoints, payloads, workflows, and their limitations.
Migration Plan: A step-by-step sequence for migration was laid out, along with strategies to manage dependencies and streamline the process.
Test Cases: Migrating such a large number of APIs introduced significant risks. To mitigate this, we created comprehensive, step-by-step documentation for test cases to ensure reliability.
This document wasn’t just a roadmap—it was our reference point at every stage of the initiative. I mean it because there wasn’t a single day throughout the migration where I didn’t revisit it for planning, testing, and documentation.
Executing the Migration 🤺
Once the groundwork was laid with the ED, the real challenge began—executing the migration. Migrating all the APIs across various workflows, while ensuring minimal (near to zero) disruption to existing functionality, required careful planning and execution.
Step 1: API Design and Development
The backend team was responsible for redesigning the APIs to align with the new platform architecture. A big shoutout to Roshan Mhatre, Sumanth Avadhani, Madan Gopal, and Kulasekar for their outstanding contributions.
Step 2: Integration with the Frontend
This was the hands-on phase of the migration for me. Once the backend APIs were ready, it was time to integrate them into the front end—updating the codebase to replace old API calls and ensure the system worked flawlessly with the new architecture.
Step 1 and step 2, were more than just technical execution—it was about collaboration, problem-solving, and adaptability.
Step 3: Testing Testing & Some More Testing
Testing played an important role in the migration. Every single migrated API went through detailed test cases from the test case doc to ensure it functioned as expected. Pre-release followed by post-release testing.
Key areas of focus:
Ensuring the new APIs didn’t break existing functionality, required a deep understanding of workflows.
Applying the lessons learned during Project API migration, I planned weekly releases, focusing on delivering small, thoroughly tested changes. This approach allowed us to identify and address issues before release, ensuring stability and minimal issues.
Testing beyond usual scenarios to uncover potential vulnerabilities.
Export API Migration: Wrapping Up the Journey 📈
Of all the APIs we migrated, the Export API deserved special attention. Export functionality allows users to generate detailed reports of their CC transactions, making it a crucial component.
Frontend tasks for Export API migration included:
Refactoring advanced settings for list view columns.
Transitioning user settings and default export preferences to the backend.
Rewriting new column configurations for the list view table.
Verifying export formulas with the backend team.
This migration took three weeks and required close collaboration with the backend team. Rigorous testing ensured a smooth transition with significant improvements in functionality.
Learnings And Achievements Along the Way 🏆
For me, this initiative wasn’t just about improving APIs—it was an incredible learning experience. Here’s a closer look at the milestones and lessons learned.
Valuable Learnings:
Gained insights into complex systems like VISA Net and RTF (Real-Time Feed).
Developed a better understanding of virtual card management processes and bank statement reconciliation.
Worked with different teams, improving Collaboration and Communication
Key Achievements:
Migrated 10+ APIs in 2.5 months.
Eliminated 10+ redundant API calls and identified and removed 1 unnecessary API call, simplifying critical workflows for smoother operations
Completed the entire migration without a single P0 issue — ensuring no disruptions for customers.
Reflections and Takeaways 🎖️
This migration has been by far the most rewarding, enjoyable, and filled with knowledge, and initiative I’ve worked on. It challenged me to grow both technically and taught me how to collaborate with the team.
What I learned is,
Documentation Matters: A well-thought-out ED document saves time, clarifies goals, and streamlines collaboration.
Testing is Essential: Comprehensive testing ensures reliability and stability. It’s a cornerstone of success.
Learning is Continuous: Tackling complex systems like VISA Nest and virtual cards expands your expertise in ways you never expected.
Looking Forward 👀
While this migration is complete, the journey doesn’t end here. I’m excited to see how these changes enhance our platform and user experience. This initiative has reaffirmed the value of embracing challenges, learning along the way, and building impactful solutions. From streamlining APIs to gaining deeper insights into complex corporate card systems, every milestone brought new opportunities to grow and contribute meaningfully.
As I look ahead, I’m excited to carry these learnings into future initiatives and continue pushing boundaries.
Kudos to Dimple, Sumanth Avadhani, Madan Gopal, and Kulasekar for their constant support throughout this initiative.
Here’s to more exploration and growth.
Happy coding…! 🚀