Outbound API Clients
An API client is an outbound connection — this platform calling another system's API. It is not related to the API keys that let other systems call you.
Where to find it
Architect Panel → Integration & Connections:
- API Clients — the outbound connections and their actions
- API Server — inbound access, which is a different thing entirely
- Data Sources — an alternative for reading external data
Architect Panel → Configuration:
- Site Settings — whether outbound calls are logged
The naming is genuinely confusing
"Client" here means this platform acting as a client of somebody else — the ordinary sense in HTTP, and the opposite of what many people expect from a screen called API Clients.
If you are looking for the credential a partner uses to reach you, that is an API key under API Server. This screen is for reaching outwards.
What a client defines
- A name.
- The host it calls and the protocol.
- Its authentication.
Beneath it sit actions — the individual calls, each with a path, an HTTP method and a request body.
Client and actions, not one call at a time
Connection details are configured once on the client, and each action reuses them. So a credential change is one edit rather than an edit per call, and the actions describe the API's operations rather than repeating its address.
When to use this rather than a data source
They overlap and the distinction is worth getting right:
- Data sources map an external system onto a datastore for reading, and optionally writing back — the right tool when you want the data to be in the platform.
- API clients call an operation and do something with the result — the right tool for actions rather than records: submit a job, trigger a notification, look something up in passing.
If your answer is "I want a table of their things", use a data source. If it is "I want to tell them something happened", use a client.
Credentials belong to the organisation
Register the connection under an account belonging to you rather than to an individual. An outbound integration that stops working because somebody left is an avoidable outage, and it is one of the commonest.
Consider what happens when the other end is down
You are now dependent on a system you do not control. Before wiring an outbound call into something time-sensitive, decide what should happen when it fails — retry, queue, degrade, or alert — because the default of "the action fails and somebody notices eventually" is rarely what you wanted.
Whose data is going out
An outbound call sends your data to somebody else. That is a processing decision as much as a technical one: know what each action transmits, satisfy yourself it is covered by your arrangements with that supplier, and prefer sending the minimum that works.
Worked example
An organisation configures one client for a courier's API, with three actions: book a collection, fetch a tracking status, and cancel. The credential is a service account the courier issued to the company. When the courier rotates it, one field changes and all three actions continue.
Recommendations
- Keep the inbound/outbound distinction clear in your own documentation.
- One client per external system, with actions beneath it.
- Use organisational credentials, never a person's.
- Decide the failure behaviour before going live.