Integration Studio

This section is for integration engineers, partner teams, and system integrators who need to move data between revenexx Revenue Cloud and a customer's enterprise systems — typically an ERP like SAP or Microsoft Dynamics, a PIM like Salsify, a CRM like Salesforce, or any custom HTTP API the customer cares about.

Most B2B commerce projects spend more engineering effort on integration than on anything else. Integration Studio exists so you don't have to write a custom backend service every time a customer's ERP needs to talk to revenexx.

What it is, in one paragraph

Integration Studio is a visual workflow engine built into Cockpit. You drag nodes onto a canvas — triggers, HTTP requests, transforms, conditionals, loops — connect them with edges, configure them with templated parameters, and deploy. The platform handles durable execution, retries with exponential backoff, observability, and per-tenant isolation. Workflows are visible and editable in Cockpit, so customers and partners can see what's running and adjust it without a deployment.

It's not "no-code". The people building real integrations still need to understand HTTP, JSON, authentication, idempotency, and error handling — things that don't go away just because the canvas is visual. But it removes the parts that every team rebuilds: scheduling, durability, retry logic, secrets management, logging, monitoring.

When to use Integration Studio (and when not to)

Use Integration Studio when:

• You're moving data between revenexx and an external system, and the external system has an HTTP API (REST or SOAP). This is the 90% case.
• You need a recurring schedule ("every night at 2am, pull orders from SAP").
• You're reacting to events from external systems via webhooks.
• The workflow is owned operationally by the customer or partner — they need visibility and the ability to retry, pause, or modify it without redeploying code.

Don't use Integration Studio when:

• You're writing core business logic that should live inside an app. That's the App Marketplace, not Integration Studio.
• You need millisecond-tier latency in a tight loop — sync workflows target sub-100ms, but if you need sub-10ms, write a direct service call.
• The integration is so specific to one customer that it shouldn't be visible in the standard Cockpit UI. Then a custom app is the better path.

What you'd typically build with this

Three realistic examples:

A nightly ERP order sync. Every night at 02:00, the customer's SAP system needs to receive yesterday's orders. You build a scheduled trigger, an HTTP GET that pulls orders from the catalog API filtered by date, a JSON Transform that reshapes them to SAP's expected format, and an HTTP POST that pushes them into SAP. The async engine handles the retries when SAP is briefly down; the customer sees the run history in Cockpit. About 30 minutes of work for the first time, 5 minutes for the next similar one.

A real-time price check. When a buyer lands on a product page, the storefront needs to show contract-specific pricing fetched live from the ERP — not the cached catalog price. You build a sync workflow with a manual trigger from the storefront, an HTTP call to the ERP, a JSON Transform, and a response. Sub-100ms round-trip. The storefront calls the workflow as an API endpoint, exactly like calling any internal service.

A webhook receiver for a third-party platform. When the customer's Salesforce instance updates a contact, the change should flow into revenexx. You build a webhook trigger, validate the incoming payload against a shared secret, transform Salesforce's contact format into revenexx's customer format, and post to the customer app's API. Salesforce's outbound webhook is the only thing the customer's CRM team needs to configure.

In all three, the boilerplate (scheduling, retries, secrets, logging) is solved. Your work is the actual business logic of the integration.

Two engines, one connector library

The interesting architectural choice in Integration Studio is the dual-engine design.

Async workflows run on a durable execution engine designed for long-running, fault-tolerant work. Each step's state is persisted; if a worker crashes mid-workflow, another worker picks up exactly where it left off. Retries happen automatically with exponential backoff. This is the right model for nightly imports, hourly syncs, anything that takes more than a few seconds and where durability matters more than latency.

Sync workflows run in-process — the same node logic, but invoked as a normal HTTP request, with the response held open. No queue, no event log, no durable-execution overhead. This is the right model for live price checks, availability queries, anything where the buyer is waiting on the screen and 100ms matters more than perfect durability.

The same library of node types — HTTP, JSON Transform, Filter, Switch, Iterator — works in both engines. You pick the engine when you deploy a workflow, based on whether the use case is "fire and forget durably" or "respond fast and now".

What's in this section

• Dual-engine architecture — Why two engines instead of one, what the durable async engine does for you, and how the connector library bridges both.
• Workflow Builder — The visual canvas. Nodes, edges, the configuration panel, and how data flows between steps.
• Node Types — Reference: every node type available, what it does, how to configure it.
• Triggers — Webhook, schedule, manual — the three ways a workflow can start, and when to use which.
• Expression Syntax — How to wire values between nodes: referencing previous step outputs, secrets, environment variables.

Where to go next

If you're new to revenexx, start with Platform Overview. If you understand the platform and want to see the engine architecture, go to Dual-Engine Architecture. If you want to start building immediately, the Workflow Builder page walks through the canvas.