Infusion - generate Elixir SDKs from OpenAPI specs

Hey everyone,

I’ve been working on something for the past while and finally published it, so I wanted to share.

It’s called Infusion. You give it an OpenAPI spec and it writes a full Elixir SDK for that API. Structs for every schema, a function for every endpoint, retries, streaming, pagination, the whole thing.

The reason I started: almost every API company now generates their SDKs with Stainless, Fern or Speakeasy, and none of them do Elixir. So every time a new API comes out, Python and TypeScript folks get an official SDK on launch day and we’re left writing HTTP calls by hand or hoping someone keeps a community client alive. I tried the two Elixir generators that already exist on OpenAI’s spec first. One crashed, and the other only worked after I forced it, and it turned union types into empty structs. So I built my own.

Using it looks like this. Add it as a dev dependency:

{:infusion, "~> 0.1", only: :dev, runtime: false}

and point it at a spec:

mix infusion.gen https://raw.githubusercontent.com/github/rest-api-description/main/descriptions/api.github.com/api.github.com.json --name GitHub

1-generate1078×405 47.8 KB

That’s the entire GitHub API, about 1,300 endpoints, in 16 seconds. What comes out is a normal Mix project you can read through:

3-generated-code1078×668 83 KB

And these are real calls to GitHub through it:

5-live-calls1078×586 62.8 KB

The repo comes back as a proper struct. The 404 at the bottom is on purpose, I asked for a repo that doesn’t exist, just to show what errors look like. You get one error struct with a type you can match on, like :not_found or :rate_limit, plus GitHub’s request ID.

Pagination was the fun part. Specs never say how an API pages its results, so Infusion looks at each endpoint and works it out. Cursors, page numbers, GitHub’s Link header, next-page URLs, it handles all of them. Every list endpoint gets an _all function that gives you a lazy stream, and pages only load as you read:

6-pagination1078×546 85.1 KB

Streaming works too. Endpoints that send Server-Sent Events get a _stream function. This one is live Wikipedia edits coming in through an SDK generated from Wikimedia’s spec:

7-streaming1078×685 120 KB

I’ve been testing it on OpenAI, Stripe, GitHub, Twilio and Cloudflare’s published specs. All five generate SDKs that compile without a single warning, and Cloudflare’s is huge (3,778 endpoints). GitHub and Wikimedia I’ve tested against the real APIs. The rest only against stubs so far, because I don’t have keys for everything.

There are two packages:

• infusion is the generator you run: infusion | Hex
• infusion_runtime is what every generated SDK runs on. It handles HTTP, retries, decoding and errors, and you never add it yourself: infusion_runtime | Hex

Splitting it that way keeps the generated code small, and a fix in the runtime reaches every SDK without regenerating anything.

It’s 0.1, so it’s rough in places. The function names come straight from the spec, so some of them are clunky. You can see it in the Wikimedia screenshot, get_v2_mediawiki_recentchange_stream is not a name anyone would pick. Fixing names is what I’m working on next. Objects that a spec defines inline still come back as plain maps, and there’s no config file yet, so for GitHub you have to set auth: :bearer in your config yourself.

If you try it on a spec you use and something breaks, please open an issue with the spec attached. That helps me more than anything. I’d also love to know which API you’d want an SDK published for first. I’m leaning towards GitHub.

Code is here:

Docs: infusion v0.2.0 — Documentation

Thanks for reading.