Integrations

An integration is a connected provider account scoped to one organization. The provider catalog lists what tools exist; integrations are the credentials that let you actually call them.

Two auth modes

Mode	Who pays	Setup
`managed`	Pay Oxygen credits per call; Oxygen holds the provider key	None
`byok`	Pay the provider directly; you connect your own account	OAuth or API key per provider

Some tools support both. CRMs, outbound sequencers, and most LinkedIn tools are BYOK-only — the data needs to live in your account.

Working with integrations

oxygen integrations list --json
oxygen integrations connect <integration-id> --json
oxygen integrations actions <integration-id> --json
oxygen integrations run <integration-id> <action-slug> --input '{...}' --dry-run --json
oxygen integrations disconnect <integration-id> --json

Some connections open an OAuth approval URL. Others ask for a provider API key in a secure connection flow.

integrations actions serves two action sources. Composio toolkits return app actions (composio.<toolkit>.<action>). Native BYOK providers — Salesforge and the rest of the Forge family (Mailforge, Infraforge, Warmforge, Primeforge, Leadsforge), Instantly, Smartlead, Zapmail — are not Composio toolkits: their actions are the provider's native operations from the provider catalog, run with your connected BYOK key. The actions response marks these integrations with source: "native_provider".

The same operations are runnable as integration actions or directly as tools:

oxygen integrations actions salesforge --json
oxygen integrations run salesforge <action-slug> --input '{...}' --live --json
oxygen tools run salesforge.<action-slug> --input-json '{...}' --mode live --json

Read actions run live without approval. Write actions require a dry run first, then --live --approved. Native BYOK actions consume zero Oxygen credits — the provider bills your connected account directly.

Example: drive Salesforge sequences

Salesforge exposes ~80 native operations: workspaces, mailboxes, sequences, enrollments, sender profiles, replies, contacts, and validations. Creating and launching a Salesforge sequence from Oxygen:

# Discover actions, the workspace, and its mailboxes (reads)
oxygen integrations actions salesforge --json
oxygen integrations run salesforge get_workspaces --live --json
oxygen integrations run salesforge get_workspaces_by_workspace_id_mailboxes --input '{"workspaceID":"ws_123"}' --live --json

# Create a sequence (write: dry-run, inspect, then approve)
oxygen integrations run salesforge post_multichannel_workspaces_by_workspace_id_sequences --input '{"workspaceID":"ws_123","name":"Q3 launch outreach"}' --dry-run --json
oxygen integrations run salesforge post_multichannel_workspaces_by_workspace_id_sequences --input '{"workspaceID":"ws_123","name":"Q3 launch outreach"}' --live --approved --json

# Enroll contacts, then launch
oxygen integrations run salesforge post_multichannel_workspaces_by_workspace_id_sequences_by_sequence_id_enrollments --input '{"workspaceID":"ws_123","sequenceID":42,"filters":{...}}' --live --approved --json
oxygen integrations run salesforge patch_multichannel_workspaces_by_workspace_id_sequences_by_sequence_id_launch --input '{"workspaceID":"ws_123","sequenceID":42}' --live --approved --json

post_multichannel_workspaces_by_workspace_id_sequences_by_sequence_id_enrollments_remove removes enrollments with the same filter shape. Sequence steps, schedules, and settings patch the same way — integrations actions lists every operation with its input schema.

Sending-pool boundary

Connecting Salesforge or Mailforge does not add their mailboxes to Oxygen's native sending pool. The native sequencer sends only through Google and Microsoft OAuth mailboxes — imported inline or from a connected Zapmail workspace — using the Gmail API and Microsoft Graph; there is no SMTP transport. Mailboxes hosted on Salesforge/Mailforge sending infrastructure cannot join that pool. "Sending through Salesforge" means driving Salesforge's own sequences via the actions above: sends execute on Salesforge's side, and its metrics stay readable from Oxygen (get_workspaces_by_workspace_id_sequence_metrics, get_workspaces_by_workspace_id_sending_data).

Connection shape

Field	Notes
`provider`	Provider name
`auth_mode`	`managed` or `byok`
`status`	`connected`, `disconnected`, `expired`, `error`
`account_label`	Provider-side identifier (workspace name, email)
`scopes`	Granted OAuth scopes, if applicable
`connected_at`, `last_verified_at`	Timestamps
`last_error`	If status is `error`

Provider events

Many integrations emit events when something happens on the provider side (HubSpot contact created, Instantly reply, Attio record updated). Events can fire workflow triggers.

oxygen integrations events list --json
oxygen integrations events enable --source instantly --event email.reply_received --json
oxygen integrations events disable --source instantly --event email.reply_received --json
oxygen integrations events deliveries --json

deliveries shows delivery status for provider events before you debug why a workflow did or did not fire.

Mirroring external state

External writes such as CRM contact create, outbound enrollment, or LinkedIn actions should mirror their useful result back into the originating table through tool/action columns:

Cell field	Holds
`value`	Provider record ID (e.g. `hubspot_contact_id`)
`provenance.outputs.sync_status`	`queued`, `synced`, `failed`
`provenance.outputs.last_synced_at`	Timestamp
`error`	Provider error text on failure

This is what makes the table the audit log — provider state stays inspectable from within Oxygen.

Provider-specific docs

Per-provider quirks, rate limits, and mapping examples live in the Oxygen agent skills. Install them with:

oxygen skills install --agents codex claude-code cursor --skill '*' --json

Provider catalog — the tools each integration exposes.
Waterfalls — combining multiple integrations for fallback.
Columns — wiring row work to provider actions.