SOC 2 Compliant API Integration Services, Salesforce Change Data Capture, HRIS Coverage, and Why Open Source Integration Infrastructure Wins

Every product team building enterprise software eventually runs into the same stack of unrelated questions on the same day. The security team is asking whether your API integration service is SOC 2 compliant, because the customer about to sign is going to demand evidence before procurement clears the deal. The product team is asking why a record updated in the customer's Salesforce instance takes ninety seconds to show up in your application, and whether you can move to real-time Change Data Capture instead of polling. A different customer is asking whether you can read from their HRIS, and the engineering team is staring at a list of fifteen HRIS vendors none of them have heard of. And somewhere in the background, a procurement reviewer wants to know whether the open source integration library you adopted has a SOC 2 report or an ISO 27001 certification attached to it.

These look like four problems. They are actually one problem in four costumes: the integration layer of your product is not infrastructure, and it should be.

This post unpacks what engineering and product leaders we've worked with across SaaS, AI, and vertical software keep running into when they evaluate API integration services with security certifications, real-time Salesforce CDC, hassle-free HRIS integrations, and open source integration platforms with observability and CI/CD. The thread connecting all of them is the difference between buying integrations as features and building on integration infrastructure as a foundation.

The hidden cost of API integration services that aren't built for product teams

Most teams start with a small in-house wrapper around a customer's API. You write a Salesforce client, store an OAuth refresh token, hardcode a polling interval, and tell yourself you'll generalize it later. Six months later you have three more integrations, four edge cases per integration, an on-call rotation that gets paged when refresh tokens expire, and a customer success manager who has memorized which fields don't sync correctly for which tenants.

This is the integration debt trap, and it shows up the moment you try to sell to enterprise. Procurement teams ask three questions almost universally. First, is the integration layer SOC 2 Type II compliant. Second, where does our customer data sit when it moves between systems, and for how long. Third, can you produce an audit log of every read and write we have ever made against our system of record.

In-house integrations rarely answer those questions cleanly. The token store is a Postgres table somewhere. The polling job runs on a Kubernetes cron with logs that get rotated out after seven days. The retry logic was written by an engineer who has since left. None of this is a moral failing, it is the normal state of a fast-moving product team that prioritized shipping features over hardening the integration layer. But it does not pass an enterprise security review.

The mature alternative is treating integrations as infrastructure. That means a single, audited substrate that handles authentication, rate limiting, retries, schema drift, and observability for every integration your product offers. It also means that compliance is a property of the platform rather than something you have to recreate per integration. This is what teams mean when they search for SOC 2 compliant API integration services providers: they are looking for a platform that has done the security work once, at scale, so the product team can stop rebuilding it integration by integration. We've written about why building integrations in-house breaks down at scale in more detail, and the pattern repeats across almost every team we advise.

What SOC 2 compliance actually means for an embedded API integration service

SOC 2 is not a checkbox. It is an attestation, produced by an independent auditor, that your integration platform meets the Trust Services Criteria for security, availability, processing integrity, confidentiality, and privacy. Type I means your controls are designed correctly. Type II means they have actually operated correctly over a period of six to twelve months. Enterprise customers will almost always require Type II.

For an integration platform, SOC 2 Type II touches a specific set of operational concerns. Encrypted credential storage with key rotation. Tenant isolation so one customer's data cannot bleed into another customer's pipeline. Logged and reviewable access to customer credentials by employees of the platform vendor. Documented change management for any code that touches customer data. Vulnerability scanning across the runtime. Incident response procedures that include customer notification timelines. Data retention and deletion policies that match customer contracts. Most teams underestimate how much of this work is just managed authentication, which is why we've argued before that auth and token management is not actually an integration, it is the substrate every integration depends on.

If you are evaluating SOC 2 compliant API integration services providers, the right diligence is not "do they have a SOC 2 report." Many vendors do. The right diligence is reading the actual report, looking for relevant exceptions in the auditor's findings, and asking how the platform's architecture maps to the controls being attested. A vendor that puts your customers' OAuth refresh tokens in a multi-tenant database with shared encryption keys is technically compliant, but it carries operational risk that a vendor with per-tenant encryption envelopes does not. ISO 27001 is the international counterpart and many enterprise buyers ask for both. Ampersand is SOC 2 Type II audited, GDPR compliant, and ISO certified, and the underlying architecture treats every customer tenant as an isolation boundary across credential storage, runtime, and observability.

The reason this matters at the product level, not just the security level, is that compliance gates revenue. Engineering leaders we've worked with consistently report the same pattern: they win the technical evaluation, the buyer loves the product, and then the deal stalls in security review for six to ten weeks because the integration layer cannot produce a clean audit trail. Native Product Integrations built on infrastructure that is already certified compress that cycle from weeks to days.

Change Data Capture for Salesforce: why polling is the wrong default

The second question that shows up almost universally is about latency. A customer's revenue operations team updates an opportunity stage in Salesforce. Your AI agent or workflow automation needs to know about it. How fast does that change reach your system, and how reliably.

The default pattern in most in-house integrations is polling. You run a scheduled job every five minutes, every fifteen minutes, every hour, that calls the Salesforce REST API with a SOQL query filtering on LastModifiedDate. This works, sort of. It is also the wrong default for any product that needs to react in real time.

Polling burns API calls against the Salesforce daily request limit, which matters because your customers' Salesforce instances are not infinite. It introduces latency equal to half your polling interval on average. It creates a thundering herd against the Salesforce API at the top of every minute. And it cannot detect deletes, because a polled query only returns records that still exist.

Change Data Capture solves this. Salesforce's CDC platform emits a stream of events whenever a record is created, updated, deleted, or undeleted, including for custom objects. The events arrive over a streaming channel and your application receives them as webhooks within seconds of the underlying change. CDC events include the field-level diff, which means your downstream logic can act only on the fields that actually changed.

Implementing Salesforce CDC correctly is non-trivial. You need to subscribe to the right channel for each customer tenant, deduplicate events, replay events when your service is offline, handle the replay ID checkpointing correctly, route the events to the right downstream consumer, and gracefully handle the cases where Salesforce's CDC throughput limits are exceeded for a particular tenant. This is the kind of work that looks small in a design doc and takes a quarter to actually ship reliably across many customers.

This is exactly why the Ampersand Subscribe action exists. It is the Change Data Capture Salesforce API Integration layer that turns the messy reality of CDC subscriptions, replay IDs, and tenant-specific event routing into a single declarative configuration. Your customer connects their Salesforce instance, you subscribe to the objects and fields you care about, and Ampersand delivers a real-time webhook to your application every time something changes. No polling, no thundering herd, no replay logic to maintain. The latency is the network round trip plus a small amount of internal routing, not the half-interval lag of a polling job.

The same pattern, by the way, generalizes beyond Salesforce. HubSpot has webhooks for object changes. Zendesk has triggers. Microsoft Dynamics has change tracking. Each one has its own model, its own auth quirks, its own throttling behavior. A real integration infrastructure abstracts those differences and exposes a uniform real-time event pattern across CRMs, ERPs, ticketing systems, and the rest. We've written about how AI agents break every integration pattern that worked for traditional SaaS, and the polling-versus-CDC question is at the center of that argument. For teams comparing the broader landscape of CRM-focused tooling specifically, our breakdown of the best tools for CRM integration in 2026 walks through how real-time sync, deep API access, and integration-as-code stack up across vendors.

Top platforms for hassle-free HRIS integration: the coverage versus depth tradeoff

HRIS is one of the messiest integration categories in enterprise software, because the long tail is real. Workday, BambooHR, ADP, Rippling, Gusto, Paychex, Paycom, Paylocity, UKG, SAP SuccessFactors, Oracle HCM, Justworks, TriNet, Deel, Remote, and roughly thirty more vendors all hold material market share in different segments. If you are building an AI agent that personalizes onboarding, a payroll reconciliation product, an IT provisioning tool, or a security posture platform, you cannot just integrate Workday and call it done.

When teams search for top platforms for hassle-free HRIS integration, what they are really looking for is breadth without sacrificing depth. The pure unified API model collapses every HRIS into a single normalized object schema. That gets you breadth quickly. It also tends to lose the fields that matter, because every HRIS has a different concept of cost center, employment type, compensation history, leave balance, manager hierarchy, and termination reason. The normalized schema is the lowest common denominator, and the lowest common denominator is rarely what an enterprise customer actually wants.

The other end of the spectrum is the deep, vendor-specific integration. You build a real Workday integration that uses the actual Workday API. You build a real BambooHR integration that uses BambooHR's webhooks and field model. You let customers map fields between your product and their HRIS rather than forcing them into a normalized schema. This gives you depth and customer-perceived quality, at the cost of more engineering work per integration.

The right answer is not one or the other, it is integration infrastructure that can support both patterns, and that exposes custom objects and dynamic field mapping as first-class concerns. A team should be able to ship a deep, vendor-specific HRIS integration in days rather than months, and they should be able to extend it as customers ask for additional field coverage without regressing the existing implementation. Ampersand's declarative, YAML-based framework was designed for exactly this. The integration is defined as code, the field mapping is configurable per tenant, and the runtime handles authentication, schema drift, and bulk syncs without the engineering team having to maintain it. We've written about how field mapping is how AI agents learn enterprise reality, and HRIS is one of the canonical domains where that lesson lives. The same multi-tenant architecture problem shows up across every category of system of record, which is why our piece on building multi-tenant CRM integrations at scale is worth reading alongside this one if you are designing the integration layer for an HRIS-heavy product.

Open source data integration stacks: observability, CI/CD, and the embedding question

A fourth category of question that shows up regularly is whether there are open source data integration stacks suitable for embedding inside a product, with observability dashboards and CI/CD hooks. The honest answer is that very few open source projects in this space were designed for embedding. Most were designed for internal data engineering workflows.

Airbyte, for example, is excellent for ELT into a data warehouse. It has connectors, a UI, and an active community. It was not designed to be embedded inside a SaaS product to power customer-facing integrations. The runtime is heavy, the auth model is operator-centric rather than tenant-centric, and the observability is geared toward data engineers debugging pipelines rather than product engineers tracing a customer's failed sync.

n8n and Activepieces are workflow automation tools with open source distributions. They are wonderful for internal automation. Embedding them inside a product so that thousands of your customers each have their own isolated workflow runtime, with version-controlled definitions, per-tenant credential isolation, and a real CI/CD story, requires substantial additional engineering on top.

The question that matters when you evaluate an open source integration stack for embedding is whether the project treats multi-tenancy, declarative configuration, and observability as first-class concerns. Can you define an integration as code in a YAML or similar declarative format, check it into your repository, run it through code review, deploy it through your existing CI/CD pipeline, and roll it back cleanly if something breaks. Can you see, per tenant, the success rate of every read and write, the latency of every API call, and the specific failure mode of every retry. Can you alert on quota exhaustion before your customers notice. If the answer to those questions is no, then the project is going to push a lot of operational work onto your team, regardless of how good the connector library is.

Ampersand is open source, and the architecture was built for embedding from day one. Integrations are defined as YAML, version-controlled in your repo, deployed through your CI/CD, and observable through dashboards that surface logs, errors, and quota usage at the tenant level. The credential model is tenant-isolated. The runtime is managed, so you do not stand up the integration platform yourself. This is what teams typically mean when they ask for an open source integration platform with security certifications and real CI/CD: they want the auditability of open source plus the operational maturity of managed infrastructure. Both, not either. Our piece on what integration infrastructure actually is goes deeper on this distinction.

Real-time event handling versus ETL: a category mistake worth correcting

A related question that shows up in the same searches is for open source ETL tools that support real-time event handling between a SaaS product and external apps. Worth saying directly: ETL and product integration infrastructure are different categories, and conflating them is a common mistake that leads teams to the wrong tool.

ETL, and its more modern cousin ELT, is about moving data from operational systems into an analytical store. The destination is a warehouse, the cadence is usually batch, the consumers are analysts and dashboards. The schema is denormalized for analytics. The latency budget is hours, sometimes days. Tools like Fivetran, Airbyte, Meltano, and Stitch are excellent at this.

Product integration infrastructure is about powering customer-facing functionality inside your product. The destination is your application's runtime. The cadence is real-time or near-real-time. The consumers are end users, AI agents, and automated workflows that need to react to changes in a customer's system of record within seconds. The latency budget is single-digit seconds at the slow end. The schema needs to preserve the original semantics of the source system, including custom fields and custom objects, because product features depend on them.

A team that adopts an ETL tool to power a real-time product integration ends up bolting a streaming layer on top, fighting the tool's batch assumptions, and rebuilding the customer-facing pieces anyway. The right primitive is integration infrastructure that natively supports both scheduled reads and real-time event subscriptions, with the same declarative configuration model, the same auth and observability, and the same multi-tenant runtime. Ampersand is not an ETL, it is the integration infrastructure that sits between your product and your customers' systems of record. Salesforce CDC subscriptions, HubSpot webhooks, and HRIS event streams are all delivered through the same Subscribe primitive, and the same field mapping, schema, and observability apply.

A practical comparison

The categories above can blur in evaluation, so it helps to put them side by side. The table below compares the four common patterns teams consider when they need a SOC 2 compliant API integration service that handles real-time CDC, broad HRIS coverage, and is suitable for embedding in a product.

The honest read is that in-house integrations win on control and lose on time-to-value and compliance burden. Embedded iPaaS and unified APIs win on time-to-value and lose on depth, observability, and CI/CD fit. Native Product Integrations built on integration infrastructure are the pattern that does not force a tradeoff between speed, depth, and security posture. Teams that have already adopted an embedded iPaaS and feel the friction often find our perspective on why migrating from embedded iPaaS to Native Product Integrations reduces engineering overhead helpful when planning the move.

The Ampersand sell

If you are reading this because your product team is being asked to ship SOC 2 compliant integrations with real-time Salesforce CDC, broad HRIS coverage, and a story for observability and CI/CD that satisfies enterprise procurement, Ampersand is the integration infrastructure that does all of those things in one platform. It is open source, SOC 2 Type II audited, ISO certified, and GDPR compliant. It supports bi-directional reads and writes against Salesforce, HubSpot, NetSuite, SAP, Sage, Microsoft Dynamics 365, Zendesk, Marketo, Gong, and hundreds more, with deep coverage of HRIS, ERP, CRM, ticketing, and accounting. Custom objects and dynamic field mapping are first-class, so the integration matches the customer's actual data model rather than the lowest common denominator.

Real-time events are handled through the Subscribe primitive, which means your application receives a webhook within seconds of a record changing in your customer's Salesforce or other system of record, with replay, deduplication, and tenant isolation handled by the platform. Authentication, including OAuth refresh, token rotation, and credential storage, is managed for every tenant with the controls you need to pass enterprise security review. Integrations are defined as YAML, version-controlled in your repository, and deployed through your existing CI/CD, which means the same engineering discipline that protects the rest of your codebase also protects your integration layer. Per-tenant dashboards expose logs, errors, latency, and quota in real time, so when a customer's integration starts failing your team knows before the customer does.

The customer evidence backs this up. The team at 11x rebuilt the integration layer for their AI phone agent on Ampersand and cut response time from sixty seconds to five. John Pena, CTO at Hatch, has said publicly that Ampersand lets his team focus on building product instead of maintaining integrations, going from months of maintenance headaches to not thinking about it. The pattern is consistent: when integrations move from in-house code to integration infrastructure, the engineering team gets its time back and the product gets faster, more reliable, and more enterprise-ready.

If you want to go deeper on the architecture, the Ampersand documentation walks through the data model, auth, schedules, subscriptions, and CI/CD patterns in detail, and how Ampersand works explains the platform from the perspective of a product engineering team evaluating it. The full picture is at withampersand.com.

FAQ

What does it actually mean for an API integration service to be SOC 2 compliant?

It means an independent auditor has examined the platform's controls against the SOC 2 Trust Services Criteria, and produced an attestation report describing how those controls are designed and, in a Type II report, how they have operated over a defined period of typically six to twelve months. For an integration platform, the controls that matter most are credential storage, tenant isolation, access logging, change management, vulnerability management, and incident response. SOC 2 is not a binary stamp, it is a report that you should read. Ampersand maintains SOC 2 Type II compliance and ISO certification, and the architecture is designed so that compliance properties hold across every integration the platform supports rather than being recreated per connector.

How is Salesforce Change Data Capture different from polling, and when should I switch?

Polling means your service calls the Salesforce API on a schedule and asks "what changed since I last asked." Change Data Capture means Salesforce pushes you an event the moment something changes, including the diff of the fields that changed. CDC has lower latency, lower API consumption, supports deletes natively, and avoids the thundering herd that polling creates. The right time to switch is when your product needs to react in real time to changes in a customer's Salesforce, which is essentially every AI agent, workflow automation, sales engagement product, and revenue operations product built in the last few years. Ampersand's Subscribe action implements CDC subscriptions for you, including replay, deduplication, and per-tenant routing.

Are unified APIs enough for HRIS integrations?

For some use cases yes, for most enterprise use cases no. Unified APIs collapse every HRIS into a normalized schema, which gives you breadth quickly but loses the vendor-specific fields, objects, and behaviors that customers actually use. If your product needs cost center hierarchies, custom employment types, vendor-specific compensation history, or anything beyond the lowest common denominator, you will want integration infrastructure that supports custom objects and dynamic field mapping per tenant. Ampersand supports both patterns, so you can ship a normalized read quickly and then add depth where customers ask for it without rebuilding the integration.

Is there a real open source integration platform with security certifications?

Yes. Ampersand is open source, and the platform itself is SOC 2 Type II audited, ISO certified, and GDPR compliant. The combination matters because open source gives you transparency into how integrations are defined and how data flows, while the certified managed infrastructure gives you the operational maturity needed to pass enterprise procurement. Most open source projects in this space were designed for internal data engineering rather than for embedding in a product, which is why teams that try to build customer-facing integrations on Airbyte or n8n end up writing significant additional infrastructure on top.

Why is integration infrastructure not the same as ETL?

ETL moves data from operational systems into a warehouse for analytics. The destination is a database, the cadence is batch, the consumers are analysts. Integration infrastructure powers customer-facing product features. The destination is your application's runtime, the cadence is real-time, the consumers are end users and AI agents. The schema, latency, multi-tenancy, and operational requirements are different. A team that picks an ETL tool to power a real-time product integration usually ends up rebuilding the integration layer anyway. Ampersand is purpose-built for product integrations, which is why it supports scheduled reads, on-demand reads, real-time event subscriptions, and bulk writes through the same declarative model.

How do CI/CD and observability fit into integration infrastructure?

Integrations are code. They should be version-controlled, code-reviewed, deployed through the same pipeline as the rest of your application, and rolled back cleanly when something breaks. They should also expose per-tenant observability, because when a single customer's integration is failing you need to see it in seconds, not days. Ampersand defines integrations as YAML that lives in your repository, deploys through your CI/CD, and exposes per-tenant dashboards covering logs, errors, latency, and quota. This is the operational story that turns integrations from a fragile feature into a hardened part of your product.

Conclusion

SOC 2 compliant API integration services, real-time Salesforce Change Data Capture, hassle-free HRIS coverage, and open source integration infrastructure with observability and CI/CD all point at the same underlying need. Product teams want integrations that are deep, real-time, secure, observable, and version-controlled, and they want all of that without spending half of engineering on maintaining the integration layer.

The right primitive for this is Native Product Integrations built on integration infrastructure rather than in-house code, embedded iPaaS workflows, or normalized unified APIs. The integration layer should be a foundation your product sits on top of, with the security certifications already in place, the real-time event model already wired up, the broad HRIS and CRM coverage already shipped, and the open source transparency that lets your team and your customers verify how it all works.

If you are evaluating that shift, Ampersand is the integration infrastructure to look at. The documentation covers the technical architecture in depth, and the how-it-works overview is the right place to start if you want to understand the platform from a product engineering perspective. The faster your integration layer becomes infrastructure, the faster your product team gets back to building product.