How it works

Who holds what between your client, their services, Operate As and your workflows, and what happens on every call.

Your client gives access to Operate As, not to you. Your workflows call Operate As with an oa_ key, and we attach the client's access to each call on our server.

Connecting, once

Their page lists what you asked for, in plain words. See What your client sees.

They approve on the provider's own screen

Google's screen for Google, Slack's for Slack. For services that use a key, such as Stripe, they paste a key they made there instead.

The provider hands the access to Operate As

We encrypt it and keep it with the list of permissions they approved. It never leaves our server.

Every call, step by step

Your n8n node, code, client library or MCP server says which client and which action. Then:

StepIf it fails
1Your workflow calls with an oa_ key, a client and an action
2Key checked: it exists and hasn't been revoked401
3Scope checked: the key allows this client, service and action; the client is yours and was asked for the service; the client hasn't paused the connection or limited it to reads403
4Allowance checked: your plan has API calls left this period429
5Access renewed, if due: if the client's access has less than 5 minutes left, it's renewed first409 if the provider refuses, 503 if it can't be reached
6Call sent to the service's own API, with the client's access attached502
7Result back: the service's own status and body, as { status, data }
8Counted: one API call against your allowance; the key and connection are marked used

The answer you get is the service's own: its HTTP status and body, wrapped as { status, data }. See Errors for each Operate As status.

Between calls

A daily check renews every connection, used or not. Access that has ended is found by us, not by a failed workflow run. See Keeping access alive.

Why it's built this way

On this page