- Datadog, Vault, SQS, Temporal, Lambda, and GitHub Actions each solve one piece, but none know the others exist. B2B SaaS teams managing integrations in-house end up with a stack, not a single tool, and eventually a second engineering team to make it work.
- Each mature tool category requires you to add customer and tenant context. Datadog doesn't know an execution belongs to Customer A's NetSuite integration running version 12; a secrets manager stores a token but doesn't know it's about to expire or give a customer a way to reconnect without a ticket.
- An in-house integration platform is usually built one piece at a time without anyone deciding to build it. A basic OAuth handler, then reusable retry logic, then a scheduler, then an internal dashboard for support turn into a full system with no formal name, roadmap, or owner.
- A stitched-together stack stops making sense when certain signals appear. These include engineers rebuilding the same auth pattern per integration, deploying to a new customer requiring an engineer, and integration support tickets escalating to engineering by default.
- An embedded iPaaS provides much of the integration-specific slice of every other category into one platform. It doesn't replace Datadog, PagerDuty, or other systems in your stack so much as remove the need to hand-build tagging, dashboards, and alert rules for every integration shipped.
You built the integration. It authenticates correctly, moves the right data, and passes every test in staging. Now you have to run it in production for every customer who turns it on.
That means you need somewhere for the code to execute. You need to store each customer's credentials securely. If the integration receives webhooks, you need infrastructure to receive, verify, and queue them. If it polls instead, you need a scheduler. You need retry logic for the failures that are nobody's fault, logs for the ones that are, alerts so you find out before your customers do, and a way to ship an update to several tenants at once (while leaving others untouched).
None of these problems is new. Mature tools exist for nearly every one of them. Datadog can give you observability. Vault can hold your secrets. SQS can queue the work. Temporal can orchestrate it. Lambda can run it. GitHub Actions can deploy it.
But while your integration needs all these apps to behave like one system, none of them knows the others exist.
That's why B2B SaaS teams that manage integrations in-house rarely end up with an integration infrastructure tool. Instead, they end up with an integration infrastructure stack. And eventually, a second engineering team whose job is to make all those tools work together.
What integration infrastructure must do
An integration can look simple from the outside: a customer connects Salesforce, fills in some configuration, and data starts moving. Underneath, a production-grade version of that same integration depends on infrastructure for:
- Authentication and credential management, per customer
- Inbound webhook traffic, or scheduled polling if the third party doesn't support webhooks
- Queues and asynchronous processing for anything beyond trivial volume
- Retry logic that can tell a transient failure from a permanent one
- Compute to run the code
- Logging, metrics, and alerting that make sense per customer
- Deployment and version management across every customer instance
- Customer-specific config and state
Turns out, it's serious work to handle all of this the same way across dozens of integrations and hundreds of tenants simultaneously.
The popular tool categories
Here's the infrastructure that B2B SaaS teams typically assemble over time.
Observability and monitoring
Popular tools: Datadog, New Relic, or the Elastic stack.
These platforms are built to answer "Is our infrastructure healthy?" and they answer it well.
However, they weren't built with customers or tenant context. Datadog understands services and traces. It doesn't inherently know that a given execution belongs to Customer A's NetSuite integration, is running version 12, and failed at the create-invoice step because that customer's OAuth token expired. Getting from raw logs to "Why did customer A's sync fail?" means your team has to design tagging conventions, build the dashboards, and wire all the alert rules for every integration you ship.
Secrets and credential management
Popular tools: HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault.
These tools handle encryption at rest, access control, and rotation policies, and they're the right tools for the job.
What they don't solve is credential lifecycle management. Storing an OAuth token securely is different from knowing when it's about to expire, refreshing it automatically, detecting that it's been revoked, and giving the customer a way to reconnect without opening a ticket. Multiply that by every third-party API your integrations connect with, each with its own OAuth, and the secrets manager handles the easy part of the problem.
Webhooks
Popular tools: Hookdeck or something built on SQS/SNS or Kafka.
Webhooks look simple until you're running them in production. Events can arrive more than once, out of order, or not at all. Implementation differs by vendor. Your endpoint might be briefly unreachable. Tools in this category handle receipt, validation, queuing, and retry for inbound events, and they do a lot of work.
They stop at "the event arrived intact." Mapping that event to the right customer, the right integration instance, and the right action is still on you, and it's different for every one.
Queues
Popular tools: AWS SQS, Apache Kafka, or RabbitMQ.
Integration workloads are built for asynchronous processing: one customer syncs 100 records while another syncs 100,000, and a downstream API can go offline for half an hour without warning. Queues decouple that work from the request that triggered it, which is foundational infrastructure for any system operating at scale.
A queue doesn't know what an integration failure means, though. Your team still has to decide which errors are retried, how many times, what happens to a job that lands in a dead-letter queue, and how to keep one high-volume customer from starving every other customer's throughput. The queue organizes/moves the work, but you still have to determine the policy that it needs to follow.
Workflow orchestration
Popular tools: Temporal or AWS Step Functions.
For multi-step integrations (receive a new hire from an HRIS, provision downstream apps, wait on an async step, notify a manager, write back to the source system, etc.), orchestration engines generally provide durable state, retries, and the ability to resume instead of restarting from step one.
These engines are great for internal pipelines with one audience: your own engineers. They don't understand a workflow that represents a customer-facing integration, configured differently for two hundred tenants, with several versions live in production and a support team that needs to see what's happening without reading the workflow definition.
Compute and scheduling
Popular tools: AWS Lambda, Google Cloud Run, or Kubernetes for compute; EventBridge Scheduler, Cloud Scheduler, or cron for scheduling.
Serverless compute is attractive. A webhook comes in, a function runs, you're done. It remains attractive until one integration becomes thirty, and thirty become two hundred customer-specific instances, each with its own config and schedule. The same thing happens with scheduling: running one polling job on a timer is trivial, but giving each customer their own interval and pausing individual instances is a different, much larger problem than cron was built to solve.
Feature flags and CI/CD
Popular tools: LaunchDarkly or Split for feature flags; GitHub Actions, GitLab CI, or CircleCI for deployment.
Mature engineering teams have CI/CD pipelines, and feature flags are the standard way to ship changes safely. Both are the right tools for shipping code.
Integration configuration is rarely a boolean. It can include credential references, field mappings, schedule overrides, and per-customer settings that must stay consistent across hundreds of live instances. Deploying an integration update usually means rolling it out across those instances without disrupting the customers who haven't opted into the new version yet. That's a more specific deployment problem than general CI/CD and feature-flagging tools were built to solve.
Unified APIs
Popular tools: Merge, Finch, or Apideck.
Unified APIs normalize a single schema across several vendors within one category. One API to read from any HRIS, or any CRM, rather than a separate integration per vendor. For simple, read-heavy sync use cases, that abstraction can seriously reduce the number of connectors you maintain.
The tradeoff is the abstraction itself. Unified APIs optimize for normalized coverage, with provider-specific functionality varying by vendor. However, when customer needs a field the normalized schema doesn't expose, a write operation the API doesn't support, or a workflow specific to one vendor, you're back to building a custom integration anyway. And then maintaining both patterns forever.
Embedded iPaaS
Popular tools: Prismatic, Cyclr, or Workato Embedded.
This is the one category that isn't solving a single piece of the puzzle. It exists specifically to provide many of these capabilities for the B2B SaaS integration use case: per-tenant execution logging and alerting, credential handling built around OAuth-per-customer, pagination and rate limits, queuing and retry behavior tuned for third-party API failures, and deployment tooling built around rolling out updates to myriad live customer instances.
The integration platform you build yourself
It's rare for anyone to sit down and decide to spend two years building an in-house integration platform. Instead, it happens in bits and pieces. The first integration gets a basic OAuth handler. The third one needs better retry logic, so someone makes it reusable. The fifth needs scheduled executions. Then, support needs visibility into integration state, so someone builds an internal dashboard. Customers need varied field mappings, so someone designs a configuration wizard to support them. Deployments get rather risky, so someone adds version tracking.
Add it up, and you have a connection service, an OAuth framework, a scheduler, an execution framework, retry conventions, tenant routing, a configuration schema, deployment tooling, logging conventions, and an admin UI to answer questions like "Which version of this integration is this customer running?" That's an integration platform. It may not have a formal name, roadmap, or owner, but it's a full system in its own right.
And it has to be maintained like every other product your engineering team owns. Each tool in the stack does its job well. The often hidden cost comes from the time and effort engineering puts in to keep all the pieces together and make things work. And that's engineering time that isn't going toward the integrations themselves (or the core product).
Stack or platform: how to decide
A stitched-together stack can be a reasonable choice. It tends to make sense when:
- Your integration catalog is small and isn't expected to grow much.
- You need unusually deep, non-standard control over execution infrastructure.
- You already have a platform engineering org that owns the relevant systems, and the incremental cost of one more integration is low.
But that choice no longer makes sense when:
- Engineers keep rebuilding the same auth, retry, or error-handling pattern for each integration.
- Deploying an existing integration to a new customer requires an engineer.
- Integration support tickets escalate to engineering by default.
- Nobody can quickly answer which customers are running which version of an integration.
- Tracing a single failed execution means moving across three or four different tools.
- The team maintaining your integration infrastructure is becoming a bigger line item than the team building the integrations.
| Stitched-together stack | Embedded iPaaS | |
|---|---|---|
| Per-customer visibility | Usually bolted on after the fact, via custom tagging | Built in as a first-class concept |
| Credential lifecycle | Storage solved; refresh, revocation, and reconnection UX are custom | Handled per tenant, including customer-facing reconnection |
| Deployment across live instances | Custom versioning and rollouts | Built to roll out updates to many tenants at once |
| Who owns the glue code | Your engineering team, indefinitely | The platform vendor |
| New integration costs | Auth, retries, and logging again | Shared infrastructure; reusable code |
Does building and maintaining this infrastructure differentiate your product?
Your customers care whether their Salesforce data shows up on time and whether you fix a broken sync fast. They rarely care if your team wrote the credential-refresh service or the deployment pipeline that makes it possible.
Where an embedded iPaaS like Prismatic fits
Prismatic doesn't try to replace Datadog or PagerDuty so much as it removes the need to hand-build integration-specific context for them. Execution logging is per-customer and per-run, and it still streams to Datadog, New Relic, or whatever you already use. Alert monitors already understand what a connection exception or a missed nightly sync looks like, and route to Slack or PagerDuty just the same. Credentials are handled per tenant, including OAuth refresh and a customer-facing reconnection flow, instead of a general-purpose secrets manager that has no concept of a customer. Pagination and rate limits are abstracted at the platform level rather than hand-coded per integration. Deployment is built to roll out updates to live customer instances, so it fits alongside your existing CI/CD rather than replacing it.
In short, Prismatic is one platform standing in for the integration-specific slice of several categories above, so your team doesn't have to build and maintain that slice themselves.
The bottom line
You don't get to pick zero tools for managing integration infrastructure. Every category on this list solves something real, and many teams will keep using them regardless of what else they adopt.
However, you get to choose how much of the integration-specific layer (the part that understands customers, tenants, versions, and credentials) you want your own engineers to build and maintain indefinitely, versus how much you'd rather hand to a platform designed for that job.
Ready to see what that looks like in practice? Start a free trial or get a demo.
