How we use testing to support the most reliable, secure, and scalable integrations

Building and maintaining hundreds of integrations is incredibly hard.

You have to navigate different authentication methods, data models, and API specs for each platform; handle unexpected edge cases as customers onboard; continuously manage API version changes, breaking updates, and platform-specific bugs; and a whole lot more.

At Merge, we take on this work on behalf of the world’s largest banks, AI companies, streaming platforms, HR technology providers, and more. And since these customers have the highest standards for integration security and reliability, the complexity—and the bar—is even higher for us.

To deliver the most reliable and secure integrations at scale, we perform robust and sophisticated testing.

We treat testing as a continuous system that evolves alongside our product, our customers, and the third-party platforms we integrate with. Because when your product sits between mission-critical systems, “mostly correct” isn’t good enough.

That said, given the breadth and depth of integrations we work on, testing can be extremely difficult. I'll break down why and how our approach overcomes these challenges. 

Why integration testing is uniquely hard for us

Integration quality becomes extremely complicated when you weigh all of the challenges we face. 

Here are just a few:

Hundreds of cross-category integrations 

Merge supports hundreds of third-party platforms across eight integration categories (and growing!). Each platform has its own APIs, data models, quirks, and edge cases, and they evolve independently of us.

Diverse syncing requirements

Some of our customers prioritize data robustness (e.g., historical financial data), while others only care about a small subset of data, but need it to reflect changes in near-real-time (e.g., inventory levels). Delivering widespread demands requires flexible architectures and careful tradeoffs between scale, speed, and accuracy.

Flexibility by design

Customers can pick which endpoints, objects, and scopes they use. They can also create custom fields, apply custom filters, and utilize different authentication methods. All of this flexibility increases the surface area and the number of states the system can be in.

Sandboxes aren’t reality 

Third-party sandbox environments are critical for building and testing integrations, but they’re rarely representative of an enterprise environment. A sandbox differs from an enterprise account in scale (e.g. an HR software sandbox may have ten employees, whereas a large employer will have tens of thousands).

Custom account configurations, rate limit tiers, and geographic/language differences also aren’t discoverable in a sandbox environment.

How we approach testing and monitoring integrations

To overcome these challenges, we don’t rely on a single testing strategy. Instead, we layer multiple systems together, and each is designed to catch different classes of failure.

Foundational testing

This typically includes the following tests:

Unit testing 

Unit tests verify that individual components behave correctly in isolation and across potential and known edge cases, such as null values, special characters, and other boundary conditions.

At Merge, these tests run automatically in our CI/CD pipeline, helping ensure that new code changes don’t break existing functionality and that our development process aligns with industry standards.

Load and performance testing

Load testing ensures our integrations can handle enterprise-scale data volumes and concurrent operations without degrading performance or hitting third-party rate limits. 

Merge tests the syncing of large volumes of data (for example, 10M files or 5M candidates) to ensure that our integrations operate at the scale of our customers, and uses the results to optimize performance. 

Both of these tests are foundational to reliable integrations, but are only the starting point of Merge’s testing framework.

End-to-end testing that mirrors real usage

The most meaningful failures don’t come from isolated API calls; they come from sequences of actions over time.

With this in mind, we’ve invested heavily in automated end-to-end (E2E) test suites that model real data lifecycles across third-party platforms. 

These suites:

• Define the full set of “data story” actions that can occur in each system (creates, updates, deletes, permission changes, state transitions, etc.)
• Execute those actions in controlled environments
• Validate how data flows, mutates, and reconciles end-to-end through Merge

This allows us to simulate the behavior within a real-world enterprise environment. For example, one of our end-to-end tests for SharePoint, shown below, pressure tests how enterprise customers can reorganize their document structure. 

Our team’s deep experience in building and debugging integrations has enabled us to catalog hundreds of ways that data can flow through third-party software across integrations and use cases. 

Our tests then simulate each of these scenarios to verify that a given integration correctly records and represents the resulting data changes.

Canary releases to limit our blast radius

Even with extensive testing, production environments can contain unknowns.

Third-party APIs can change without notice; enterprise customers can have heavily customized configurations that differ from sandboxes; customer-specific edge cases and unexpected data volumes can surface behaviors that testing environments can't replicate, and the list goes on.

To manage this, we use canary testing in several ways. Here are just a few:

• New logic is rolled out first to a very small subset of customers
• System health, error rates, and data correctness are closely monitored
• If anomalies appear, changes can be quickly rolled back before broader impact

This lets us learn from real-world behavior while tightly controlling risk. In other words, it offers an early warning system rather than a full-scale rollout.

Continuous monitoring in production

No test suite can fully replicate every real-world configuration. That’s why monitoring is as critical as testing.

We continuously monitor:

• Sync health and performance
• Error patterns across third-parties and customers
• Behavioral changes from third-party APIs

For example, we proactively detect issues at both the individual linked-account and organization-wide levels. This allows us to surface early warning signs of a problem, such as a sudden spike in sync failures for a specific integration or an unexpected increase in API response times. 

We consistently see this approach work.

For example, last month we identified unexpected behavior in two different third-party APIs and informed the providers, leading them to fix the problem and update their documentation accordingly.

These signals feed directly back into our engineering and testing systems, informing where to harden logic, expand coverage, or adapt to upstream changes.

Final thoughts

Our testing and monitoring systems will continue to grow alongside our products, customers, and integrations to deliver industry-leading quality and performance. 

Testing at Merge isn’t a milestone; it’s an ongoing investment to provide the most reliable and secure integrations for the largest and fastest-growing companies in the world.

{{this-blog-only-cta}}