.png&w=640&q=75){kind=small}
A new category for modern automation
What is XPA?
Cross-Platform Automation (XPA) is the discipline of connecting the software platforms a business already runs on, so that data, files, and triggers move between them automatically. Its substrate is four things in combination: APIs, webhooks, no-code orchestrators, and bespoke code.
- XPA stands for Cross-Platform Automation. The unit of work is the connection between platforms, not a click on a screen and not a top-down process model.
- Where RPA imitates a human clicking through a user interface, XPA moves data directly between the interfaces machines were built to use: APIs and webhooks.
- The XPA substrate is four things in combination. APIs, webhooks, no-code orchestrators, and bespoke code. Most production builds draw on all four at once.
- XPA fits best where work flows between SaaS platforms a business does not own, where speed of build matters more than process modelling, and where durability matters more than UI fidelity.
- The acronym has had prior uses. Neither of them described a working discipline. XPA is now the term for what the modern automation studio actually does.
- The term was coined by Olmec Dynamics in May 2026, proposed by founder Remi Gouws, to name a category the market had been practising without a name.
The full definition
The unit of automation is the connection between platforms.
The modern business does not run on one piece of software. It runs on dozens of them, and in enterprise settings often hundreds. A customer relationship manager for sales. A spreadsheet for forecasting. A ticketing system for support. A chat platform for internal communication. A billing engine for revenue. A document store for contracts. A model provider for artificial intelligence. Each of these platforms is excellent at the single thing it was built for. The work of the business, however, does not live inside any one of them. It lives in the spaces between them.
Those spaces have historically been filled by people. A salesperson copies a contact from an email into the customer relationship manager. An operations analyst exports a report from the billing engine and pastes it into a spreadsheet. A support agent reads a ticket and updates a separate project-tracking tool. A finance controller takes a figure from an invoice and keys it into an accounting system. The platforms are connected, but the connection is a person. Over time, the aggregate cost of those human-mediated connections becomes one of the largest hidden line items on a company operating statement. It also becomes one of the most reliable sources of error.
Cross-Platform Automation is the discipline that replaces those human-mediated connections with machine-mediated ones. It treats the connection between two platforms, the path a piece of data or a file or a trigger takes from where it arrives to where it needs to go, as the primary unit of automation. Where earlier categories defined that unit as a click on a user interface or a step inside a modelled business process, XPA defines it as the wiring itself.
That choice of unit has consequences. It reorganises what the work of automation looks like at the ground level. Instead of recording a human clicking through a screen, the XPA practitioner examines the two platforms at either end of a connection, identifies the interfaces they expose to machines, selects the orchestration layer that suits the path, and builds the connection. No process model is drawn first. No top-down map is required. The connection is built where it is needed, then extended platform by platform, until the cumulative effect is a system rather than a single automation.
XPA is not a single tool. It is a discipline that draws from four kinds of building block, often inside the same build. Native application programming interfaces, the documented contracts by which modern platforms expose their functionality to other machines. Webhooks, the inverse of an API call, by which a platform pushes a notification the moment something happens. No-code orchestration platforms, which compose API calls and webhooks into multi-step workflows without requiring connection code to be written by hand. And bespoke code, written in a general-purpose language, which fills the gaps the orchestrators cannot reach. These four together are the substrate on which an XPA system is built.
A category defined by the connection between platforms inherits a particular kind of durability. User interfaces change frequently. Business processes drift from their models the moment the business starts operating. Workflow engines become legacy. Application programming interfaces, by contrast, are versioned, documented, and engineered for machine use. When a platform updates its interface, the change is announced in advance, the old version is typically preserved for a period of months or years, and the automation is adjusted once. This is a material difference from the brittle regime of automations built against moving user interfaces, and it is the main reason XPA builds have unusually long operating lives once deployed.
Cross-Platform Automation, in short, is the name for what results when a business treats the connection between its software platforms as a first-class engineering problem and builds the system that follows. The discipline has existed in practice for years. The category has existed without a name. The purpose of this page is to give the category that name and to describe it with the precision the work deserves.
Where it sits
XPA vs. RPA vs. BPA vs. DPA
Four overlapping but distinct categories. The differences are not cosmetic. Each one starts from a different assumption about where the work of automation actually lives.
| Dimension | RPARobotic Process Automation | BPABusiness Process Automation | DPADigital Process Automation | XPACross-Platform Automation |
|---|---|---|---|---|
| Unit of automation | A click or keystroke on a user interface | A modelled end-to-end business process | A digital task inside a workflow engine | A connection between two platforms |
| Starting assumption | The system has no machine interface, only a screen | The process must be modelled top-down before it can be automated | A workflow engine routes work between steps | The platforms already exist, expose machine interfaces, and need wiring |
| Primary tooling | UiPath, Blue Prism, Automation Anywhere | Pega, Appian, IBM, ServiceNow | Camunda, Bonita, Nintex | Make, Zapier, n8n, bespoke code |
| Breaks when | A user-interface element changes | The modelled process drifts from operational reality | The workflow engine becomes a legacy system | An API is formally deprecated (rare, versioned, announced) |
| Time to first build | Days to weeks | Weeks to months | Weeks | Hours to days |
| Best fit | Legacy systems with no machine interface | Regulated, compliance-driven processes at scale | Internal task routing inside a single operational stack | SaaS-native businesses moving faster than their process modelling can keep up |
Commercial neighbours
XPA and its commercial neighbours
RPA, BPA, and DPA are the analytical neighbours of XPA, the categories against which its definition is most naturally drawn. A second set of neighbours exists in the commercial and analyst literature. Each one overlaps with XPA in scope but differs in kind. The table below is the short version. The paragraphs beneath it explain the distinctions that matter.
iPaaS
Integration Platform as a ServiceiPaaS names a category of commercial tooling. MuleSoft, Workato, Boomi, Tray.io, Celigo. XPA names a discipline. The relationship between the two is the same as the relationship between "database" (tooling category) and "data engineering" (discipline). An iPaaS product is one valid way to deliver an XPA build, particularly inside the enterprise. No-code orchestrators and bespoke code are equally valid delivery modes, and are typically chosen for builds outside the enterprise or inside teams that prize iteration speed over governance infrastructure.
Hyperautomation
Gartner term, first published 2019Hyperautomation is the combined application of multiple automation technologies across an enterprise. RPA, BPA, iPaaS, machine learning, process mining, and business rules engines. It describes a posture at the scale of the enterprise. XPA describes a category at the scale of a build. A hyperautomation programme may contain many XPA builds as components. XPA does not require a hyperautomation programme to exist. The scales are different and the terms are not interchangeable.
API-led integration
MuleSoft architectural patternAPI-led integration is an architectural pattern published by MuleSoft, organising enterprise integrations into three tiers of application programming interfaces (System APIs, Process APIs, Experience APIs). It is an architecture for how APIs are structured inside a large organisation. XPA is a category of discipline for what the work of connecting platforms is called. A single XPA build may or may not conform to an API-led architecture, depending on the scale of the organisation and the governance rules in place.
Workflow automation
Generic termWorkflow automation is a popular and deliberately loose term. It covers any automation of a sequence of steps and does not commit to a starting assumption about where the work lives. XPA is a workflow automation category in the broadest sense. "Workflow automation" and "XPA" are often used interchangeably in marketing copy. The broader term is less useful as an analytical label precisely because its looseness is the feature. Where precision is required, the correct label is XPA, or RPA, or BPA, or DPA, depending on which category the work belongs to.
No-code automation
Delivery modeNo-code automation refers specifically to automation built without writing source code. No-code is a delivery mode. It is not a category in the same sense RPA, BPA, DPA, and XPA are. Most XPA builds include a no-code layer as one of their four substrates. Many also include bespoke code at the points the no-code layer cannot reach. A build that mixes the two is no longer strictly no-code, but it remains XPA. No-code is one substrate inside XPA, not a competitor to it.
The internal framework
The XPA Substrate Model
XPA is not delivered by a single tool. It is assembled from four substrates that work in combination. The Substrate Model names each substrate and defines its role inside the discipline. Most production XPA systems draw on all four at once, and the engineering judgement of an XPA practice is substantially the judgement of how to balance them.
APIs
Application programming interfaces are the native contracts by which modern platforms expose their functionality to other machines. Every modern SaaS platform of serious size, among them Shopify, HubSpot, Stripe, Notion, Slack, and Salesforce, publishes a documented API. The API is versioned. Its changes are announced in advance. It is engineered from the outset for machine-to-machine use. For the XPA practitioner the API is the default surface. The question of alternative surfaces arises only when an API does not exist, or when the API does not cover a required operation.
REST, GraphQL, gRPC
Webhooks
A webhook inverts the polling model. Rather than asking a platform, on a schedule, whether something has changed, the platform itself pushes a notification the moment a change occurs. This turns an automation from periodic to real-time. It also removes the operational cost of polling, which at scale can become the dominant line item in an automation compute budget. Webhooks are the signalling layer of XPA. Where they are available, they are preferred. Where they are not, scheduled polling is the fallback, and the automation inherits the latency the schedule imposes.
Stripe events, Shopify webhooks, GitHub hooks
No-code orchestrators
A no-code orchestrator is a visual platform that composes API calls and webhooks into multi-step workflows without requiring connection code to be written by hand. The orchestrator handles authentication, retries, error paths, scheduling, and logging. For the large majority of XPA work, the orchestration layer is where the system is expressed and where most of its logic lives. Make, Zapier, n8n, and Pipedream are the leading examples. The differences between them are less about capability than about operational style, pricing model, the depth of the connector library, and the degree to which self-hosting is permitted.
Make, Zapier, n8n, Pipedream
Bespoke code
The fourth substrate is bespoke code, written in a general-purpose language and integrated into the system at the points the orchestrator cannot reach. Complex data transformations. Custom business logic. Model calls that require streaming or fine-grained control. Integrations for which no off-the-shelf connector exists. Performance-sensitive paths where orchestration overhead becomes a measurable cost. A mature XPA practice treats bespoke code as a precision instrument, used when it earns its place and not before, but never refused on principle. The balance between no-code and bespoke code is the defining engineering judgement in XPA. Too little code, and the build cannot reach the paths that matter. Too much, and the speed advantage of the orchestration layer is forfeited.
Node, Python, TypeScript, edge functions
How XPA works
How an XPA build is assembled
A worked example. One event at the front of the system triggers a cascade of cross-platform actions. The system is assembled from six canonical steps. No human intervenes in any of them after the trigger.
Trigger
A form submission, an inbound email, a platform webhook, or a scheduled event marks the moment the work begins. Every XPA build starts with an observable event.
Capture
The raw payload is received by the orchestration layer, then normalised, validated, and converted into a stable internal shape on which the rest of the system can rely.
Enrich
Additional data is added. A model extracts structured fields from an unstructured input. A lookup pulls a record from another platform. A calculation derives a value that was not present in the raw payload.
Route
Decision logic selects the destinations. Different inputs take different paths through the system. The routing layer is where business rules live, made explicit rather than implicit.
Push
Records are written into destination platforms. Files are generated and stored. Messages are sent. The work of moving data across the system boundary happens here.
Notify
Stakeholders are informed through the channels they use, and the run is logged to an auditable trail. The system records what happened and why, so that every execution remains inspectable after the fact.
A representative XPA chain
A supplier submits a form with product details and an attached utility document. That single submission is the trigger.
The orchestration layer captures the payload, passes the document to a model for structured extraction, calculates a set of derived values, renders a branded proposal from a template, stores the finished document in the correct client folder, logs the record in an operational spreadsheet, and returns the proposal to the account owner by email. The entire chain completes in under six minutes from submission to inbox.
No human operator touches the work. No process diagram is drawn. No bot clicks through a user interface. Six platforms move data between one another, in the correct order, because the connections are wired. This pattern, scaled and varied, is the shape of almost every XPA build.
The XPA stack
The working XPA stack
The Substrate Model describes the abstract anatomy of an XPA system. The stack below describes the concrete tools drawn on by the studio in production work. The list is opinionated by practice rather than by partnership. Each tool is included because it has earned its place on live builds.
Orchestration
LayerThe visual layer on which the automation is expressed. The orchestrator is where most of a given system logic lives and where most of its operational observability surfaces.
AI and extraction
LayerPulling structured information out of unstructured inputs. The bridge between human-formatted documents and machine-formatted records.
Storage and documents
LayerWhere records and files ultimately reside. The durable memory of the automated system.
Communications and workflow
LayerThe channels by which humans are notified and by which they act on the results of automated work.
CRM and sales
LayerWhere lead and customer data land, and where the downstream sales process picks up.
Custom layer
LayerWritten when no off-the-shelf connector is sufficient. A custom web application or service sitting inside the stack as a first-class participant.
When to use XPA
When XPA is the correct category for the work
XPA is not the right answer to every automation problem. The patterns below are the ones where XPA is unambiguously the best-suited category. Each one is drawn from recurring client work.
Manual data transfer between SaaS tools
A person moves fields, records, or files from one application into another on a recurring basis. Both applications expose documented interfaces. This is the canonical XPA scenario, and the one for which the discipline was named.
Document and proposal generation
Standardised outputs are assembled from structured inputs. Proposals, reports, invoices, decks. A template, a source of values, and a generation step together replace the work of a dedicated document specialist.
Lead capture, enrichment, and routing
A lead enters the system, is enriched from third-party sources, and is written into the correct customer relationship manager record with the correct owner assigned. Time from arrival to qualified record is measured in seconds rather than days.
Real-time multi-channel notification
An event in one platform must surface simultaneously in several others. A chat channel. An email. A dashboard update. A CRM record. All in the same moment, all reliably, with no human orchestrator in the middle.
Inbound document ingestion
Incoming files of varied format, including PDF, image, and email, are parsed, structured, classified, and routed to their appropriate destinations without a human transcriber in the loop.
Backlog clearance
A queue of work has accumulated that should already have been processed. XPA runs against the backlog overnight, freeing the team to return to the work the queue could not accommodate.
Origin
A term for what the modern automation studio actually does.
The word "automation" has for most of its career been split between categories that no longer describe the work most practitioners are producing. Robotic Process Automation was named for the screen-scraping robots of its era, at a time when many enterprise systems lacked machine interfaces. Business Process Automation assumed a top-down modelled process as its starting point, a posture that suited the early 2000s enterprise but sits poorly with SaaS-first operating models. Digital Process Automation, in most of its usage, is Business Process Automation under a cloud-coloured label. None of these names describes what a modern automation studio actually produces when it ships work for a SaaS-native business.
What those studios produce is not robotic imitation of a human at a screen. It is not the execution of a top-down modelled process. It is the wiring together of platforms, through the interfaces those platforms expose to machines. The work is the connection. The unit of automation is the connection between platforms.
Cross-Platform Automation, abbreviated to XPA, is the term for that work. The name describes the starting assumption. The abbreviation places the category alongside the ones it adjoins (RPA, BPA, DPA) so that a practitioner or a buyer can locate it within the existing taxonomy on first encounter.
Two prior uses of the acronym exist, and this page acknowledges both. Magic Software markets a low-code application development platform under the name Magic xpa. That product belongs to a different category, low-code application development rather than cross-platform automation, and the overlap in acronym does not extend to overlap in category. In 2021 the analyst firm Intellyx used the string "xPA" to mean "any-process-automation", a meta-pattern intended to describe commonalities between RPA, BPM, and low-code tooling. That usage was a taxonomy observation rather than a working category. It did not produce a discipline, a stack, or a definitional unit of automation, and it did not travel. XPA as defined on this page is a different claim, with a different unit of automation, a different substrate, and a different scope of application.
The term XPA, in the sense defined here, was coined by Olmec Dynamics in May 2026 and proposed by the studio founder, Remi Gouws. The aim is not to claim a proprietary category. The aim is to give a category that already exists in practice an honest name, so that the work of building it can be described in one syllable rather than in three sentences each time.
A category without a name is a category that cannot be discussed, compared, budgeted for, or evaluated with precision. Naming the category is the precondition for the work being taken seriously as an engineering discipline rather than as a trailing item under the heading of "miscellaneous digital projects". The purpose of this page is to set that name into usable public circulation, with the definition it deserves attached.
XPA in the wild
XPA in the wild
Every case study below is an XPA build. Named platforms. Concrete connections. Measured hours returned to the business.
Case study
UAE Media Sales House
From 800-Product Backlog to Zero. In Days.
Make.com · Shopify · OpenAI · Google Drive
Case study
Solar Proposals Automation
Proposal packets hit inboxes in under six minutes.
Make.com · Jotform · OpenAI · Google Workspace
Case study
Daily Fixture Processing Automation
Operators get their fixture reports before sunrise.
Make.com · OneDrive · Microsoft Excel · CloudConvert
Case study
Zoom-to-Drive Knowledge Pipeline
Every Zoom call becomes searchable knowledge within 20 minutes.
Make.com · Zoom · Google Drive · OpenAI
FAQ
Frequently asked questions
Short answers to the questions asked most often about XPA.
- No. iPaaS (Integration Platform as a Service) names a category of commercial tooling. MuleSoft, Workato, Boomi, Tray.io. XPA names a discipline. The relationship between the two is the same as the relationship between "database" and "data engineering". An iPaaS product is one valid way to deliver XPA. It is not the only one. No-code orchestrators and bespoke code are equally valid delivery modes, and are typically chosen for builds where speed of iteration matters more than enterprise governance.
- RPA is the automation of a human clicking through a user interface. It exists because certain legacy systems do not expose machine interfaces at all. XPA assumes the systems do expose machine interfaces, which modern SaaS platforms do, and builds directly against those. RPA breaks when the user interface changes. XPA breaks only when an application programming interface is formally deprecated, which is a rare, versioned, and announced event.
- Hyperautomation is Gartner's term for the combined application of multiple automation technologies across an enterprise portfolio. It describes a posture at the scale of the enterprise. XPA describes a category of automation at the scale of a build. A hyperautomation programme may contain many XPA builds as components. XPA does not require a hyperautomation programme to exist. The two terms sit at different scales and are not interchangeable.
- Zapier is one of the orchestration tools within the XPA substrate. Make, n8n, and Pipedream are others. Bespoke code is a fourth. XPA is the discipline of connecting platforms. Zapier is one of several legitimate ways to deliver it.
- API-led integration is an architectural pattern published by MuleSoft, organising enterprise integrations into three tiers of application programming interfaces (System, Process, Experience). API-led integration is an architecture. XPA is a category of discipline. A given XPA build may conform to an API-led architecture when operating at enterprise scale. Most XPA builds outside the enterprise do not need to.
- Not quite. Workflow automation is a broader and deliberately looser term. It covers any automation of a sequence of steps, and does not commit to a starting assumption about where the work lives. XPA is a workflow automation category in the broadest sense, but the broader term lacks the analytical precision to distinguish XPA from RPA or BPA. Where precision is needed, XPA is the correct label.
- No-code automation describes a delivery mode, in which an automation is built without writing source code. Most XPA builds include a no-code layer. Many also include bespoke code, at which point they cease to be strictly no-code but remain XPA. No-code is one of the four substrates inside XPA. It is not a competitor to XPA.
- Any business operating across multiple SaaS platforms with recurring flows of data between them. The pattern is industry-agnostic. E-commerce. Professional services. Agencies. Real estate. Media. Finance. Logistics. Healthcare, where compliance permits. A simple diagnostic applies. If a team member copies data from one tool into another more than once a week on a recurring basis, that work is a candidate for XPA.
- For simple two-platform connections, no. No-code orchestrators are designed for practitioners without engineering backgrounds. For complex data transformations, specialised logic, model integrations with streaming behaviour, performance-sensitive paths, or platforms without off-the-shelf connectors, engineering capability is required. Most production-grade XPA systems combine both no-code and bespoke code.
- Hours to days for a single connection between two platforms. Days to weeks for a multi-platform pipeline. Weeks to several months for a full-stack XPA system replacing the operational work of a team. Speed comes from the no-code substrate. Durability comes from bespoke code used at the right points.
- Most XPA work is priced by project scope rather than by hours of effort. The economic logic is straightforward. An XPA build pays for itself at the point where the monthly value of hours returned to the business exceeds the one-time cost of construction. For most builds delivered by the studio, that threshold is reached inside the first operating quarter.
- An XPA build typically has an operating life measured in years rather than months. The durability is a consequence of building against application programming interfaces rather than user interfaces. APIs are versioned, documented, and engineered for long-term machine use. A build against an API may require an occasional minor adjustment when a major version is released, which for most platforms occurs every several years with advance notice. A build against a user interface may require adjustment whenever a layout change ships, which on modern SaaS tools can happen monthly.
- Olmec Dynamics, a B2B software automation studio based in Cape Town and operating internationally, in May 2026. The term was proposed by the studio founder, Remi Gouws, to describe what the studio had been producing for clients for years under the catch-all label of "workflow automation".
- Because none of the existing terms accurately describes the unit of automation most modern businesses need to execute. RPA, BPA, and DPA are each anchored to a starting assumption that no longer matches how SaaS-native businesses operate. iPaaS names tooling rather than discipline. Hyperautomation names a posture at enterprise scale. Workflow automation is too broad to function as an analytical label. The space for a precise, discipline-level term has been empty. XPA fills it.
Get started
Describe the manual process that is costing the most time. A mapped XPA build is returned within the week.
Ten questions. Three minutes. A personalised assessment with a build estimate attached.