---
name: outloop-custom-api-setup
description: Connect any API to Outloop for this workspace by operating the visible Outloop dashboard in a browser — research the provider, create the custom service, import or define its operations, configure async and file behaviour, pause once for the person to enter the credential, enable workspace access, and take it through provider verification and a real workflow proof. Use when someone says connect, add, set up, wire up, integrate or fix an API, service or provider for their agent, or when an Outloop Custom API is failing and needs repair.
license: Proprietary. Outloop / Agent Access Router.
metadata:
  compatibility: "Claude Code or Codex. Requires an approved browser path — the Outloop Managed Browser (preferred) or Claude in Chrome — plus Outloop Local Bridge file access in this workspace. No terminal access is used."
  version: "1.0.1"
  source: agent-access-router
  surface: outloop-dashboard
  runtimes: "claude-code, codex"
  browser_paths: "outloop-managed-browser, claude-in-chrome"
---

# Outloop Custom API Setup

Tell your agent which service you want to connect. The Outloop Custom API Setup Skill researches the provider, configures it directly in Outloop, validates the connection, and takes the setup through verification. When a credential is required, Outloop asks you to enter it directly. The agent never sees the secret.

You do this by operating the **visible Outloop dashboard** in a browser, the same way a person would. There is no terminal step in this workflow, and you never ask for a key.

## OLLIE Runtime integration

For execution under Ask OLLIE, read live Workspace Context and tenant bindings. Consume
ask-ollie-authority-core for authority, outloop-access-fallback for access and recovery,
email-lifecycle-core for communication, and the bootstrapper Runtime Contract for ownership,
scheduling and completion. This capability supplies dashboard-specific configuration knowledge;
it does not grant service access or create a separate Runtime owner. Preserve the dashboard's
credential-entry and security boundaries. Resolve the actual host tool names from its capabilities.
Verify findings against source evidence and read back the resulting configuration and proof state.

## First turn

Ask one question:

> **Which service do you want to connect, and what should your agent be able to do with it?**

"Connect Higgsfield" is a complete answer. Take it from there: research the provider, infer the likely outcome, state the outcome you are configuring for in one line, and start. Ask a second question only when the outcome genuinely changes the configuration (for example: does this need to *create* things, or only read them?) — and ask it while you work, not as a gate.

If the person instead describes a broken setup ("PandaDoc keeps saying authentication rejected"), go to **Repair an existing setup** below.

## Before you touch anything

1. **Pick the browser path.** Check the Outloop Managed Browser with `outloop.grants.check` and `check_verb: "outloop.browser.call"`. Granted and available → use it. Otherwise use Claude in Chrome if its tools are present. Neither → name the missing capability and stop. Never improvise another browser and never fall back to a terminal.
2. **Get the dashboard URL** from the non-secret file the installed app writes: `~/Library/Application Support/AgentAccessRouter/dashboard-url`. Never hard-code a port. Never write that URL into a file.
3. **Get the workspace (tenant) id** from this workspace's own OUTLOOP block or `.claude/agent-access-router/project.yaml`. Never guess it, never take it from a folder name, never read it off the screen.
4. **Open `#/keys?ws=<tenant>`** and confirm from the snapshot that the visible workspace is the one you were given. A mismatch is a hard stop.

Read `references/browser-tools.md` for the tool vocabulary and `references/browser-security.md` for what is refused on the dashboard origin. Both are short; read them before your first click.

## The flow

Thirteen steps. `references/browser-flow.md` carries each one in full, plus the control map you need to turn a control name into a snapshot `ref`.

1. **Choose the browser path and open the workspace.** Above.
2. **Route the service.** Search the service picker. A native connector exists → follow *that* connector's setup and stop; never build a Custom API beside it. No row → **+ Add a custom service**. See `references/service-routing.md`.
3. **Fill the creation card.** Service name, HTTPS base URL, authorization kind, header or query name, value template. Non-secret only. `create-name`, `create-base-url`, `create-auth-kind`, `create-first-path`, `create-submit`.
4. **Bring in the operations.** OpenAPI URL first (`import-source-url`), pasted specification second (`import-source-paste`), **never the file mode** — file upload is refused on this origin. No specification → define operations by hand with `editor-operation-add`. Classify every effect honestly.
5. **Configure async and files** when the workflow needs them: `editor-artifact-retrieval` for a provider-issued result URL, `editor-file-response` for a direct binary answer. See `references/async-and-ids.md` and `references/files-and-media.md`.
6. **CREDENTIAL HANDOFF — the only manual step.** Navigate to the credential screen, say in one sentence what to enter, and **pause**. The person types the value and saves. Resume on the visible success line containing *never shown*. Never ask for, read, type, verify, log or snapshot the value. See `references/credential-handoff.md`.
7. **Assign the credential reference** in the editor (`editor-auth-reference`) and confirm the visible assigned state.
8. **Enable workspace access** (`editor-workspace-access`). A saved configuration grants nothing until this is on. The destructive toggle is the person's decision, asked once.
9. **Validate and save** (`editor-validate`, then `editor-save`). Reopen and read the chips. A green save chip alone is not readiness — see `references/setup-state-machine.md`.
10. **Verify against the provider.** Open `proof-open`, choose the lowest-risk real read, read the prepared request, **execute it yourself as `api_bridge.request` over the Local Bridge**, then press `proof-refresh` and confirm **Provider operation verified**. The dialog never calls the provider. See `references/verification.md`.
11. **Run the representative workflow**: create → carry the returned ID → poll → retrieve → confirm the workspace file receipt. The same execution path.
12. **Diagnose and repeat.** Read the visible rescue card and `row-next`, match it in `references/troubleshooting.md`, fix the named control, re-run.
13. **Stop and report.** Stop only for the credential handoff, a real external prerequisite, or a security refusal.

## Configure the capability the workflow needs

This Skill configures a **working** integration, not a demo.

- If the outcome needs to create, submit, update, upload or download, configure those operations. Read-only is a deliberate choice, not a safe default that spares you the thinking.
- Classify each operation by its **honest effect**, never by its HTTP method. A `POST` search is a read; a `GET` is never a licence to mutate.
- **Deletion and destructive operations are the person's explicit decision.** Configure them when the workflow truly needs them, say in one sentence what turning the toggle on permits, and accept "no" without arguing. Never enable it to make an error disappear.
- A configuration that can check a request but cannot create one is a **half workflow**. So is one that can start work but can never see the result. Name the missing capability; never call either one ready.

## Repair an existing setup

Enter here when a configuration already exists and something is wrong.

1. Open `#/keys?ws=<tenant>` and find the row for the service. Read its chips and `row-next` — they already say which fact is false.
2. Read the latest attempt's code and HTTP status, and find the matching card in `references/troubleshooting.md`. Match the HTTP status first, then the code.
3. **A local refusal means no provider request was sent.** Never report it as a provider failure and never retry it unchanged.
4. Fix the one control the card names. Validate, save, re-verify.
5. Common repairs, in order of how often they are the answer:
   - Authentication rejected (401) → the scheme, header name, prefix or composition does not match the docs character for character. `editor-auth-composition`, and `references/patterns/multi-part-credential.md` when the value has two parts.
   - Not found (404) → a missing version prefix in the base URL, or an ID from another account.
   - Nothing runs at all → workspace access is off, or a credential reference has no stored value.
   - Was working, now is not → the definition was edited or the credential rotated; the verification is correctly gone. Re-verify.
6. If the configuration is from an older engine and refuses to load, recreate it **keeping the same operation ids and resource ids**, then validate and save.

Never delete and rebuild a working configuration to avoid diagnosing it.

## Hard rules

- **Never ask for, receive, read, type, verify, store, log, print or screenshot a credential value** — not the whole value, not a prefix, not its length. If someone pastes one into the conversation, say you cannot receive it, ask them to enter it in Outloop, and tell them to rotate it.
- **Never use a tool that is refused on the dashboard origin** in either vocabulary: no script evaluation or run-code, no network capture, no console reading, no screenshots, no file upload. Navigating to a dashboard `/api/*` URL is refused too. A refusal is an answer: report the code and stop.
- **Never use a login-recovery verb or any sign-in path** as part of setup, and never open Keychain or any credential store.
- **Never change anything outside this Custom API configuration** — not Managed Browser availability, not other grants, not another workspace.
- **Never add an `Authorization`, `Bearer` or custom auth header** to a request you execute. Outloop injects authorization host-side.
- **Never invent a path, parameter, ID or success status** to make something pass, and never widen an origin, prefix or pattern to silence one failing call.
- **Never reuse an ID produced by another tool, account or integration** as evidence that this configuration works.
- **Never replay a mutation whose outcome is uncertain.** Read the resource back first.
- **Never present a preflight, a save, a green chip or a successful clipboard copy as a provider proof.**

## Reporting

End with four short sections:

- **Verified** — which operation Outloop ran, and what the provider completed. Non-secret terms only.
- **Supported, not verified** — what is declared and has never been exercised, and why.
- **Blocked** — the exact code, external prerequisite or refusal, if any.
- **What the person must know** — the destructive setting as it stands, anything ambiguous in the provider docs, and what would invalidate the verification (editing the definition, rotating the credential).

Never blur verified and supported. An honest "configured, not verified" is worth more than a confident wrong claim.

## References

| File | Read it when |
| --- | --- |
| `references/service-routing.md` | Deciding native connector vs Custom API. |
| `references/browser-flow.md` | Any step of the flow; the control → role/name map. |
| `references/browser-tools.md` | Choosing a tool in either vocabulary; reaching the Managed Browser. |
| `references/credential-handoff.md` | Before the handoff. Every time. |
| `references/browser-security.md` | What is allowed and refused on the dashboard origin. |
| `references/provider-research.md` | Before configuring anything. |
| `references/capability-model.md` | Methods, effects, the twelve authorization kinds, OpenAPI limits, glossary. |
| `references/setup-state-machine.md` | Reading the chips; what "ready" actually requires. |
| `references/async-and-ids.md` | Create → poll → result; executing over the Local Bridge. |
| `references/files-and-media.md` | Downloads, uploads, provider-issued result URLs, patterns. |
| `references/troubleshooting.md` | Any failure. Match HTTP status first, then code. |
| `references/verification.md` | Preflight vs provider proof vs workflow proof. |

### Patterns (recipes, not adapters)

`references/patterns/rest-api-key.md` · `references/patterns/bearer-oauth.md` · `references/patterns/multi-part-credential.md` · `references/patterns/async-create-poll-result.md` · `references/patterns/provider-generated-ids.md` · `references/patterns/uploads.md` · `references/patterns/downloads.md` · `references/patterns/provider-media-urls.md` · `references/patterns/soap-session.md` · `references/patterns/complex-apis.md`

Worked examples: `references/patterns/examples/pandadoc.md` · `references/patterns/examples/higgsfield.md`. They are illustrations of the patterns, never adapters — always re-read the provider's current documentation.