Guides · Setup guides

Connect any API to Outloop — and let an agent do the setup

Last updated: September 12, 2026

Two ways to set this up

Both paths end in the same place: an approved service in one workspace, with declared operations, a credential you typed into Outloop, and one real provider operation that completed. What differs is who does the clicking.

• A.Let the Setup Skill do it — recommended. You name the service and the outcome; the agent researches the provider and operates the Outloop dashboard. You step in once, to type the credential.
• B.Guided manual setup. The nine steps below, in order. Worth reading even if you take path A — it is the same nine steps, and it is how you check the agent's work.

A. Let the Setup Skill do it

The Outloop Custom API Setup Skill is a downloadable Agent Skill. One package, two platform labels — Claude Code and Codex share the Agent Skills folder format, and only the install directory differs.

Download it from the Skill library →

1. Unpack it into your runtime's skills folder

Claude Code:

Personal   ~/.claude/skills/outloop-custom-api-setup/
Project    .claude/skills/outloop-custom-api-setup/
Invoke     /outloop-custom-api-setup

Codex:

Personal   ~/.codex/skills/outloop-custom-api-setup/   (also ~/.agents/skills/)
Project    .agents/skills/outloop-custom-api-setup/
Invoke     $outloop-custom-api-setup

2. Register the Outloop Managed Browser once

The Skill works by operating the visible Outloop dashboard in a browser, so the runtime needs a browser path. Register the Managed Browser MCP server once per runtime:

agent-secrets browser mcp

3. Say which service to connect

Open the runtime in the client folder and say, in your own words:

Connect <service> to Outloop.

The Skill asks one question back — which service, and what should the agent be able to do with it — then researches the provider's documentation and starts configuring. The outcome matters: "read our documents" and "create and send documents" produce different operation sets, and the second is not finished by configuring the first.

What the Skill is not allowed to do

On the Outloop dashboard origin, a set of browser tools is blocked by name — in both browser vocabularies. The Skill can see and click the dashboard; it cannot run code in it, read its network traffic or console, upload a file to it, or photograph it.

• →Managed Browser: browser_run_code, browser_evaluate, browser_network_request, browser_network_requests, browser_take_screenshot, browser_file_upload, browser_console_messages, browser_pdf_save, browser_install, browser_start_tracing, browser_stop_tracing.
• →Claude in Chrome: javascript_tool, read_network_requests, read_console_messages, file_upload, and computer screenshot.

1. What are you connecting?

Name the provider and what the agent should accomplish. The outcome decides which operations count as complete — it is the thing every later step is measured against, and it is why "connect the API" is not a finishable request on its own.

2. Setup path

Three ways in: let an agent set it up (recommended), import an OpenAPI description, or configure manually.

Then the creation card: a service name and the documented HTTPS base URL, including the version prefix the provider publishes. A missing version prefix is the single most common cause of a 404 on every path.

3. Authentication

Choose the authorization scheme, the credential reference and — when the provider needs one — the header name, prefix or template. Values are entered once in Outloop and never shown again.

The twelve authentication kinds

The "use it when" column is deliberately the question you can answer from the provider's own documentation. Kinds marked JSON-only are configured in Advanced JSON today — there is no form for them yet, and saying otherwise would waste your afternoon.

The credential reference, and the one place a credential is typed

The configuration names a reference — a name standing for a value. The value itself is entered once, in Outloop, by a person, and is never displayed again.

4. Workflow readiness

Operations are approved request shapes: method, path, effect, parameters, response handling. Nothing outside the grid can be called, by anyone.

Readiness then measures every capability the intended workflow needs against what is present and what is still missing. A status operation alone cannot create anything — a configuration that can check a job and cannot start one can never be exercised, because the id the status read requires has no producing operation.

5. Workspace access

Then validate and save. Validation is local, and an incomplete result is a neutral fact that names the field.

Setup is six independent facts, never one light

There is deliberately no collapsed "Connected" or "Ready" state anywhere in Outloop. Collapsing these is exactly how a half-configured service reads as finished.

6. Verify

Run one low-risk provider operation through Outloop and confirm the visible verified state. A read, never a write: an access check is not the place to exercise a mutation.

operation:        the lowest-risk real read you declared
decision:         allow
http_status:      200
secret_exposed:   false
runtime_verified: yes

provider_verified is now true for THIS saved configuration
and THIS credential. Editing either one invalidates it.

The required-resource rule

7. Run with your agent

Hand the agent the approved service. It inspects the approved operations and carries provider-generated ids between operations itself — you never paste a job id from one step into the next.

Use the approved {service} Custom API in this workspace. Inspect the approved operations and complete the task through Outloop. Handle provider-generated request/job/resource IDs internally. Do not ask for or expose credentials or authentication headers.

Substitute the real service name for {service}. Nothing in that prompt asks for a credential, and nothing in it could produce one: Outloop composes the authentication host-side, so the agent uses the credential's capability without ever seeing it.

8. Files and results

Real client work produces files, and a file has to land somewhere sane. Outloop covers four shapes:

• →A direct file response. The operation answers with bytes. Set its response mode to file and you get a workspace file receipt — path, size, checksum, MIME — instead of bytes in a conversation.
• →A provider-issued result URL. The JSON result points at a finished file on a different host. Result artifact retrieval follows that pointer to an approved result origin and saves the file — without forwarding the API credential to that host.
• →Approved origins and path prefixes. Exact HTTPS origins only, never a wildcard. A result URL outside them is refused locally, with nothing downloaded and nothing forwarded.
• →Uploads. A workspace file as a body source or a multipart part, bounded by declared MIME types and sizes — up to 128 parts, and a 50 GiB ceiling in each direction.

9. Troubleshooting

The latest attempt selects the rescue card, and every card names the control to fix. The rows below are in match order — the first matching row wins — with HTTP statuses first, then codes.

What the engine supports

Every number below is a property of the shipped Custom API bridge contract, read out of the product rather than written from memory. They describe what the engine accepts — they are not a claim that any particular provider has been connected or verified.

Two consequences worth stating plainly. The method never classifies the operation — a POST can be a read, which is normal for SOAP and for search endpoints, so every operation declares its effect honestly instead. And SOAP 1.1 is supported and shipped, including the session pattern, so "we only do REST" was never true of this engine.

Reusable patterns

These are shapes, not provider code. Outloop ships no provider-specific Custom API adapters of any kind.

Two worked examples

A document API with a prefixed API key

The documentation shows the authorization value as API-Key <your key>. A first setup almost always sends the key bare — because "API key" sounds like "paste the key" — the provider answers 401, and the obvious next move of requesting a new key is exactly wrong. Set the value template to the scheme word, a space, then the single credential placeholder. Not the bare value, and not Bearer.

The rest of the recipe: import the published OpenAPI specification by URL and expect a large catalogue, of which most operations are irrelevant to your outcome; select what the outcome needs and classify each effect honestly, because a document create is a write, not a read. Creating a document is asynchronous — the provider returns an id in a non-terminal state — so the honest workflow is create, carry the id, poll to a terminal state, retrieve. The retrieval is a binary response, so set that operation to save as a workspace file.

An async media API whose result lives on another host

Four operations in sequence: a create that submits the generation and answers with a request identifier; a status read that takes that identifier and reports progress; a result read whose terminal payload carries a URL to the finished media on a host that is not the API host; and the retrieval that follows it to an approved result origin and saves a workspace file. Configure result artifact retrieval with a JSON pointer to the media URL, the exact HTTPS result origin, and the path prefix. Exact origins only — no wildcards.

• ✕Status-only is a half workflow. Configuring the status read first feels like progress — it is a GET and it is safe — but a configuration that can check a request and cannot create one can never be exercised, because the identifier it needs has no producing operation. Readiness says so. Believe it.
• ✕An account with no credits is an external prerequisite, not a configuration bug. A create that is accepted and never completes may simply be an empty balance. Name it and stop — never loosen the configuration to make it look like something else.

What is proven, and what is not claimed

This is a universal guide, so it has no single provider to have verified — and a page that does not say so is a page borrowing credibility it did not earn. Each line below carries exactly one status.

• Engine contract The capability numbers. Seven methods with CONNECT and TRACE always denied, nine effects, twelve authentication kinds, seven formats, OpenAPI 3.0–3.2, the envelope, header, multipart, workflow and transfer limits. These are read from the shipped bridge contract, not measured against a provider.
• Engine contract The local refusals. Workspace access off, an unassigned or missing credential, an undeclared operation, a parameter outside its schema, a required resource id, a result URL outside the approved origins — each refuses before any provider request leaves the Mac. That is the engine's own behaviour.
• Docs-backed example The two worked examples. Written from each provider's published documentation as illustrations of a pattern. Neither has been runtime-verified here, neither is an adapter, and neither is a supported connector.
• Not claimed No provider proof is published on this page. Verification is something your configuration does, against your provider, with your credential — and it is invalidated the moment you edit either. A universal guide cannot do it for you, and pretending otherwise would be the one claim most worth distrusting.
• Not claimed The Setup Skill's runtime coverage. It is published as a candidate and names no runtime as verified until it has actually been load-tested in that runtime.
• Stage honesty Outloop is at controlled design-partner prep. This page describes what the engine enforces and what the setup actually does. It makes no compliance or certification claim of any kind.

Rotate or revoke safely

Verification is tied to the exact saved configuration and the exact credential. Editing either invalidates it — which is the point. A rotated key is a different credential, and a configuration that worked with the old one has not been shown to work with the new one.

• 1.Create the replacement credential on the provider first, where the provider allows both to exist at once. Then you never have a window with no working credential.
• 2.Enter the new value in Outloop, in the same credential panel. The reference name does not change, so no operation has to be edited.
• 3.Re-run the verification read and confirm the visible verified state comes back. Until it does, treat the service as unverified rather than assuming.
• 4.Revoke the old credential on the provider. Revoking there is what actually ends its reach — deleting a reference in Outloop stops Outloop using it, not anyone else.

To take access away without touching the credential at all, turn workspace access off. The configuration stays, every call refuses locally, and nothing reaches the provider.

Glossary

Official documentation

A Custom API is configured entirely from the provider's own published API documentation — that is the authoritative source for the base URL, the authorization scheme, the paths, the parameters and the terminal states. Outloop has no provider-specific knowledge to add, and neither this guide nor the Setup Skill substitutes for reading it.

• →The OpenAPI Specification — the import formats Outloop accepts are 3.0, 3.1 and 3.2. Swagger 2.0 has to be converted first.
• →The Outloop Custom API Setup Skill in the Skill library — the download, its checksum and the full package documentation.
• →The connector guides — check here before building a Custom API. A native connector, where one exists, is always the better route.
• →AI agent API key management — the reasoning behind the boundary this page configures.

Outloop is available with guided onboarding for agency teams. Outloop is an independent tool and is not affiliated with or endorsed by any provider named on this page. Provider names are used only to illustrate reusable configuration patterns, and are trademarks of their respective owners.