Point to point integration vs integration platform: which one fits the problem you actually have

If your team is weighing point-to-point integrations against an integration platform, you're usually staring at one of two piles. The first pile is a growing set of one-off scripts, cron jobs, and bespoke connectors that each did the job on the day they shipped and now nobody wants to touch. The second is a proposal for an integration platform — iPaaS, ESB, or a modern connector suite — that promises to consolidate the mess in exchange for a licence fee and a migration.

This comparison is for engineering and platform leads at established SaaS companies making that call. The short version: point-to-point wins when the integration count is small and stable. An integration platform wins when it's neither. Neither is designed for the newer problem — AI agents reaching your product's internal surface — and we'll come back to that at the end.

How point-to-point integration works

A point-to-point integration is a direct connection between two systems. Product A calls Product B's API, transforms the payload in application code, handles auth in application code, retries on failure in application code, and logs the outcome to whatever observability stack A already runs. There's no middle tier. Each integration is its own small piece of software, usually living inside one of the two systems it connects.

The appeal is real. On day one, point-to-point is the fastest path from zero to a working integration. You don't buy anything, you don't stand up a new runtime, and the engineers who own the source system also own the integration code. When you have two systems to connect, this is unambiguously the right answer. When you have five, it's still defensible. The problem starts when the count grows without the underlying architecture changing.

That's where the term spaghetti integrations comes from. Each new system multiplies the number of possible connections — n systems produce up to n(n-1)/2 pairwise links — and each link carries its own auth handling, retry logic, error taxonomy, and observability quirks. Nothing is shared. When a downstream API deprecates a field, you find every consumer by grep. When a new engineer joins, the map of who talks to whom lives in tribal memory. This is the classic shape of in-house connectors problems: cheap to start, expensive to own, impossible to reason about at portfolio scale.

How an integration platform works

An integration platform sits between systems and standardises the connection. Broadly, three shapes qualify: traditional iPaaS (Workato, Boomi, MuleSoft), embedded iPaaS (Prismatic, Paragon), and unified API vendors (Merge, Nango). The details differ, but the model is the same: connectors are managed as reusable assets, auth is centralised, execution runs on shared infrastructure, and integrations are observable from a single place.

Instead of writing HTTP calls inline in application code, engineers configure a workflow — sometimes in a visual builder, sometimes in code, usually a mix. The platform provides a catalogue of pre-built connectors for common SaaS products, a runtime that executes them, and a control plane where you can see runs, retry failures, and rotate credentials. When a downstream API changes, the platform vendor updates the connector once and every customer benefits. That last claim is the core value proposition, and it's the one that either holds or doesn't depending on the vendor.

The ipaas benefits are strongest when you have many integrations of a similar shape — order syncs, CRM updates, ticket flows — and when your team's time is better spent on product than plumbing. The costs are the licence fee, the vendor lock-in of workflows expressed in a proprietary DSL, and a new operational surface (the platform itself) that has to be monitored, upgraded, and reasoned about alongside everything else.

Comparison

When to choose point-to-point

Stay with point-to-point when the integration count is small (say, under five), the integrations are stable, and the systems on both ends are owned by teams you can call. It's also the right call when the integration is deeply coupled to product logic — a webhook handler that triggers an internal workflow isn't really an "integration" in the platform sense, and pushing it into an iPaaS adds latency and a hop for no benefit.

Point-to-point also wins when the data or auth model is unusual enough that no pre-built connector exists. If you're integrating with a partner's bespoke API, a legacy on-prem system, or an internal service, the platform's connector catalogue doesn't help you and you'd be writing custom code inside the platform anyway — with less flexibility and more indirection than writing it in your own stack.

The one caveat: if you're choosing point-to-point today, budget for connector maintenance cost honestly. The "we'll refactor when it becomes a problem" plan almost never gets funded. Assume every integration will need touching once a quarter and staff accordingly.

When to choose an integration platform

An integration platform earns its licence fee when you have many similar-shaped integrations — dozens of CRM syncs, ticketing flows, or file transfers — and when the teams building them would otherwise be re-solving the same auth, retry, and observability problems in parallel. It's especially strong for embedded integrations shipped as part of your product: a customer-facing "connect your Salesforce" feature is exactly the workload embedded iPaaS was designed for.

It's also the right call when your integration debt has already become a compounding line item. If you're spending a meaningful share of engineering time on integration maintenance — MuleSoft's 2026 Connectivity Benchmark Report puts IT teams at 36% of their time on custom integrations versus innovation, down from 39% the year before, though we'd treat that number as directional rather than gospel — then consolidation onto a platform is a defensible way to buy that time back.

What a platform won't do is fix a bad decomposition. If the reason you have thirty integrations is that your product boundaries are wrong, moving them into iPaaS moves the problem without solving it. The platform will faithfully run the wrong integrations on shared infrastructure and hand you a bill for the privilege.

How Pontil fits

The comparison above is the right one when the consumers of your integrations are humans, batch jobs, or other services. It's the wrong frame when the consumer is an AI agent working on behalf of an authenticated user inside your product.

Both point-to-point and integration platforms assume the API surface already exposes what the caller needs. In most established SaaS products, it doesn't — the UI can do a hundred things the API can't, and agents inherit that gap. That's the problem Pontil's Tools-as-a-Service platform is built for: we scan the codebases you already own, generate the tool surface agents need against the APIs and internal functions that already exist, and run them at the boundary as the authenticated user rather than a shared service account.

It's a different layer from iPaaS, which connects systems, and different from point-to-point, which hard-wires them. If your integration debt is really an agent access problem in disguise, book a walkthrough — the diagnosis is usually clearer once you've looked at your own numbers.

What we'd choose

For two to five stable integrations owned by one team: point-to-point. The overhead of a platform isn't worth it and never will be at that scale.

For a portfolio of similar-shaped integrations — especially embedded ones shipped to customers — an integration platform. Pick the shape that matches the workload: unified API for read-heavy sync, embedded iPaaS for customer-configurable flows, traditional iPaaS for internal system-to-system work.

For exposing your own product to AI agents: neither, on its own. That's a tools-layer problem, not an integration problem, and treating it as one is how agent projects end up 18 months in with a stack of connectors that still can't do what the UI can. Get the framing right first; the tooling choice follows from it.