Data Integration Platform: How to Choose One That Fits

You've watched three demos this month. Each data integration platform showed a wall of logos, a drag and drop canvas and a dashboard that filled in by itself. Then you asked whether it connects to your field service app, and the answer was "through our generic HTTP connector." That answer decides more about your project than any feature on the slide.

A data integration platform moves data between your business systems, or from them into one place for reporting, on a schedule or as changes happen. The way to choose one is to start from the decisions the data feeds and the hardest source system you have, then work backward to the tool. This guide gives you the tool categories, a requirements matrix tied to real decisions, and the source system checks that rule tools in or out before you sign.

What a data integration platform does

The term covers a few kinds of tools that solve different problems. Most buyers need one or two of them.

Two questions sort most buyers into a column. Do you need data in one place for reporting (analytics), or do you need systems to update each other (operations)? And how many of your sources are popular apps with mature prebuilt connectors?

Start with the decisions, then the features

Feature lists invite you to buy capability you'll never use. A requirements matrix tied to decisions keeps the evaluation honest. Fill in the right column for your business before any demo.

If the first row says "analytics only" and the freshness row says "daily," most of the market will work and the decision comes down to price and sources. If you need two way syncs within minutes, the field narrows fast.

The source system test: check your hardest source first

Every platform looks good on Salesforce and QuickBooks. Pick your least popular, most important system and check three things before you shortlist anything.

1. How does the platform connect to it? A dedicated connector maintained by the vendor is one thing. A generic HTTP connector means your team writes the queries, pagination and error handling. Tray.ai, for example, connects to Jobber through its HTTP Connector and notes that Jobber API access comes through Jobber's partner program or an API plan. Other platforms, such as Nexla, list a Jobber connector with templates for clients, jobs, quotes, invoices and properties. Same source, very different amounts of work.

2. What are its API limits? Jobber's rate limit docs describe two limits: 2,500 requests per five minutes per app and account, and a GraphQL cost budget that, in Jobber's sample response, holds 10,000 points and restores 500 points per second. A connection costs its page size times the number of fields requested. That math decides how often you can refresh.

3. How far back can you recover changes? HubSpot's Journal API lets you query changes for the past 3 days. A sync that's down over a long weekend plus a day loses its place and needs a full reload.

Here's what the Jobber limit means in practice. Set your own record count, fields and refresh interval.

This is the kind of limit that rules out an attractive tool. A platform that only offers full table refreshes on a generic connector will spend most of its API budget rereading records that never changed, and every other integration on that Jobber account competes for the same budget. A design that pulls only records updated since the last run fits easily. Ask every vendor which one they do for your hardest source, and ask them to show it.

Refresh, schema changes and data quality

Three operating issues decide whether the platform still works in six months.

• Refresh strategy. Incremental loads (only changed records) are cheaper and faster than full reloads, as the chart shows. They need a reliable "last updated" field or change feed on the source. Confirm that field exists for every object you need.
• Schema changes. Vendors add fields, rename them and change API versions. Nexla's Jobber connector, for instance, pins a specific Jobber GraphQL API version in a request header. Ask how the platform tells you when a source changes, and who updates the mapping.
• Data quality. Moving data is the easy half. Duplicate customers, missing job numbers and conflicting addresses travel just as fast as clean records. The platform needs a place to apply matching rules and a queue for records that fail them. If it has neither, plan to build that layer yourself.

What it costs to run

License price is the visible part. Budget for four lines:

1. Platform fees. Usage pricing is common. Fivetran meters monthly active rows, counting rows inserted or updated each month; its free plan covers 500,000 of them, and its Standard plan table shows a lowest annual contract of $12,000.
2. Destination costs. Warehouse storage and compute, or a managed Postgres database.
3. Build time for gaps. Custom connectors, matching rules and exception handling the platform doesn't cover.
4. Maintenance. Someone watching failed runs, updating mappings after schema changes, and answering "why doesn't this number match?"

Line 3 is where cheap platforms become expensive. A tool that covers 80% of your sources still leaves you building and owning the other 20%, usually the ones that matter most.

When the right platform is a database and a few integrations

Some of the most useful setups we build look small. The Horizon Roofing pricing portal we delivered, which handles contractor quotes, pricing, labor, margins and approvals, runs on PostgreSQL and Supabase with a Google Sheets integration. It works without a warehouse.

For a mid market operator with a CRM, an accounting package and a field service app, a sensible starting point is often:

• A managed Postgres database as the shared layer.
• Prebuilt connectors or a managed tool for the popular sources.
• Small custom jobs for the hard source, written to respect its API limits.
• Matching rules and definitions in SQL, with an exceptions table people review.
• Reports in Power BI or a similar tool on top.

You can move to a bigger platform later. Clean, matched data in one place is what lets you.

Choosing with your hardest source in hand

The right data integration platform is the one that handles your hardest source within its API limits, applies your matching rules, and refreshes at the speed your decisions need. Write the requirements matrix, run the source system test, and price the gaps along with the license.

If you'd like a second pair of eyes on a shortlist, or want us to run the source system test on your stack, show us the workflow. Our data integration page covers how we build the shared layer between your systems and your reports.

Sources

• API rate limits, Jobber Developer Center, accessed Nov 2026
• Jobber connector, Nexla Docs, accessed Nov 2026
• Jobber integrations, Tray.ai, accessed Nov 2026
• Webhooks Journal API, HubSpot Developers, accessed Nov 2026
• Fivetran pricing, Fivetran, accessed Nov 2026
• What is Power Query?, Microsoft Learn, accessed Nov 2026