Do you still need an iPaaS when Claude Code can write your integrations?

Claude Code made integration code cheap to write. Running it, securing it, and keeping it working cost what they always did. If you have a handful of integrations, engineers willing to own them on call, and logic that belongs in your product, building them yourself is now a reasonable default. An integration platform earns its cost when the count outgrows what one team can watch, when people outside engineering need to change workflows, or when someone has to show an auditor where credentials live and who called what. The platforms worth shortlisting now are the ones your engineers can build on from Claude Code, so the choice no longer has to be either-or.

Somebody on your team has probably asked the question already. Claude Code wrote a working Salesforce-to-NetSuite sync in an afternoon, so why is the company paying for an integration platform? It deserves a straight answer, and the answer depends on what happens to that sync after its first successful run.

What Claude Code changed, and what it left alone

The first version of an integration used to be the slow part. Someone had to read the API documentation, work out the authentication, map the fields, handle pagination, and write the tests. Claude Code does most of that from a description, and a competent engineer can have a working sync by the end of the day.

Everything after the first run is unchanged. An OAuth token expires on a Saturday, and the sync stops quietly until someone notices on Tuesday that the pipeline numbers look low. A vendor renames a field in a minor API release, and records start arriving with blanks. A rate limit tightens, and a job that ran cleanly at 5,000 records starts dropping some at 50,000 without raising an error. The engineer who wrote it moves to another team, and the next person to open the repository has to work out what it does before they can fix it.

Each of those is caught by monitoring and fixed by an owner. Claude Code can write the fix once someone knows it’s needed, but it doesn’t know on its own that anything broke.

When building it yourself is the right call

For a lot of teams, building is the right answer. It usually is when most of these are true:

• You run a small number of integrations, and that number isn’t growing quickly.
• The integration is part of your product, and the logic inside it is something you compete on.
• Your engineers want to own the runtime and already carry on-call for services like it.
• The systems involved are ones your team knows well.

If that describes you, put the integration in your own codebase, review it like any other service, and give it monitoring and a named owner from the first day. Claude Code makes that cheaper than it has ever been.

Where it tips the other way

The case for a platform tends to build gradually, and it usually arrives as one of four signals.

The count outgrows the team. Ten integrations are a side job. Forty are a system, with shared credentials, overlapping schedules, and failures in one that show up in another. Someone has to see all of them in one place, and building that view is a project of its own.

People outside engineering need to change things. RevOps wants a new field mapped, finance wants an approval step, and support wants a different routing rule. If every change becomes an engineering ticket, the queue that Claude Code shortened grows back, and teams start building around it.

A security review asks where the credentials are. Security teams and auditors ask where credentials live, who can use them, what each integration did and when, and what happens when the person who built it leaves. Across a set of individually built services, the answer has to be assembled too.

Agents need the same systems. Once AI agents start reading and writing to the CRM and the ERP, your integrations become their tools. Every question about identity and audit now applies to each call an agent makes, which is where governing the MCP tools your team builds comes in.

Who handles what

The difference between the two paths is who carries each of these responsibilities once the integration is live.

The right-hand column is what a platform charges for. Owning the left-hand column is a legitimate choice, as long as it’s a deliberate one and someone is named against each row.

What to look for in a platform if your team lives in Claude Code

Buying a platform used to mean moving engineers out of their editor and into a visual builder. That’s the part to check hardest now, because it decides whether engineers will use the platform at all. Four questions sort the options quickly:

• Can engineers build from Claude Code, or does the platform expect them to switch to its own canvas?
• Does what they build inherit the platform’s access control, audit, and credential handling from the start, or is governance a separate step later?
• Can people outside engineering still see and change a workflow an engineer built in Claude Code?
• Can the same integrations be published as governed MCP tools for AI agents without a second build?

Vendors answer these in different ways. Workato’s AIRO MCP server exposes a Workato workspace to Claude Code, Claude Desktop, and Cursor, so engineers can build recipes from the assistant.¹ Tray Headless does the equivalent for Tray, with dedicated plugins for Claude Code and Codex and an MCP server for other assistants.² Ask each vendor to show it working on one of your own integrations. For teams weighing the two directly, here’s how to choose between Tray.ai and Workato.

Tray.ai or building it yourself with Claude Code

If you’re weighing Tray specifically, the choice is less binary than the question suggests, because Tray is built to be used from Claude Code.

An engineer describes an integration, an automation, an MCP tool, or an agent in Claude Code, and Tray Headless scaffolds it on Tray’s 700+ connectors, wires up the authentication, and validates each step and the whole workflow before it reaches production.² Connectors Tray doesn’t have yet can be generated from an OpenAPI spec with the Tray CDK, which also works with Claude Code.³ Tray Headless is included in every plan.⁴

What the engineer doesn’t build is the right-hand column of the table above. Access control, audit trails, and credential handling come from the platform, retries aren’t charged against your usage, and workflows run in parallel without a fixed concurrency quota and for up to 14 days.^4,5 An ops team member can open the same workflow in Tray Build’s visual canvas and extend it without touching Claude Code.²

Teams using Claude Code also build small internal apps, and those need somewhere to run too. Tray Helix takes them to production with one command, connects them to your systems through managed credentials, and runs them on Tray’s managed runtime, with an owner for every app.⁴

Tray is the wrong fit for an integration that is your product and that your engineers want to own at every layer. Build that one yourself.

For the rest, test it rather than debate it. Pick three integrations that represent your real work: a simple sync, a multi-step process with branching, and one with awkward authentication. Build each with Claude Code on its own, then again with Claude Code on Tray during the 30-day free trial, which needs no card and no sales call.⁴ Compare time to production, what happened the first time something failed, and who could maintain each one if its builder left. If cost is part of the decision, here’s how Tray pricing behaves as usage grows.

Sources

1. Workato documentation, AIRO, read October 2026: https://docs.workato.com/en/airo
2. Tray.ai, Tray Headless: https://tray.ai/platform/ai-development/tray-headless/
3. Tray.ai blog, Tray CDK now works with Claude Code: https://tray.ai/blog/build-ipaas-connectors-claude-code-tray-cdk/
4. Tray.ai, pricing: https://tray.ai/pricing/
5. Tray.ai, Tray.ai vs Workato: https://tray.ai/compare/tray-vs-workato/