Connect the systems
Connect the systems
Credentials
The six shipped types, the five auth kinds, connection tests, and what needs-reauth means.
OAuth
Authorize, callback, refresh rotation, and what re-authorizing looks like.
Secrets
The per-tenant encrypted store, its key format, and why expressions cannot reach it.
File transfer
The SFTP and FTP node sets, and the list, move and archive patterns worth copying.
Reaching Revenue Cloud
The revenexx API credential, Generic API Call, and the import and export endpoints on the public gateway.
A workflow is only useful once it can reach something. This group is how access data is stored, tested and referenced — and the two systems most workflows end up talking to: a file server, and Revenue Cloud itself.
The pages
- Credentials — the structured, testable connection to one external system: the six types that ship, the five auth kinds, testing before you save, and the four positions a credential reports.
- OAuth — the three-legged flow in detail: authorize, the provider, the callback, refresh rotation, and what happens when an authorization lapses.
- Secrets — the per-tenant encrypted key/value store for a single opaque string, and why it is deliberately unreachable from an expression.
- File transfer — the SFTP and FTP node sets, the credential they take, and the inbox-archive-failed pattern the shipped templates use.
- Reaching Revenue Cloud — the revenexx API credential and its scopes, the Generic API Call node, and when to use the gateway's own import and export endpoints instead of a workflow.
Reaching a system behind a firewall
A workflow can reach what the public internet can reach, and nothing else. No node sends its traffic through a VPN tunnel, and revenexx publishes no fixed set of outbound IP addresses for workflow requests (as of 2026-10). Do not plan a firewall rule around either.
Cockpit does let you set up a site-to-site VPN connection under Integration Studio → Data exchange → VPN. That connection does not make a system reachable from a workflow yet.
What works today is to make the connection one your side can open or accept:
| Your system | Do this |
|---|---|
| It can call out: an ERP, a warehouse system, a marketplace | Let it push. Give it the address of a webhook trigger and a token. Nothing is opened inbound on your network. |
| It has to be asked: a REST API, an SFTP server | Publish one HTTPS or SFTP endpoint at the edge of your network, a reverse proxy or an API gateway, and authenticate the caller with a credential or key. Allow-list by credential, not by IP address. |
| It exchanges files | Put the files on an SFTP host both sides can reach and read them with the file nodes. |
Credential or secret?
The one decision people get wrong at the start:
| You have | Use | Why |
|---|---|---|
| A system with a shape — a mail server, a file server, an API with an auth flow | A credential | Field validation, a test button, token handling, and one place to fix it when the customer rotates a password |
| A single opaque string nothing else models — a token a partner's endpoint expects in a custom header | A secret | The platform stores it and hands it to a node; it never has to understand it |
If you find yourself keeping a host, a username and a password as three separate secrets, that is a credential type waiting to be written — a node package can publish one alongside its nodes. See Custom nodes.
Neither one puts a value into the workflow document. A node references a credential by the type it needs, or a secret by its key, and the resolved value never enters the workflow definition or the run history — see Node configuration.