Connecting a Custom API to a Workflow via OpenAPI Import
Workflows can turn an OpenAPI 3.0 spec into usable capabilities without a pre-built connector — but a raw spec still needs a human pass before it's ready to use.
Instead of waiting for us to build a connector for every API, you can now point Workflows at an OpenAPI 3.0 spec and get back a set of usable capabilities directly.
How it works
Give the importer a spec, and it reads through the defined operations and turns them into capabilities a workflow step can call — stored against your workflow as a connector. We tested this against real specs from Stripe, GitHub, and Twilio: a meaningful share of each API's operations (8%, 4%, and 25% respectively) became usable without anyone editing anything by hand.
What it doesn't do
It's a real time-saver, not a magic button. Two things to know before you rely on it. First, it only reads OpenAPI 3.x — a Swagger 2.0 spec (like Slack's) is rejected outright, because the importer expects the servers[0].url field that only exists in OpenAPI 3. If your target API only publishes Swagger 2.0, you'll need to convert it first. Second, import order is alphabetical by path today, not by usefulness — so the capabilities that show up first in a large spec tend to be account/admin-style endpoints rather than the ones you actually reached for the API to get. In Stripe's spec, for example, /v1/charges lands around position 59, well past the first page.
Who this is for
If there's no pre-built connector for the service you need, this is the path: import the spec, then curate — check which capabilities you actually want live in a workflow, and don't assume the first batch the importer surfaces is the one you're looking for.
This is a real alternative to a fixed integration catalog, and we'd rather describe it accurately than oversell it as one click and done.