IntegrationsWebhooks & API

Webhooks and API

One API across Alice and Julian. Push data in, pull outreach and outcomes out, trigger motions from any system, and subscribe to events with webhooks.

11x exposes one API across both Alice and Julian. It is bi-directional: you push custom product, prospect, and proprietary data in, and pull outreach, transcripts, research, replies, and outcomes back out. You can trigger an 11x motion from any system — a CRM field change, a product signal, a form submission — and subscribe to webhooks for real-time automation.

The endpoint reference is not published yet. This page covers the integration model, the patterns, and the operational practices. For the current endpoint list, authentication scheme, event catalogue, and rate limits, contact your 11x representative or email support@11x.ai. This page will be updated when the public specification is available.

What the API is for

When to use the API instead of a native connector

Use the native connector when one exists. Reach for the API when:

SituationApproach
You use Salesforce, HubSpot, Pipedrive, or ZohoUse the native connector — no API work needed
You use a different CRMAPI
You want to trigger on a product usage eventAPI or Dynamic Triggers
You need 11x data in a warehouseAPI, pulling outcomes on a schedule
You want to notify a system other than SlackWebhooks
You have proprietary firmographic or intent dataAPI, pushing it in as custom attributes

The trigger pattern

The most common custom integration is triggering a motion from an event your own systems detect.

Typical triggers worth wiring up:

  • A free-tier account crosses a usage threshold → start a PLG conversion play
  • A support ticket indicates expansion intent → start a Julian callback
  • A form submission on a high-intent page → trigger Julian for sub-60-second response
  • An account's renewal date approaches → start an expansion play
  • A CRM stage change to Closed Lost → queue the account for a revival play in six months

Webhook practices

Whatever the final event catalogue looks like, these practices apply.

Return 2xx fast, process asynchronously

Acknowledge receipt immediately and do the real work in a queue. Slow handlers cause retries, and retries cause duplicates.

Make your handler idempotent

Assume any event can be delivered more than once. Key your processing on the event ID so a redelivery is a no-op.

Verify the signature

Validate the signature header before trusting a payload. An unauthenticated webhook endpoint is an open write path into your systems.

Log the raw payload

Store what you received before parsing it. When something is wrong, the raw payload is the only reliable record.

Handle unknown fields gracefully

New fields get added. Your parser should ignore what it doesn't recognise rather than failing.

Alert on delivery failure

A silently broken webhook endpoint looks exactly like a quiet week of pipeline.

Test your handler against a deliberately malformed payload and a duplicate delivery before you rely on it. Both will happen in production.

Security

  • Treat API credentials as secrets. Store them in a secret manager, never in source control or client-side code.
  • Scope credentials narrowly. Separate keys for read-only reporting and write-capable automation.
  • Rotate on a schedule, and immediately when someone with access leaves.
  • Restrict by IP where your environment supports it.
  • Verify webhook signatures on every request — see above.
  • Don't log full payloads containing personal data in systems with broad access. Transcripts contain what a prospect said.

See also the 11x security overview and the privacy policy.

Still need help

For the current endpoint reference, authentication details, event catalogue, and rate limits, email support@11x.ai or contact your 11x representative.