Reaching Revenue Cloud

Plenty of workflows have Revenue Cloud on both ends: read orders out of it, write products into it, export an entity and deliver the file somewhere. This page is how a workflow authenticates against the platform itself, and which of the three routes to take.

The revenexx API credential

One credential type covers all of it: Revenexx API (revenexx:api). Its fields are the access data:

Create it under Integration Studio → Credentials, test it in the dialog before saving, and every node that talks to the platform references that one instance. See Credentials.

Scopes are the thing that bites

The key is scoped, and a node needs the scope for what it does:

A credential that tests fine but lacks the scope fails at the step, not at the test. The connection test proves the key and tenant are valid; it does not prove the key is allowed to do what your workflow asks. If a flow fails on one node with an authorization error while everything else works, the scope is the first thing to check.

Where a customer's policy allows it, * covers every scope — convenient for a first integration, and worth narrowing before it reaches production.

Route 1: Generic API Call

revenexx:entity-api — labelled Generic API Call in the palette — is the node for reaching any Revenue Cloud API operation from inside a workflow.

You pick a resource and an operation, and the node resolves that operation's parameters into real, typed configuration fields, and its response into an output port. The credential carries the authentication and the tenant, so you are not maintaining a URL and an auth header by hand.

Prefer it over a hand-rolled HTTP Request against the platform. The reasons compound:

• The fields come from the API's own schema, so a wrong parameter name is visible while you are editing rather than at 03:00.
• The dropdowns reflect what your tenant can actually call, once a credential is chosen.
• Nothing about the request has to be re-checked when a header convention changes.

The resolution happens while you edit and is captured when you save — see Node configuration. Re-open and re-save the node to pick up a change in the API.

Route 2: the import and export nodes

For bulk data, do not loop an API call over ten thousand rows. Eight nodes drive the platform's Import & Export service from inside a workflow: stage a file, run an import profile, export from a profile, deliver the result. They take the same Revenexx API credential, with the io scope.

This is the route for anything file-shaped, and the two staging nodes stream large files past the workflow rather than through it. See File transfer and the node catalog.

Route 3: the gateway's own endpoints, without a workflow

Import and export are also plain API operations. The /v1/io/* endpoints on the public gateway stage a file, run a profile, and report a job's outcome — no workflow involved.

Take that route when the operation is standalone: your own service already has the file and wants to import it, or a nightly job on your infrastructure pulls an export. Use the workflow nodes instead when the import is one step in a larger flow — pick the file up from SFTP, import it, move it to an archive folder, notify somebody.

Browse the endpoints in the API Explorer, and see API usage for the conventions that apply to every call: the request headers, pagination, rate limits and error shapes.

Which route

Where to go next

• API usage — the conventions every platform call shares.
• API Explorer — every endpoint, ready to try.
• Credentials — creating and testing the credential this page depends on.
• File transfer — the other half of a file pipeline.