Context
I originally developed the bank deposit workflow using mocked data because the back-end services were not yet available. With the APIs now delivered, the next objective was to connect the front-end to production endpoints and validate the workflow end to end.
This phase involved integrating four API endpoints across the process and refactoring temporary logic introduced during the prototyping stage.
Studying the API Response
I began with the first step of the workflow, where a mocked data table needed to be replaced with live API data. Although the endpoint returned all required information, the payload also contained additional properties that were not immediately relevant to the UI.
A quick discussion with the back-end developer clarified which fields should drive the interface and which should be ignored.
Replacing Mocked Data and Refactoring Logic
With the API contract clarified, I used GitHub Copilot to accelerate the integration. The mocked dataset was removed and replaced with live API responses, while temporary UI logic was refactored to rely on actual response properties.
For example, USD values had previously been displayed through a hardcoded feature flag. After integration, the component rendered these values conditionally based on whether foreign currency amounts were present in the API response.
Updating Core Business Rules
Before the API was available, the system was designed to retrieve USD exchange rates from a separate endpoint and prompt users to enter them manually only if the lookup failed.
The production API introduced a new property containing the exchange rate directly in the response. As a result, the workflow was refactored so the system requests user input only when this value is absent.
Demonstration of how the application uses a response property to determine whether manual exchange-rate entry is required.
Removing Temporary Testing Structures
During development, I created dedicated URLs to simulate edge cases involving CAD and USD transactions while the back-end was unavailable.
Once live endpoints were connected, these temporary routes and associated fixtures were no longer needed. Currency-specific scenarios were now handled natively by reusable components consuming real API data.
End-to-End Validation
The bank deposit workflow spans multiple steps and contains numerous business-rule branches. After replacing the mocked data, I executed the entire workflow repeatedly to identify residual dependencies and regressions.
This validation surfaced several issues, including logic paths that still referenced obsolete mock files and conditional rules that no longer reflected the production API structure.
The system incorrectly attempted to fetch an exchange rate even though the API already provided the required value.
A validation rule compared user-entered values against a stale mock dataset, triggering an erroneous justification request.
Resolving a Cross-Functional Misalignment
During implementation of the final step, I encountered a discrepancy between UX prototypes and back-end expectations.
The design indicated that a warning message should appear immediately when the user selected the option to close the office after completing the deposit. However, the back-end architecture assumed this decision could only be evaluated after the bank transfer had already been submitted.
To resolve the issue, I organized a working session with the lead UX designer, lead back-end developer, and business analyst. The team agreed to move the bank transfer submission one step earlier in the workflow, leaving the final step dedicated exclusively to office closure.
This alignment preserved the intended user experience while ensuring the implementation remained technically feasible.
Note: The examples above represent only a subset of the issues uncovered during the integration phase. Close collaboration with the back-end team proved invaluable in identifying implementation gaps, clarifying API contracts, and resolving edge cases efficiently.
A walkthrough of the complete bank deposit workflow, highlighting how each step interacts with production endpoints and how API responses drive business logic, validation rules, and user-facing decisions.
Conclusion and Next steps
Connecting the bank deposit workflow to production APIs was far more than a data-mapping exercise. It required refactoring temporary logic, validating complex business rules, removing technical debt introduced during prototyping, and aligning multiple teams around a shared implementation strategy.
The result is a workflow that is no longer dependent on mocked data and is now capable of operating against real back-end services while preserving the reliability required for financial reconciliation processes.
Next steps
The integration work is largely complete, but several opportunities remain to further strengthen the solution:
Continue validating edge cases as additional back-end functionality becomes available.
Expand automated testing coverage to reduce regression risk during future releases.
Monitor API performance and error handling under real-world operational conditions.
Refine the user experience based on feedback gathered from business users and ServiceOntario staff.
Support future enhancements as the broader modernization initiative continues to evolve.
This phase marks an important milestone: the transition from a prototype-driven implementation to a fully integrated enterprise workflow operating on production-ready services.