Data and research

A Clay integration stores a Clay webhook URL so loops can submit JSON rows into a Clay table.

Clay does not expose a general public API for table reads, arbitrary row updates, or full workspace control. Use Clay's HTTP API enrichment when Clay should call Mobius, and use clay.webhook.submit when Mobius should push a row into Clay.

Capability map

Connect Clay

Clay webhook URLs are table-specific. Connect the URL for the Clay table that should receive rows from Mobius.

curl -X POST \
  "$MOBIUS_API_URL/v1/projects/platform/integrations/providers/clay/connect" \
  -H "Authorization: Bearer $MOBIUS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "webhook_url": "https://<clay-webhook-url>",
    "auth_header_name": "Authorization",
    "auth_header_value": "Bearer <token>"
  }'

{
  "kind": "complete",
  "integration": {
    "name": "clay",
    "provider": "clay",
    "status": "active",
    "config": {
      "webhook_url": "https://<clay-webhook-url>",
      "auth_header_name": "Authorization"
    }
  }
}

Omit auth_header_name and auth_header_value when the Clay webhook does not require an auth header. If you set one, provide both fields so Mobius can send the same header on every submission.

Push rows into Clay

Use clay.webhook.submit from an action step when a run should create a row in the connected Clay table.

{
  "payload": {
    "email": "ada@example.com",
    "company_domain": "example.com",
    "source": "mobius"
  },
  "request_id": "req_123",
  "external_id": "lead_123",
  "callback_url": "https://api.example.com/clay/callback"
}

Mobius sends payload as the Clay row body. If request_id, external_id, or callback_url are set and the payload does not already contain those keys, Mobius adds them before submitting. Use those fields for async request-response flows where Clay enriches the row and later calls back to another endpoint.

The action returns the Clay HTTP status code and any JSON object Clay returns:

{
  "ok": true,
  "status_code": 200,
  "request_id": "req_123",
  "response": {
    "accepted": true
  }
}

A non-2xx Clay response fails the action. Clay webhook submissions create rows, so retries can duplicate rows unless your Clay table handles request_id or another deduplication key.

Clay webhook sources are limited to 50,000 submissions. That limit stays with the webhook source even if rows are deleted, so create a new Clay webhook when the source reaches its limit. Enterprise passthrough tables can process and delete rows for higher-volume streams.

Call Mobius from Clay

Use Clay's HTTP API enrichment when each Clay row should call Mobius. Create a Mobius API key, store it in Clay as an HTTP API header account, then call normal Mobius endpoints from a Clay HTTP API column.

Recommended Clay account header:

Authorization: Bearer $MOBIUS_API_KEY

To start a Mobius run from a Clay row, configure Clay to POST the run-start endpoint:

https://api.mobiusops.ai/v1/projects/platform/loops/<loop-id-or-name>/runs

Use a JSON body that maps Clay columns into the run event:

{
  "event": {
    "email": "{{Email}}",
    "company_domain": "{{Company Domain}}",
    "clay_row_id": "{{Clay Row ID}}"
  },
  "source": {
    "type": "api",
    "id": "clay",
    "label": "Clay"
  },
  "idempotency_key": "clay:{{Clay Row ID}}"
}

The run starts with those values under event.*, so loop steps can read them with templates. Use an idempotency key tied to the Clay row when repeated Clay calls should return the same active run instead of creating another one.

Async Clay callback pattern

Clay does not send native table-change webhooks for arbitrary row updates. For request-response behavior, use this pattern:

1. Mobius calls clay.webhook.submit with a request_id and callback_url.
2. Clay enriches the row through its table columns.
3. A final Clay HTTP API column posts selected result columns to the callback URL.
4. The receiver correlates the result with request_id.

Keep the callback endpoint narrow and authenticated. Clay can store headers for the final HTTP API call the same way it stores the Mobius API key.

Next

• Store project API keys in API keys.
• Call Clay from action steps.
• Use run-start requests from runs.