GitHub in a config. No connector required.

Repository webhooks in, the REST API out — and a schedule in the same config for the things nobody wants to poll by hand.

How Air Pipe reaches GitHub

There is no GitHub connector, because there does not need to be one. GitHub's API is HTTP, so it is one http: action — the method, the URL, the auth helper for its scheme, and the body. The same action reaches every other API you use, including the ones that do not exist yet.

• - name: Comment http: method: POST url: "https://api.github.com/repos/a|ap_var::REPO|/issues/a|body::number|/comments" bearer_auth: a|ap_var::GITHUB_TOKEN| body: | { "body": a|Summarise::content| }
• Route: One http: action
• Auth: Token · HMAC webhooks

The same config is four things at once

Whatever you build against GitHub is not locked to one surface. The same config can expose HTTP routes, run on a cron schedule, receive webhooks, and be called by an agent as an MCP tool — with one auth model and one deploy. You do not rebuild the workflow to make it callable, and you do not bolt an MCP node onto the end of a canvas.

• HTTP routes with OpenAPI docs generated from the config
• Cron schedules and webhooks in the same file as the API
• MCP tools with input schemas derived from the route's own assertions
• OpenTelemetry traces and Prometheus metrics on all of it

Readable config you own, managed or self-hosted

The artifact is a config you can read, diff and review in a pull request — not a canvas stored in a vendor's database. Run it on Air Pipe's managed cloud or self-host the single binary, with the same config either way, and your credentials and data staying on your infrastructure when you choose to self-host.

Frequently asked questions

• Is there a GitHub connector I have to install? No — and there is no queue to join waiting for one. Air Pipe has no connector catalogue by design. GitHub is reached with the same http: action as every other API, which is why a service released this morning works as well as one released a decade ago.
• Where do the credentials live? In managed variables or secrets, referenced from the config by name — never in the config text. Any action that mints a token should also carry hide_data_on_success: true, or the token comes back in the response body.
• Can an agent call this? Yes, and you do not build anything extra for it. Mark the interface mcp: true and the same route becomes an MCP tool, with its input schema derived from the assertions the route already carries. An agent calling it gets the same auth, the same validation and the same traces as an HTTP client.
• What do I get to see when it fails? An end-to-end OpenTelemetry trace covering the request, each action and each database call, Prometheus counters and durations on /metrics, and the run history for the deployment. None of it is written by you and none of it is a separate product.