Integrations

What an AI agent can actually connect to

A directory with the real status next to every entry. One native calendar connector, one webhook that reaches almost everything else, and a clear line where a connector simply does not exist.

Available

Self-serve today - a dashboard toggle or a documented endpoint does it.

Beta · account flag

Exists, but hidden until the capability is enabled for your account.

Assisted setup

Runs in production; the connection is set up together with the bitpull team.

Via webhook

No native connector. The post-conversation webhook carries the data.

Planned

On the roadmap. Not callable today, and this site will not pretend otherwise.

Why so much of this is "via webhook"

Because that is the truth, and because it is less of a compromise than it sounds. bitpull posts a finished conversation - transcript, summary, outcome, sentiment - to one HTTPS URL. Every CRM and helpdesk in the list above has a public API that accepts a record. The distance between those two facts is roughly sixty lines of code, or four steps in Zapier, Make or n8n.

A native connector would save you those sixty lines and cost you the field mapping, the deduplication rule and the escalation logic that are specific to your business anyway. The place where a native connector genuinely wins is during the conversation - availability, order status, customer lookup - and that is what agent tools and the Calendly connector address.

Missing something?

If the system you need is not listed, the question to ask is which of the four patterns it fits: post-conversation data (webhook), live lookup during the conversation (agent tool), a channel to talk on (embedding or telephony), or your own interface (REST API). Almost everything is one of those. support@bitpull.ai reaches the people who can tell you which.

If the answer is "one of those, but we do not want to build it ourselves", that is contract engineering rather than a product question - NEOB, the company behind bitpull, does that work.