168 Integrations, One Plugin at a Time

401 plugin-related commits. Four years. 168 integrations.

That averages to roughly one new integration every nine days for the entire life of the project. The math sounds reasonable until you realize that building an integration isn’t the hard part. Maintaining it is.

This is the story of how we built Autopilot’s integration catalog – one OAuth flow, one API quirk, one pagination edge case at a time.

The anatomy of a plugin

Every one of our 168 integrations follows the same architecture. Understanding that architecture explains why building integrations is a grind and not a sprint.

Each plugin needs four things:

Authentication. Usually OAuth2, which means implementing the authorization URL, token exchange, token refresh, and scope management for that specific service. Google alone has different OAuth flows for Sheets, Gmail, Drive, and Calendar. Some services use API keys instead. A few use webhook-based auth. Each auth type has its own error modes.

Triggers. Events that start a workflow. “New message in Slack channel.” “New row in Google Sheet.” “New email in Gmail.” Each trigger needs a polling mechanism or webhook handler, and we support four webhook types: synchronous, asynchronous, polling, and polling-state. The choice depends on how the external API delivers events.

Actions. Operations that execute as part of a workflow. “Send a Slack message.” “Create a Trello card.” “Update a Salesforce record.” Each action needs input validation, API call logic, error handling, and response mapping.

Test run support. Users need to verify their configuration before deploying a workflow. That means every trigger and action must support a dry run mode that validates credentials, checks permissions, and returns sample data without side effects.

Multiply that by 168, and you start to understand the maintenance surface area.

The integration landscape

We didn’t build 168 integrations randomly. They cluster into categories that reflect real business workflows.

Communication (8 integrations). Slack, Discord, Telegram Bot, Line Message, Mattermost, Twilio, SMTP, Pushover. These were the first category we built because every automation eventually needs to notify someone. Slack alone has 14 different action types – post message, update message, add reaction, create channel, invite user, and more.

Social Media (9). Twitter, Facebook Pages, Instagram, LinkedIn, Reddit, Pinterest, Medium, VK, OK. The most painful category to maintain. Twitter’s API went through three pricing tiers and two complete redesigns. Facebook deprecates Graph API versions on a fixed schedule, forcing migration work every 12-18 months.

Google Suite (12+). Sheets, Docs, Drive, Gmail, Calendar, Slides, Forms, Contacts, Tasks, and several others. Google’s APIs are well-documented but deeply complex. The Sheets API alone has different methods for reading, writing, appending, and formatting – and batch operations have their own entirely separate endpoint pattern.

Productivity (8). Notion, ClickUp, Todoist, Trello, Jira, Miro, Asana, Monday.com. These are the integrations our enterprise users request most. The challenge isn’t the initial build – it’s keeping up with the rapid feature iteration these platforms undergo. Notion changes their API every few months.

CRM (4). Salesforce, HubSpot, Pipedrive, Freshdesk. Each of these has its own object model, its own query language, and its own approach to relationships between records. Salesforce’s SOQL is practically a dialect of SQL. HubSpot’s association API requires understanding their graph model.

AI Services (5 direct + 15+ via OpenRouter + 25+ via Replicate). This is where the integration story gets interesting. We built direct integrations for ChatGPT, OpenAI, Claude, and two internal AI services. But the real scale came from OpenRouter and Replicate.

The Replicate automation

82 commits are tagged to Replicate-related work. That’s more than any other single integration, and there’s a reason: we didn’t just integrate Replicate. We automated the integration.

Replicate hosts thousands of AI models across categories: audio generation, image diffusion, music synthesis, video processing, 3D rendering, and more. New models appear weekly. Building a static integration would have been outdated within a month.

Instead, we built a GitHub Actions workflow that runs weekly. It queries Replicate’s API for new and updated models, generates plugin definitions for each one, and commits the changes automatically. Every Monday morning, our integration catalog refreshes itself.

The result is 25+ categories of AI models, all accessible through Autopilot workflows, all maintained by a script that runs while we sleep. It’s the closest thing to self-maintaining code we’ve built.

OAuth is hell

If there’s one universal truth about building integrations, it’s this: OAuth2 implementations are inconsistent across providers, and the inconsistencies will break your assumptions.

The OAuth2 spec defines a flow: redirect user to authorization URL, receive a code, exchange code for tokens, use refresh token to maintain access. Simple in theory.

In practice: Google requires offline access scope to get a refresh token, but only on the first authorization. Salesforce returns different token formats depending on the environment (production vs. sandbox). HubSpot’s refresh tokens expire after six months of non-use, which means automations that run quarterly will silently break. Twitter’s OAuth 2.0 PKCE flow requires a code verifier that must be stored between the redirect and the callback.

We’ve written and rewritten our OAuth handling layer multiple times. The current implementation has provider-specific adapters that handle the quirks of each service’s interpretation of the spec. It’s not elegant. It’s necessary.

API deprecations: the silent killer

Building an integration takes days. Maintaining it takes years.

In four years, we’ve weathered Twitter’s API v1.1 to v2 migration, Facebook’s Graph API version deprecations (v14 through v19), Google’s OAuth consent screen policy changes, Slack’s shift from RTM to Events API, and dozens of smaller breaking changes from services that update their APIs without much notice.

Each deprecation creates a cascade of work: read the migration guide, update the API calls, test every trigger and action, handle backward compatibility for workflows that reference old field names, and deploy without breaking existing users.

We don’t have a dedicated team for this. The same engineers who build new features also fix broken integrations. It’s a tax on velocity that never goes away.

The data utilities nobody mentions

Not all integrations connect to external services. Some of our most-used plugins are internal data utilities.

Datastore provides persistent key-value storage across workflow runs. It’s how users maintain state – counters, last-processed timestamps, accumulated results.

Formatter transforms data between steps. Parse dates, extract substrings, convert currencies, format numbers. It handles the glue logic that makes workflows actually work.

Array, String, and DateTime Utils provide the operations that workflow builders need constantly but that no one builds a product around. Split a comma-separated list. Calculate business days between two dates. Merge two arrays and deduplicate.

Run-JS-Code is the escape hatch. When no integration exists for what you need, write JavaScript. It runs in a sandboxed context with access to workflow variables and returns structured output. It’s the integration of last resort, and it’s one of our most popular.

168 versus 8,000

Zapier has over 8,000 integrations. We have 168. That’s not a fair comparison, and we don’t pretend otherwise.

But integration count isn’t the metric that matters for our users. Coverage of their specific workflow is. A company that uses Slack, Salesforce, Google Sheets, and GPT-4 doesn’t need 8,000 integrations. They need four that work reliably, run on their infrastructure, and don’t send data through third-party servers.

Our catalog covers the services that enterprise teams actually use: the major communication platforms, the dominant productivity suites, the leading CRM systems, and – increasingly – the AI models that are becoming central to business operations.

What 401 commits taught us

Every integration is a contract. Not a legal contract – a maintenance contract. When we ship a plugin for a service, we’re committing to keeping it working for as long as that service has an API.

That commitment compounds. 168 integrations means 168 APIs to monitor, 168 auth flows to maintain, 168 sets of triggers and actions that could break at any time. The Replicate automation helps with AI models, but the other 143 integrations are hand-maintained.

The lesson we’ve learned over 401 commits and four years is that integration work doesn’t scale linearly. The 168th integration isn’t harder to build than the first. But maintaining 168 integrations simultaneously is orders of magnitude harder than maintaining one. Every new plugin we add increases the surface area for things that can break.

We’re still adding integrations. The catalog will keep growing. But we’ve learned to be deliberate about what we add, because every integration we ship is one we’ll be maintaining for years to come.