The vendor brochure says "integrates with hundreds of tools." Open the actual integration directory and the number is closer to 40, with another 60 listed as "via Zapier" or "via Make." For most SMB use cases that is plenty. For an operator trying to wire an industry-specific tool into a finance system into an AI agent into an e-signature flow into a calendar, it is rarely enough.
What "custom" means at the connector layer is that there is no closed list. The constraint is no longer "is this on the integration directory" but "does this third party have an API." For modern SaaS, the answer is almost always yes.
The Current Heed Connector Catalog
What follows is the working set of connectors we have implemented across active client builds. Each one is a production-grade integration with OAuth or service-token auth, retry and backoff handling, observability, and audit logging. Not a Zapier zap. Not a one-time export.
Identity and SSO. Microsoft Entra ID for enterprise tenants. Okta for security-forward firms. Google Workspace for smaller teams. JumpCloud where the IT team has already standardized. SAML and OIDC patterns supported across all four.
Practice management. Lawcus and Clio for law firms. Procore for general contractors and construction. ServiceTitan for trades and home services. PracticePanther where the firm has chosen it over Lawcus. Each one has a different API shape, a different rate limit, and a different idea of what a "matter" or "job" looks like. We translate at the connector layer.
Communications. RingCentral for cloud phone, with call recording and SMS. Twilio for programmatic voice and messaging. ElevenLabs for conversational AI agents (the same widget you see at the bottom of this page). Microsoft Teams for chat and meetings. Slack for chat where the firm prefers it.
Productivity. Microsoft 365 (Outlook, Word, Excel, OneDrive, SharePoint) for the dominant enterprise stack. Google Workspace (Gmail, Docs, Sheets, Drive) for the rest. Read and write access to documents, calendars, contacts.
Finance. QuickBooks Online for the GL. QuickBooks Time for time tracking on construction and trades. Stripe for online payments. Square for in-person and link-based payments. Bill.com where the firm has invested in it as an AP layer.
CRM source-of-truth. Salesforce in read-only mode for clients mid-migration off Salesforce. HubSpot in read-only mode for the same scenario. The custom dashboard becomes the new source of truth, and the legacy CRM provides reference data until the migration is complete.
AI providers. Anthropic for the agentic and reasoning workloads. OpenAI for image generation and a few specific text use cases. Perplexity for deep research with citations. Each provider routed through the right model for the right task, with audit logging on every call.
Storage. Cloudflare R2 for the canonical file store on Cloudflare-native builds. AWS S3 where the firm has standardized on AWS. OneDrive and SharePoint for Microsoft-native firms. Google Drive for the rest. Same connector pattern, different backend.
E-signature. DocuSign and Adobe Sign for firms that want to keep their existing tool. Native e-signature for firms moving to the consolidated portal pattern (see the secure client portal post).
Calendar. Google Calendar and Outlook for scheduling, free/busy lookups, and meeting management. Calendar.app.google integration for booking flows where the firm prefers it.
The Auth Pattern
Every connector follows the same authentication pattern. OAuth 2.0 where the third party supports it (most do). Service-token auth for legacy APIs that do not. Tokens stored in Cloudflare KV or D1, encrypted at rest, scoped per-tenant.
One pattern that matters more than people realize: every token is associated with a specific human inside the firm. Not a service account. Not a shared credential. When the agent reads a Lawcus matter, it does so as a specific attorney's identity, with that attorney's permissions. When it writes back, the audit trail captures who took the action and through what agent.
That pattern is what makes the audit log defensible. If a client, a regulator, or an opposing counsel asks who did what when, the answer is in one place, with full chain of custody from the human, through the agent, to the third-party system.
The Audit Layer
Every API call to a third party is logged. Request, response, latency, status code, retry count. Stored in a queryable index that the firm can interrogate without our help.
The most common question we get is "did the agent do what the client thinks it did." The audit log is the answer. It is not a black box. It is a searchable record of every action the agent took, which third party it talked to, what it sent, and what came back.
For ISO 42001-aligned firms, the audit layer also captures the model used, the prompt template version, the human who triggered the action, and the approval chain (if the action required one). That is the evidence the auditor will ask for, produced automatically.
How We Add New Connectors
The standard pattern for a new connector takes about a week of engineering time. Not because the integration is hard, but because we apply the same checklist every time.
- Auth and discovery. Get OAuth or service-token credentials. Map the endpoints we need against what is documented. Identify rate limits and pagination.
- Read endpoints first. We almost always start with read-only access. Pull the data into the staging environment. Verify schema. Identify edge cases (empty values, deleted records, soft-deletes).
- Write endpoints with audit. Once reads are stable, add write endpoints. Every write is bracketed by a logged "intent to write" and a logged "result of write," so the audit trail is complete even if the third party returns a partial success.
- Retry and backoff. Exponential backoff on rate limits and 5xx errors. Idempotency keys where the third party supports them, so retries do not create duplicates.
- Observability. Latency, success rate, retry rate, error rate per endpoint. Surfaced in the firm's dashboard so they can see when the connector is degraded before they hear about it from a user.
That checklist is the reason we can quote new connectors in days rather than weeks. The pattern is repeatable, and most of the engineering work is in the schema translation and the edge cases, not in the API plumbing.
Cost Economics
For a new client, the first connector is the most expensive because we are setting up the auth pattern, the audit layer, and the observability stack. Each subsequent connector reuses that infrastructure. By the third or fourth connector, the marginal cost is low enough that we can scope a new integration the same week the client asks for it.
That economics is what makes "connected to everything" actually true. The firm is not paying $50,000 per integration. They are paying for the first build, then paying a small marginal cost per added connector, then keeping all of them under one auth, audit, and observability layer.
Where Zapier or Make Still Wins
To be clear about the scope: there are use cases where Zapier or Make is the right answer.
If you have 20 or more low-volume integrations across a long tail of niche tools, with no custom logic on top, Zapier or Make can wire them together for $50 to $200 a month and you are done. The compromises (cloud-routed data, no audit trail to speak of, fragile zaps that break with API changes) are acceptable when the use case is "send a Slack message when a Typeform is submitted."
Custom wins anywhere with custom logic on top of the integrations. AI agents that read from one system and write to another. Cross-platform reconciliation. Audit-bound workflows in regulated industries. Branded client experiences that have to look like the firm, not like a SaaS pipe. The integration tax compounds in those cases, and Zapier cannot compete.
The Right Question to Ask
If you are evaluating a custom build, the question to ask is not "which integrations do you support." It is "what is your pattern for adding a new one, and how long does it take." A working answer to that question is the difference between a real custom platform and a glorified template.
Read the broader architecture of how we build at custom-apps-dashboards.html, or bring a list of the tools you would need wired together and we will scope the connector list against the catalog above.