Adding an integration

Nothing gets installed. Nothing gets added to a catalogue. Adding an integration is a conversation with the assistant, and it finishes inside that conversation.

Name the system

The moment you mention a system, the assistant declares it on the workflow. The systems already connected to your account show up as context, and they are context only: the assistant is not choosing from them. Name whatever the process actually needs.

You will not be told a system is unsupported, because there is no list to check you against. Publishing checks the connection behind the trigger itself before it arms anything; other systems the workflow names are not checked at publish, a missing credential there shows up on the first run that needs it, with a notification.

Three things never get declared, because every workflow has them: web search, a code and file sandbox, and a real browser.

Connect it in the same conversation

Right there in the interview, the assistant walks you through the login card or takes the key you provide. See connecting accounts for what each route does with the credential.

Getting the credential first matters more than it looks. Subscribing to a service's events usually needs its own permission scope, separate from reading data, and a missing scope shows up as a refusal much later when the subscription is created. The assistant is meant to work out what it needs before it asks you for access, so you are not sent back through a consent screen twice.

Then it gets written

For actions during a run, the code arrives when the workflow gets codified. Each function talks to the system over plain HTTP. Only the Python standard library is available, and no packages get installed, so the code uses urllib.request rather than a third-party HTTP client. What that code may reach is declared on the step and enforced before it runs, which capabilities covers in full.

For events, the assistant writes an integration bundle: the code that checks whether the subscription exists, creates it, and deletes it again. A service without webhooks gets a single polling function instead. The engine runs those slots, keeps the subscription in step with what you asked for, and delivers each event to a secret URL unique to that one registration. A mailbox is polled by the platform itself, every five minutes, so no code is written for it; see email triggers.

Signature checking and the registration handshake are not code. They are declared as data on the bundle, a header name and an algorithm, and the engine executes them. That keeps any authored code entirely off the inbound path, where requests arrive without being signed in as anyone.

For a handful of widely used services the assistant starts from a stored note about that service's webhook API: the documentation URL, the auth shape, and the scopes a subscription needs. That is a head start on research, not a supported-apps list. Everything else starts from the service's own docs.

When one breaks

An integration that failed halfway is not retried by the next sweep. A call that timed out may well have landed at the other end, and a blind retry turns one subscription into two. The registration parks for repair instead, and the fix comes back to you as a change you approve.

The same logic applies inside a run: nothing automatically repeats a step that had internet access when it failed. See what a workflow's code may do.

What you are trading

This model buys you reach. Any service with an API is fair game, on the day you need it, without a feature request.

What it costs is uniformity. Your integration is written for your workflow, so its quality depends on what the assistant could work out about that API, and two workflows talking to the same service do not share one implementation. When something changes at the other end, the repair is yours to approve rather than something that arrives silently in a release.