What is software integration?

August 11, 2026

Software integration is the practice of connecting separate software applications so they can read and write each other's data without a person copying it across. In commercial use the term covers three different jobs: connecting the applications a company runs internally, building integrations into a product you sell so your customers can connect their own accounts, and the software engineering sense of combining code modules during a build. Most guides answer only the first, which is why answers to this question disagree with each other so often.

Which meaning of software integration are you asking about?

Three meanings share the phrase, and they have almost nothing in common operationally.

The rest of this page addresses the first two meanings, and separates them where the answer differs.

Does any standards body define software integration?

No standards body defines software integration as a technology category. ISO/IEC/IEEE 24748-6 governs integration as a lifecycle process rather than as a way of describing products, and no universal dictionary definition of the commercial sense was located in the public standards material reviewed for this page in August 2026.

What that leaves is a category defined entirely by the companies selling into it. AWS describes application integration as getting independently built software to work together without manual intervention. IBM treats application integration and software integration as alternate names for the same thing. Workato separates software integration from system integration by scope, putting hardware in the latter. Boomi frames it as connecting applications, data sources and business software. These are reasonable working definitions and they do not agree on where the boundaries sit.

That matters more than it sounds. When four vendors publish four boundaries, any comparison you read is being made inside somebody's definition, and the definition usually favours the company that wrote it.

Software integration vs system integration vs data integration vs API integration

The adjacent terms overlap and the overlap is real rather than sloppy.

How does software integration actually work?

An integration starts with authorization, not with data. The customer who owns the account has to grant access, an authorization server issues a token limited to specific scopes, and everything the integration can subsequently read or write is bounded by what that token permits.

For a customer-facing integration, the hard part of that step is rarely the protocol. Connecting to Salesforce or QuickBooks is well documented. Getting someone who does not know your product yet, may not be technical, and has no particular reason to trust you to hand over access to their core business data is the part teams underestimate, and it happens before a single API call is made.

OAuth 2.0, published as RFC 6749 in October 2012, is the framework almost every current SaaS API uses for this. Its successor is not finished: OAuth 2.1 remains an IETF Internet-Draft, draft-ietf-oauth-v2-1-15 dated March 2026, and anything describing OAuth 2.1 as a published RFC is currently inaccurate.

Tokens are not permanent, and the rules vary per vendor in ways that produce support tickets months after launch. Google documents that refresh tokens are invalidated by user revocation, by six months of non-use, and by a password change where Gmail scopes are involved. Google also caps refresh tokens at 100 per Google Account per OAuth client ID, and creating more can invalidate the oldest without warning. For an application whose OAuth consent screen is still in Testing, refresh tokens expire after seven days.

Once authorization holds, three things move: reads, where the integration requests records; writes, where it creates or updates records in the connected account; and events, where the connected API notifies the integration that something changed rather than waiting to be asked.

What are the types of software integration?

Most published lists of integration types mix incompatible dimensions into one set, which is why no two of them match. Topology, interaction style, data movement, delivery model and agent access are five separate questions, and a given integration answers all five at once.

Topology: how connections are arranged

Point-to-point connects one application directly to another with custom logic. IBM notes it suits a small number of applications and becomes unwieldy as connection count grows. Hub-and-spoke routes through a central component, which reduces direct connections and centralises monitoring while making the hub a single point of failure. An enterprise service bus adds routing, transformation and protocol mediation at the centre; IBM documents bottleneck risk, regression testing after middleware updates and high availability cost as its trade-offs.

A naming collision is worth knowing about here. In network topology, a star means one central node with spokes, which is hub-and-spoke. In the systems integration literature, star integration means the opposite arrangement, where each application connects to each of the others. Wikipedia's system integration article explains the reasoning, describing the connections as reminiscent of a star from the perspective of the single subsystem being integrated, and gives spaghetti integration as the alternative name for the same pattern. Neither usage is wrong, but reading one as the other will invert the meaning of a sentence.

Interaction style: how a call is made

API-led connectivity, as Salesforce and MuleSoft describe it, organises reusable APIs into system, process and experience layers so several consumers can build against the same interfaces. Event-driven integration inverts the direction: producers emit events, a router or broker distributes them, and consumers react asynchronously. AWS names fan-out, cross-account distribution and heterogeneous integration as fits, and notes it suits poorly where tightly coupled synchronous sequencing is required.

Data movement: how records travel

File transfer moves data on a schedule using SFTP, AS2, FTPS or FTP, and remains standard for partner and bulk exchange. ETL transforms before loading into the target; ELT loads raw first and transforms in the destination, which AWS associates with warehouse and lake processing. Reverse ETL runs the other way, syncing modelled warehouse data into operational applications. Hightouch, which sells the pattern, documents its main hazard: many destination applications have no undo, and writes must satisfy the destination API's schema or fail.

Delivery model: what you buy rather than build

iPaaS is a cloud delivery model for integration tooling. Embedded iPaaS puts that tooling inside another company's product so their customers can configure integrations; Workato's embedded offering is a named example. A unified API aggregates several APIs in one category behind a common schema, so a product team writes to one interface per category and the schema differences between individual integrations are handled by the API rather than in application code. Unified.to sells one. None of these three names comes from a standards body or a specification; they are categories the vendors in the market defined, and that includes ours.

Agent access: how a model reaches an integration

The Model Context Protocol, currently at revision 2026-07-28, gives model clients a standard way to discover callable operations with tools/list and invoke them with tools/call. The specification names API calls, database queries and computation as things a tool can do. MCP moved to the Agentic AI Foundation, a Linux Foundation directed fund, after Anthropic donated it in December 2025.

Which standards does an integration actually rely on?

Fewer than the vocabulary suggests. Several of the terms used as though they were standards are dissertations, drafts or conventions.

Why are integrations hard to keep working?

Integrations are hard to keep working because every API on the other side defines its own limits, its own pagination, its own error shape and its own version schedule, and changes them on its own timetable. Building one is a bounded project; keeping it working is not. The failure modes below are documented in the vendors' own developer material.

Rate limits are not comparable across vendors. GitHub documents 5,000 requests per hour for authenticated personal REST access, and 15,000 per hour in specified GitHub Enterprise Cloud app contexts. Slack publishes per-method tiers instead, at 1 or more requests per minute for Tier 1 through 100 or more for Tier 4, and states that it deliberately does not publish exact burst limits because they change. Two APIs, two units, no shared convention.

Rate limit policy can change under an existing integration. Slack applied new limits to conversations.history and conversations.replies on 29 May 2025 for newly created commercially distributed apps not approved for its Marketplace, treating existing installations differently. Whether your integration is affected depended on when and how it was distributed.

Pagination is not one contract. GitHub's pagination varies by endpoint, in which query parameters it accepts and in the maximum page size it allows. Slack's Web API uses cursors, and documents that a page can return fewer records than requested even when more remain, and that cursors can expire.

Error shapes differ even under HTTP. Slack states that its Web API is an HTTP RPC-style interface rather than REST, and returns a top-level ok boolean with machine-readable error information. Error handling written against one API's conventions does not transfer.

Version support windows are finite and vendor-specific. Shopify releases a new API version quarterly, supports stable versions for at least 12 months, and provides at least nine months of overlap; its current stable version at the time of writing is 2026-07, released 1 July 2026 and documented as available until 16 July 2027. GitHub released REST API version 2026-03-10 and commits to at least 24 months of support per version, counting field removal, renaming and authentication changes as breaking.

Sandbox behaviour is its own category of surprise. Salesforce documents that when Data Cloud sandbox connections are replicated, the authentication data is not, and connections stay inactive until reauthorized.

Many APIs have no webhooks at all. Where a vendor never built change notification, the choices are to poll the API on a schedule and maintain that polling yourself, or to have no events for that integration. Because no webhook specification exists, the ones that do exist differ in payload shape, retry behaviour and signature scheme, so each is written separately. Unified.to detects changes and delivers events for integrations whose APIs offer none, which is the part of the problem an integration layer can absorb rather than pass on.

And deprecation notice is frequently absent. A 2020 study mining 2,224 OpenAPI specifications covering 1,368 RESTful APIs found that 87.3% of API versions introducing breaking changes gave no deprecation information in the previous version. The authors describe this as an upper-bound indicator, based on an APIs.guru snapshot from October 2019 and identified heuristically, so read it as evidence that the practice is common rather than as a precise rate.

Should you build integrations in-house or buy?

There is no independent measurement to answer this with. No non-vendor study with a published methodology comparing the cost of building integrations against buying them was located in this research. Every figure in circulation was produced by a company selling one side of the answer, including ours, and should be read with that attached.

What you can check is your own situation. How many integrations do you need in the same category, and will that number grow. Are they internal or customer-facing, since a customer-facing integration adds authorization, error communication and support obligations that an internal one does not. Will your customers expect writes as well as reads. And who absorbs the work when a connected API ships a breaking change, which is the question that separates a one-time project from a permanent commitment.

Our longer treatment of the decision, including where building in-house is the right answer, is in build vs buy for integrations, with the engineering-level version in building integrations yourself vs using a unified API.

How does AI agent access change the requirements?

Agent access adds an authorization problem rather than removing an integration problem. MCP standardises how a model discovers and calls an operation, but it does not make the underlying integration self-maintaining, and the specification is explicit that the protocol cannot enforce the security principles it describes.

Three consequences follow. Authorization is optional at the protocol level, so adopting MCP supplies no application authorization by itself; for HTTP transports the 2026-07-28 revision defines OAuth-based behaviour and recommends least-privilege scopes. Which operations a client can see may vary with the authorization it presents, which supports per-customer scoping but does not guarantee correct tenant isolation, since that remains an implementation responsibility. And handling of personal data before it reaches a model is a policy and implementation concern that MCP does not address.

The specification also separates tools, which take action, from resources, which supply passive context such as file contents or schemas. That distinction is a useful way to think about the difference between giving an agent a document store and giving it access to a live account.

What should you ask an integration vendor?

The questions that separate integration products are architectural, and most of them can be answered in one sentence by a vendor who has a good answer.

• Is data cached on a schedule, or does each request reach the source system?
• Where does a write land first, and when does the system of record reflect it?
• Is customer data stored at rest on your infrastructure, and if so, are you a subprocessor we have to disclose?
• Which integrations get change events, and which are polled?
• Can we reach fields and endpoints you have not mapped, on the same connection?
• Does the pricing scale with our customer count, our connection count, or our API volume?
• Whose logo and whose domain does our customer see on the authorization screen?
• What happens to our integration when a source API ships a breaking change?

Frequently asked questions

Is software integration the same as integration testing? No. Integration testing is a phase of the software development cycle, where separately built modules are combined and checked for interface defects before system testing. Software integration in the commercial sense connects finished applications to each other. The two share a name and nothing else.

Is software integration the same as API integration? API integration is one method within software integration, not a synonym. File transfer, ETL, database sharing and message queues are all software integration and none of them are API integration.

Where to go next

For the mechanics behind each section above: how to handle OAuth across many integrations, why API pagination breaks multi-integration systems, what breaks in REST API integration at scale, and when to use a webhook and when to use an API.

For the delivery-model comparison: ETL vs iPaaS vs unified API and embedded iPaaS vs unified APIs.

For the agent layer: MCP vs RAG and APIs for AI agents.