Migrating to Fiskil APIs

Migrating from an existing data provider doesn't have to be a disruptive big-bang deployment. Whether you're moving from custom-built solutions, legacy aggregators, or screen-scraping services, Fiskil supports flexible migration strategies that let you test, learn, and scale at your own pace.

This guide shows you how to design a migration that minimizes risk, maintains user experience, and unlocks the full value of real-time, user-consented data.

Why Choose a Phased Migration?

We recommend a phased rollout. It reduces risk, preserves user experience, and accelerates time-to-value while you adopt Fiskil with confidence.

Risk containment: Issues are isolated to a narrow scope, not your entire user base.

Continuous improvement: Real production feedback guides rapid iteration before broad rollout.

Business continuity: No downtime or disruption to existing flows while you adopt Fiskil.

Progressive enablement: Your team builds expertise as coverage expands.

Migration Strategies

Choose the approach that best aligns with your risk tolerance, technical constraints, and business requirements:

Full Cutover

Replace your existing provider completely in a single deployment. This is a viable, clean-slate option - particularly for new applications, pilots, or straightforward integrations - when you're ready to adopt Fiskil end-to-end.

Institution-by-Institution Migration

Migrate one financial institution at a time. Start with a high-value institution, enable Fiskil for users connecting to that bank while maintaining your existing provider for others, then expand coverage as confidence grows.

Best for: Most production applications where you want to validate data quality and user experience incrementally without disrupting existing flows.

Alternative Approaches

Parallel Data Collection: Run both providers simultaneously for the same users to compare data quality before switching - useful for mission-critical workloads.

Feature-Based Migration: Move discrete features (e.g., account aggregation, transaction categorization) rather than entire institutions - effective for complex multi-use-case apps.

Planning Your Institution-by-Institution Migration

Before You Start

Assess Your Current Integration: Document your existing data flows, user journeys, and business logic dependencies. Understanding these patterns helps you design an equivalent flow with Fiskil while identifying potential challenges early.

Choose Your First Institution: Select a high-value institution with significant user volume but lower business criticality. This gives you meaningful data to validate your integration while minimizing risk.

Set Success Criteria: Define clear metrics for each institution migration including conversion rates, data quality measures, and user satisfaction scores.

Implementation Strategy

Start small: Begin with a limited cohort for your first institution. Use configuration/feature flags to control routing and enable quick rollbacks.

Observe and optimize: Monitor technical and user experience signals to validate your integration.

Expand scope: Add more institutions and broaden user coverage as confidence grows.

Technical Implementation

Targeting Specific Institutions

For institution-by-institution migrations, preselect institutions when creating Auth Sessions by passing institution_id. This bypasses the institution selection screen and takes users directly to their bank's login interface.

curl --request POST \
 --url https://api.fiskil.com/v1/auth/session \
 --header 'Authorization: Bearer {access_token}' \
 --header 'Content-Type: application/json' \
 --data '{
 "end_user_id": "eu_12345",
 "institution_id": "10",
 "redirect_uri": "https://yourapp.com/auth/success",
 "cancel_uri": "https://yourapp.com/auth/cancel"
 }'

Embedding vs Redirecting

When you create an Auth Session, Fiskil returns an auth_url. You can either redirect to our hosted consent UI or embed it via iframe to maintain brand continuity - both options deliver a secure, high-conversion experience.

Data Mapping

Keep your existing domain models and introduce a translation layer where needed. Fiskil's enrichment and data quality signals can be adopted incrementally without breaking current contracts.

Common Migration Considerations

Data schema differences: Add a translation layer where needed; adopt enrichment and quality signals progressively.

User experience: Redirect or embed to fit your UX. Embedded flows typically maximize brand continuity and conversion.

Performance patterns: Enable monitoring/alerting and tune retries, caching, and backoffs as you expand coverage.

Business logic coupling: Isolate provider-specific logic behind clear interfaces to simplify future changes.

Expert Support

Our team partners with you on strategy and implementation - schema mapping, consent UX, and rollout best practices - so you can migrate with confidence and realize value quickly.

Ready to get started? Contact our implementation team to design a plan tailored to your stack and users.