AI integrations: the tools we connect, and how we connect them

What every integration page covers

The pages follow one order, so two tools are easy to compare. Each starts with the authentication method and the narrowest scopes we request, then a table of the objects and events we read and write.

• Data flow: which system stays the system of record, and what gets written back.
• Sample workflows: patterns we build with the tool, described plainly and labelled as samples.
• Failure handling: what breaks in production and what the build does about it.
• When not to use it, and the alternatives worth pricing instead.
• Limits and common errors, quoted from the vendor’s documentation with the date we checked.
• Security notes and the questions buyers ask us about that tool.

Choosing within a category

• Automation: Zapier for short, low-volume app links; Make for branching scenarios; n8n when volume grows or data must stay on your server; code when the logic needs tests.
• Channels: WhatsApp where your customers already message you, Twilio when they call or expect a text, and web chat for visitors already on your site.
• Models: pick per task, not per vendor. We test a few models on your own examples and keep a fallback route, and self-host when data cannot leave your network.
• Data and infrastructure: Supabase when app data and embeddings belong in one Postgres with row-level security; Cloudflare when the whole feature can live at the edge.
• Payments: Stripe events drive the workflow, and anything that moves money waits for a person.

Your tool isn’t listed?

Most business systems have an API, a webhook or a reliable export, and that is enough to start. In discovery we read the vendor’s API documentation with you, list the objects the workflow needs, check the authentication options and rate limits, and write the scope down before quoting. If a system has no usable interface, we say so and suggest a workaround.

• CRMs, helpdesks and ticketing tools through their REST APIs and webhooks.
• Accounting, ERP and inventory systems through APIs or scheduled exports.
• Internal databases through a read-only replica or a narrow service account.
• Older tools with no API through files, email or a small adapter that you own.

How we connect a tool

The same rules apply on every page in this directory, whichever tool it covers.

1. OAuth where the tool offers it, so access belongs to your account and can be revoked in one place; otherwise an API key held on the server.
2. Least privilege: one credential per service and environment, with the narrowest scopes that do the job.
3. Webhooks before polling, with signatures verified before any work happens.
4. Idempotent writes, so a retry or a redelivered event never creates a duplicate.
5. Secrets in your secrets manager or the tool’s credential store, never in code, exports or a browser.
6. A runbook at handover: what each connection does, who owns it and how to rotate it.

How the evidence labels work

“In our build stack” marks a tool we build with and document here. It is not a partnership, a certification or a reseller arrangement. “Used on miniailabs.in” marks something you can check on this website. “Delivered in client projects” appears only after the owner confirms shipped client work in writing.

How these pages are kept honest

Vendor limits, quotas and data terms change, so each one is quoted from the vendor’s own documentation with the page and the date we checked it. Sample workflows describe patterns, not client results, and any trace or table that looks like live data carries a Sample data label. Prices for third-party tools are never written into these pages; the proposal quotes running costs from the vendors’ current price lists.