Skip to main content

What Connect does

Gainable Connect is the integration layer between your Gainable app and external systems. For Gaia Autopilot, Connect plays two roles:
  • Outbound. The targets agents can reach when they call tools like send_slack or call_external.
  • Inbound. The sources that fire webhook triggers.
If you’ve used datasets for ingesting data, Connect is the same idea applied to action and event flow. Datasets bring data in for the Copilot and the build agents to read. Connect routes outbound work and inbound events for agents.

Outbound channels

Every outbound integration lives behind a typed tool and inherits a default risk tier. The org configures credentials once; the agent calls the tool.

Slack

SMS

Calendar

Outbound calendar operations through the configured calendar provider (Google Calendar, Microsoft 365).

DocuSign

Stripe

Generic webhooks (call_external)

When the registry doesn’t have a dedicated tool, use call_external.
The runtime can’t reason about what an arbitrary endpoint does, so the default tier is high. If the call is well-understood and idempotent, it can be graduated.

Inbound webhooks (as triggers)

Inbound webhooks become webhook triggers on a playbook. The runtime provisions a unique URL per trigger and verifies signatures where the source supports it.

Provisioning

When you add a webhook trigger, Connect generates a URL:
You configure the source system to POST to that URL.

Signature verification

The runtime rejects unverified webhooks before the playbook runs. Rejections are logged in the action log for debugging.

Common inbound sources

Configuring credentials

Credentials are stored at the org level, not per-app. To add a Slack workspace, a Stripe key, or a Twilio account, the org admin connects it once. All apps in the org can use the connected services through the tool registry.
Credentials never appear in the action log. They’re referenced by name (e.g. secrets.stripe_key); the runtime resolves them at call time and never logs the resolved value.

Allow-lists for outbound recipients

For external messaging tools (send_email, send_slack to external workspaces, send_sms), Connect supports allow-lists at the org level: The allow-list is applied after the draft is approved but before the underlying tool runs. A user can approve a draft and still see it blocked if the recipient isn’t allowed.

Best practices

Inbound webhooks without signature verification are an attack surface. Configure the secret on the source side and the runtime will reject anything unsigned.
A new sales agent can email acmecorp.com and gainable.dev. After a clean approval history, expand. Loud allow-lists invite mistakes.
Every call_external is a system the runtime can’t reason about. Prefer a first-class tool when one exists. If you find yourself using call_external for the same target repeatedly, that target is a candidate for promotion.
Capture a real payload from the source, then replay it through Simulate on last 30 days. It’s the safest way to verify your filter and steps.

Learn more

Tools

The fixed registry, including outbound tools

Triggers

Webhook trigger configuration

Risk tiers

Default tiers per outbound channel

Datasets

Inbound data ingestion (different from action and event flow)