What is an integration platform, and where does it stop helping?

An integration platform connects systems to each other, providing pre-built connectors, a way to express logic between them, and the operational machinery — scheduling, retries, logging — so you are not building that per integration.

The value is real and it is worth understanding precisely what you are buying. A connector is somebody else's model of a system's API, maintained on their schedule, covering the operations they decided to cover. That is usually a good trade, and the cases where it is not are predictable.

What we'll cover

• What a platform actually provides
• What a connector is
• The last ten per cent
• Build, buy, or both
• Pricing models and how they bite
• Where integrations actually break
• Evaluating one honestly
• Who is meant to use it
• Where CodeWords fits
• What to get right first
• Frequently asked questions

What a platform actually provides

Four things, and it is worth separating them because different products weight them differently.

Connectors, which remove the work of writing and maintaining an API client per system.

Authentication handling, including the token refresh that breaks most hand-built integrations after a few weeks.

Operational machinery — scheduling, retries, error handling, logging, monitoring — built once rather than per integration.

A way to express logic between systems, whether visual, configuration-based, or code.

The operational machinery is undervalued. Teams comparing platforms focus on connector counts and then rebuild retries, backoff, and logging themselves in a hand-rolled alternative, which is where the time actually goes.

What a connector is

Being precise about this makes the rest of the decision clearer.

It is somebody else's model of an API — a set of operations they chose to expose, with their names for things.

It covers what most customers need, which is usually the common operations and rarely everything.

It is maintained on their schedule. When the third party changes an API, the connector is updated when the platform vendor gets to it.

It hides the underlying API, which is the benefit and means that when you need something it does not expose, you are stuck at their boundary.

Connector counts are a weak signal. A platform advertising a large number includes many that are thin, and one deep connector for a system you depend on is worth more than fifty shallow ones.

Check depth for the systems that matter to you — the two or three where most of your integration work will be — rather than comparing totals.

The last ten per cent

Where integration projects stall, reliably.

The first ninety per cent is straightforward on any competent platform.

The remaining ten is the specific thing your business does — an unusual field, a system with no connector, a sequence the visual model cannot express, a volume the platform handles awkwardly.

Every platform has an escape hatch, and its quality is the most important thing to evaluate: can you write code, call an arbitrary endpoint, define your own connector?

Evaluate on the hard case, not the demo. The demo integration works everywhere. Prototype the awkward one during the trial, because that is what determines whether the project finishes.

A platform with no escape hatch is a ceiling, and you will find it in month four rather than during evaluation.

Build, buy, or both

Buy when the systems are common. Writing an API client for a mainstream product is work somebody has already done better.

Build when the system is yours, since no connector exists and the platform is adding indirection to something you already understand.

Build when the logic is the product. Complex, differentiating business logic belongs in your codebase where it is reviewed, tested, and versioned.

Buy for the operational machinery even when you build the logic, because retries, scheduling, and credential handling are where hand-rolled integrations rot.

Both is the normal answer. A platform for the many small connections, and code for the few that matter — rather than a doctrinal commitment.

Count the maintenance. A hand-built integration is not finished when it works; it is a thing that needs attention whenever the API on either side changes.

Pricing models and how they bite

The factor that most often changes the answer after eighteen months.

Per-task or per-run pricing rewards batching and punishes fine-grained automations, which shapes how you design rather than only what you pay.

Per-connection pricing punishes breadth, which is awkward if your value is in connecting many systems.

Per-user pricing is predictable and unrelated to how much work the platform does.

Volume tiers have cliffs. Crossing one can change the cost substantially, and the crossing is usually a surprise.

Model your actual pattern, not the headline. Estimate runs per month per automation, multiply, and check what happens at three times your current volume.

Ask what happens when you exceed the plan — throttling, overage charges, or failure — since the three are very different operationally.

Where integrations actually break

Worth knowing, because it is rarely the connector.

Credential expiry and token refresh, which is the single most common failure across every platform.

Third-party API changes, which arrive without regard for your integration.

Rate limits, particularly the organisation-wide ones shared with every other tool you run.

Data shape changes — a renamed field, a new required value — which produce silent nulls rather than errors.

Volume growth, where an integration built for hundreds meets thousands.

Nobody watching. An integration that stopped produces nothing, and nothing looks like a quiet week, which is why estate-level monitoring matters more than any individual alert.

Evaluating one honestly

Prototype your hardest integration, not the easy one, during the trial.

Check connector depth for the two or three systems that matter most to you.

Test the escape hatch, by building something the visual model cannot express.

Ask about connector maintenance: how quickly do they respond when a third party changes an API, and what happened the last time a major one did?

Model the pricing at three times your current volume, and ask what happens at the plan boundary.

Ask what it does not do. A vendor who can answer has thought about where they fit; one who cannot has not.

Who is meant to use it

A question that determines which platform suits you and that evaluations frequently skip.

Engineers want code, version control, and testing. A visual builder they cannot diff is friction rather than help, and they will route around it.

Operations teams want to change a rule without a deployment, which is the case visual tools genuinely serve.

Business users want to build small things themselves, which requires the tool to be approachable and the governance to exist.

Platforms optimise for one of these and accommodate the others to varying degrees, and the mismatch is the usual reason a purchased platform sits unused.

Ask who will actually build on it, honestly, rather than who it is being bought for.

Mixed audiences are normal and need a plan — typically the same platform with different patterns and different review expectations per group, rather than separate tools that connect to the same systems twice.

Where CodeWords fits

CodeWords connects to more than 3,000 integrations and builds the automation from a plain-language description, which covers both the connection and the logic between systems without either being assembled by hand.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder, including the exceptions.
3. Connect each system once and reuse the connection across automations.

The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

What to get right first

Prototype the integration you are least sure about, during the evaluation, rather than the one that demonstrates well. Every platform handles the common case, and the project finishes or stalls on the awkward one — which you will otherwise meet in month four with the decision already made.

Two habits make the difference. Evaluate connector depth for your two or three critical systems rather than comparing connector counts, since a large total tells you nothing about the ones you actually need. And model the pricing at several times your current volume, because the model shapes how you design automations and the cliff arrives without warning.

Frequently asked questions

What am I really buying with a connector?

Somebody else's model of an API — the operations they chose to expose, maintained on their schedule. Usually a good trade, and it means you are limited to their boundary when you need something they did not include.

Is a large connector count a good signal?

A weak one. Platforms advertising large totals include many thin connectors. One deep connector for a system you depend on is worth more than fifty shallow ones, so check depth for the systems that matter to you.

Should I build or buy?

Both, usually. Buy for common systems and for the operational machinery — retries, scheduling, credentials — and build where the system is yours or where the logic is genuinely differentiating and belongs in your codebase.

Why do integration projects stall?

The last ten per cent: the unusual field, the missing connector, the sequence the visual model cannot express. Prototype that during evaluation rather than the demo integration, which works on every platform.

What should I check about pricing?

The model rather than the headline, since per-run, per-connection, and per-user pricing shape how you design. Model your actual pattern at three times current volume, and ask what happens when you exceed the plan.

What breaks integrations most often?

Credential expiry and token refresh, by a wide margin, followed by third-party API changes and rate limits — particularly organisation-wide ones shared with every other tool you run.

What is the most undervalued part of a platform?

The operational machinery. Teams compare connectors and then rebuild retries, backoff, logging, and monitoring themselves in the hand-rolled alternative, which is where the time actually goes.

Who should an integration platform be chosen for?

Whoever will actually build on it. Platforms optimise for engineers, operations teams, or business users, and the mismatch between who it was bought for and who uses it is the usual reason one sits unused.

Can one platform serve several audiences?

Usually, with different patterns and review expectations per group rather than separate tools. Two platforms connecting to the same systems means two sets of credentials, two consumption budgets, and two places to look when something breaks.

What happens when we outgrow it?

Usually not a wholesale migration but a split: the hard integrations move into code while the platform keeps the long tail. Plan for that shape rather than treating it as a failure of the platform.

How portable is what we build?

Not very. Logic expressed in a platform's format generally does not export in a usable form, so treat the flows as something you would rebuild. That is an argument for keeping genuinely differentiating logic in your own codebase.

Related reading

• Automation hubs
• Composable architecture
• API rate limiting explained