Every API, including the one released this morning.

Air Pipe ships no connector catalogue. Databases, Google services, AWS, email and MQTT have native actions; everything else is a single http: action. The practical effect is that the service you need is already supported — there is no node to install and no roadmap to wait for.

The list below is not the coverage

Air Pipe has no connector catalogue, deliberately. Databases, Google, AWS, email and MQTT have native actions; every other API is a single http: action with whatever auth helper its scheme needs. There is nothing to install and no roadmap to wait for — an internal service that only exists inside your network works the same way as Stripe, and so does an API published after this page was written. What follows is a set of worked examples, not a boundary.

Worked examples

• PostgreSQL — Native database driver — Query Postgres directly from a config — parameterised, pooled, and traced per statement.
• MySQL — Native database driver — MySQL and MariaDB on the native driver, with the same parameterised query action as every other database.
• MongoDB — Native database driver — Document operations against MongoDB, Atlas, Azure Cosmos DB or Amazon DocumentDB.
• SQLite — Native database driver — An embedded database in the same single binary — the fastest way to get a real API with real storage running.
• SQL Server — Native database driver — Microsoft SQL Server on the native driver — the same query action, against the database your enterprise already runs.
• pgvector — Native database driver — Vector search on the Postgres you already run — embeddings in, nearest neighbours out, no separate vector database to operate.
• OpenAI — One http: action — Chat completions, embeddings and tool-calling agents. The agent action speaks the OpenAI shape, so this is one line of config.
• Anthropic — One http: action — Claude as the model behind an agent action, or as a plain completion call in the middle of a workflow.
• Google Gemini — One http: action — Gemini through its OpenAI-compatible endpoint — same agent action, different URL.
• Ollama — One http: action — A model you host yourself, called from a config you host yourself. Nothing about the request leaves your network.
• Slack — One http: action — Post messages, handle slash commands and respond to interactive components — all as ordinary HTTP in and HTTP out.
• Discord — One http: action — Webhooks in, bot messages out, and signature verification on interactions without a library to keep current.
• Telegram — One http: action — A bot endpoint is a webhook interface and one http action — including AI bots that answer with a model in between.
• Twilio — One http: action — Send SMS, receive SMS as a webhook, and put a model between the two if you want the bot to answer.
• Resend — Native email action — Transactional email as a first-class action — no SMTP server to babysit and no template engine to install.
• SMTP — Native email action — Any SMTP server, including the one inside your own network, as a native action rather than a shelled-out script.
• Stripe — One http: action — Receive webhooks with signature verification, write them to your database idempotently, and call the API back — in one config.
• Shopify — One http: action — Order and product webhooks verified, stored and fanned out to whatever else needs to know.
• GitHub — One http: action — Repository webhooks in, the REST API out — and a schedule in the same config for the things nobody wants to poll by hand.
• Airtable — One http: action — Sync records both ways on a schedule, with pagination handled as a loop in the config rather than a cursor you maintain.
• GraphQL — One http: action — A GraphQL call is a POST with a query string. No client library, no codegen step, no schema to vendor.
• Kubernetes — One http: action — Service discovery against the Kubernetes API, so a config can route to pods that did not exist when it was written.
• Docker — One http: action — Container discovery and health from the Docker API — and the engine itself ships as a container when you want it to.
• Auth0 — One http: action — Verify Auth0 tokens against JWKS in front of every route, with the claims available to the actions behind it.
• Supabase — Native database driver — Supabase is Postgres, so the native driver talks to it directly — and its JWTs verify in front of the route.
• Firebase — Google service account — Push notifications through FCM, using the same signed-JWT exchange as every other Google service.
• Google Sheets — Google service account — One action mints the token, the next is plain REST. The hard part of Google — the signed JWT exchange — is the part you do not write.
• BigQuery — Google service account — Run a query on a schedule and email, post or store the result — the token exchange is one action.
• Amazon S3 — AWS signed request — Presigned uploads and downloads, and objects read straight into a workflow — signing handled for you.
• Cloudflare — One http: action — R2 speaks the S3 API, and the rest of Cloudflare's control plane is ordinary REST.
• MQTT — Native MQTT — Publish and subscribe natively — and run the broker itself from the same binary if you would rather not operate one.
• Prometheus — One http: action — Every deployment exposes /metrics, labelled by interface rather than by URL — so IDs in paths never blow up cardinality.
• Grafana — One http: action — The metrics are plain Prometheus and the traces are plain OTLP, so a Grafana stack needs no adapter to read them.
• OpenTelemetry — One http: action — Set one environment variable and every request becomes an end-to-end trace — request, action, database call and lookup.
• Datadog — One http: action — Datadog's OTLP intake takes the traces as they are. No agent to install beside the binary, no instrumentation to write.