Live before lunch: what the first hour with openfeed actually looks like
This is a build log, not a brochure. If you want the pitch, it's one line: consented Australian banking and energy data through one API, no accreditation project. Here's what happens after you decide to try it.
By Chris Katsinas, openfeed — powered by Biza.io
0:00m — Get a key
No sales call, no waiting list, no accreditation. Simple pricing at 10c per consumer, per app, per month. First 10 free.
That’s the whole pricing model, no platform fee, no tiers.
0:05m — Point your agent at the docs
We publish llms.txt, an OpenAPI 3.1 spec and full-text docs, and we publish them for this exact purpose. Point Cursor, Claude Code or whatever you’re running at the docs and ask it to write the integration. It reads the auth flow, the endpoints and the consent model without you narrating.
This is the part people don’t believe until they watch it. The reason it works isn’t magic, it’s that the surface is one API instead of one integration per data holder. There’s simply less to learn.
0:20m — The consent flow
This is the piece worth understanding properly, because it’s where the model differs from everything else.
The consumer consents once at their bank or energy retailer, the heavy CDR flow, done once. Then sharing with your app is a second, much lighter consent: one screen, one tap. They can revoke your app without breaking their holder connection, and they see every app they’ve shared with in one dashboard.
In shorthand, we say “one consent”. Precisely, it’s a two-consent design, and the precise version is the more impressive one: your users go through the ten-screen dance once, not once per app. If they’ve already connected for another openfeed app, your activation is a single tap.
0:40m — First call
Build complete and ready for your first grant. Most people are through in under an hour.
The limits, before you find them yourself
Batch refresh is every 4 hours for banking and every 6 hours for energy. It is a batch cadence, not a stream, and we’d rather say so here than have you discover it in staging, but account balance is always live. So if you want a live balance, you can get it. For other purposes (budgeting, lending assessment and energy switching etc.), that cadence is fine. If your use case needs something different, tell us. Cadence tiers are on the roadmap and they’ll be priced publicly.
openfeed is new but the infrastructure isn’t: it runs on the plumbing behind 30+ live data holder implementations, under ISO 27001, SOC 2 Type 2, FAPI 2.0 and ASAE 3150 assurance.
Why this beats the thing you’re probably doing now
Same speed to integrate as a scraped feed, but the API is FAPI 2.0 so on a far more secure baseline. Consented and sanctioned instead of credential-harvested. Your users never hand over a banking password, and your feed doesn’t break the next time a bank changes a login page.
There’s a clock on the alternative, too. The Government has called screen scraping “fundamentally unsafe” and asked Treasury for advice on a full and formal ban. The sanctioned path was always the right answer, it just wasn’t usable until now.
No form, no sales call. Kick off here →
