Enterprise integration
One execution layer across applications, data, protocols and infrastructure.
Nexus connects SaaS platforms, systems of record, databases and servers in a single governed workflow, using prebuilt actions where they exist and direct protocol access where they do not.
A cross-system transaction
Integration is one stage of the operation, not the destination. The value appears when the retrieved data is checked, decided on and written back under the same record.
- prebuilt integration actions
- 1,480+prebuilt integration actions
- event sources
- 46event sources
- runtime language families
- 8runtime language families
- capable execution
- Air-gappedcapable execution
The estate
Integration has to cover what you actually run.
Most organizations operate a mix of modern SaaS, long-lived core systems and infrastructure that predates the current architecture. An integration layer is only useful if it reaches all of it.
SaaS applications
CRM, service management, HR, finance and collaboration tools reached through their published APIs and prebuilt actions.
Core business systems
ERP and other systems of record, including interfaces that were designed long before REST became the default.
Databases and warehouses
Direct queries and writes against relational databases where a record, not an API object, is the source of truth.
Internal services
In-house APIs and microservices that carry organization-specific logic no vendor connector will ever model.
Infrastructure and platforms
Kubernetes clusters, servers and cloud accounts that need to act as part of the same business process.
Files and transfer surfaces
Shared storage, object storage and file drops that still carry a large share of enterprise data movement.
Hierarchy
Prebuilt where it exists, direct where it does not, code for the last mile.
This ordering is deliberate. It keeps common work fast without leaving teams stranded the moment a requirement falls outside the connector library.
Level 01
Use a prebuilt action where one exists
Nexus provides 1,480+ pre-built actions across 43 product families. Where an action covers the operation you need, configure it and move on. Depth varies by vendor, so treat the library as a starting point and confirm the specific action for your system.
Level 02
Use direct API, protocol or database access where it does not
When a connector does not cover an operation, call the endpoint directly. HTTP, GraphQL, SOAP, SAP RFC, MSSQL, Oracle and SSH are first-class steps rather than escape hatches, and they carry the same typed inputs, secrets and history.
Level 03
Use code for the last mile
Payload shaping, vendor-specific quirks, signing routines and reconciliation logic run in a code node in the language that fits the task. The code stays inside the governed workflow instead of becoming a separate service.
Connector coverage is not uniform. Some vendors expose deep, well-documented APIs and the corresponding actions are extensive. Others expose less, and the honest answer is direct access or code. Nexus is designed so that answer does not stop the project.
Access methods
Protocols and interfaces available as workflow steps.
Each of these is a configured node with typed inputs, vault-backed credentials and recorded results, so a legacy call is governed the same way a modern one is.
HTTP and REST
Authenticated requests with typed request and response handling.
GraphQL
Queries and mutations against modern application schemas.
SOAP
Envelope-based services that remain common in core enterprise software.
SAP RFC
Function module calls against SAP systems.
MSSQL
Direct queries and writes against Microsoft SQL Server.
Oracle
Direct queries and writes against Oracle databases.
SSH
Remote command execution on servers and appliances.
Webhooks
Inbound notifications that start a workflow the moment data changes.
Where an interface is not on this list, a code node can reach it using the libraries of the runtime you choose from Python, Bash, Go, Java, .NET, PHP, PowerShell and JavaScript/TypeScript through Deno.
Event-driven
Integration that follows events, not polling schedules alone.
Batch jobs still have their place. Most operational value comes from acting when something changes, and from a reconciliation pass that catches what the event stream missed.
Message queues and event buses
Workflows consume enterprise messaging so integration follows the events your architecture already publishes rather than a polling loop bolted on top.
Webhook receivers
Each workflow can expose an endpoint that external systems call directly, with the payload available to every downstream node.
Scheduled reconciliation
Event-driven paths cover the moment of change. Scheduled runs catch what events missed, which is how integrations stay honest over time.
Fan-out and fan-in
One event can drive parallel work across several systems, then merge results before a decision or a write-back is made.
Worked example
A representative cross-system flow.
An opportunity closes in the CRM, the customer master lives in the ERP, finance keeps a reconciliation table, and nobody is allowed to post an order without a review. That is a normal enterprise integration, and it is one workflow.
- 01
Trigger
A Salesforce opportunity moves to closed and the change reaches Nexus through a webhook.
- 02
Integration
A connector action reads the account and contract detail, and an SAP RFC call retrieves the matching customer master record.
- 03
Rules + Code
Deterministic checks compare pricing, credit terms and tax data. A code node normalizes the two record shapes into one structured payload.
- 04
Sovereign AI
A self-hosted model summarizes free-text contract notes and flags clauses that fall outside the standard template.
- 05
Human Approval
A reviewer sees both records side by side with the differences highlighted, and approves, corrects or rejects.
- 06
System Action
The approved result writes the sales order to SAP, updates the Salesforce record and inserts a reconciliation row in the operational database.
- 07
Audit
Inputs, outputs, the model response, the reviewer decision and every system call are retained with the run.
- 08
Exception path
If SAP rejects the write, the run routes to a retry and escalation branch instead of failing silently.
Control
Credentials, data handling and evidence.
An integration layer holds the keys to your estate. How it stores them, and what it records, matters as much as how many systems it reaches.
Vault-backed secrets
Credentials are stored in the vault and referenced by nodes. They are not pasted into workflow configuration, embedded in code or copied between environments by hand.
Workspace-scoped access
Connections belong to a workspace, so a team can use a credential in a workflow without the credential itself being visible to them.
Typed inputs and outputs
Each node declares what it accepts and returns, which makes mismatched payloads a design-time problem rather than a production surprise.
Retries and error routing
Transient failures retry. Persistent failures follow an exception branch that can enrich the case, notify an owner or open a review.
Execution history
Every run records which systems were called, with what inputs and what they returned, so an integration question can be answered from evidence.
Auditability across systems
Because integration, logic, AI and approval share one execution, the audit record covers the whole transaction instead of one leg of it.
Operations
What running this in production looks like.
Integrations are judged on their second year, not their first demo.
Revisions and safe change
A workflow is edited as a draft revision and tested before publication, so an integration change does not take effect the moment someone saves it.
Per-node diagnostics
When a run stops, the failing node, its input and the response from the remote system are visible together. That is usually enough to distinguish a credential problem from a payload problem.
Reruns instead of manual repair
Once the remote system is healthy, a failed run can be executed again rather than reconstructed by hand from log fragments.
Sovereign placement
The integration layer runs in your data center, private cloud or an air-gapped network. Payloads from your systems do not need to leave the environment you control.
Operation
Operating responsibilities.
Define data models, entitlements and exception handling while keeping each system of record in place.
Process design
Systems have data models, entitlements and edge cases. Nexus removes plumbing work, not the design work of deciding what should happen.
Extend through approved interfaces
Use pre-built actions for supported operations. Additional operations use APIs, protocols, databases or Rules + Code in the same run.
Systems retain ownership
Nexus orchestrates the applications, databases and infrastructure you already run. It does not aim to replace the systems of record themselves.
Architecture session
Bring us the integration your current tools cannot finish.
The interesting cases are the ones with an undocumented legacy interface, a data model nobody owns and an approval step in the middle. Walk us through yours and we will map it to prebuilt actions, direct protocol access and code.