Path to production

How to take your openfeed app from first build through verification and into the public app catalogue — the gates you cross, and the guidance to follow along the way.

openfeed runs a single live platform. There is no separate developer environment — you register today, build against real data, and progress through a small number of gates before you can serve consumers at scale. This guide walks you through those stages.

Stage 1 — Build and test on openfeed

10 free credits: enough to build and test without a bill, if you run out you can always recharge.
Up to 5 active user grants across all your apps. Use them to connect your own bank and energy accounts, then invite a small pilot group to try your app end-to-end. Revoking a grant frees a slot.

The 6th active user to try your app before you’re verified will see a “sign-ups limited” screen — that’s the trigger to move to Stage 2.

What to prove works before requesting verification

Give your integration a genuine workout with your own accounts first. You’ll want to see:

Login with openfeed: the user round-trips through openfeed and returns authenticated.
Onward disclosure consent: the user picks accounts and confirms; your app receives the grant_id on the access token.
Data fetch: banking, energy, or both (whatever your app declares).
Refresh: the access token renews silently, users aren’t bounced back to sign-in on every session.
Revocation: you handle 403 disclosure_grant_required by sending the user back through the consent flow.

You will also encounter these in production over time — worth understanding how your app reacts:

Amending a grant (grant_management_action=replace): a user changes what they share, your cached view updates on the next call. See Grant management & lifecycle.
Credit exhaustion (402 credit_exhausted): you prompt a credit top-up in your app, rather than sending the user back through consent.
Rate limiting (429): you back off exponentially.

See Handling errors from the openfeed API for the complete response catalogue.

Stage 2 — Get verified

Verification is how you become a trusted developer on the platform. Verified developers can onboard consumers without the 5-grant cap and can list their app in the public catalogue.

When to verify

You can verify whenever you’re ready — but you’ll get the most out of the process if your integration is already working end-to-end. Verification is the last gate between you and scaling.

What you’ll submit

Verification is self-service in the openfeed developer portal. You’ll provide:

Entity type: Company or Sole Trader.
Legal name, trading name, ABN or ACN .
Contact number and primary contact email: reused from your openfeed account where they’re already verified.

We currently manually verify all businesses during launch phase.

How it’s reviewed

A member of the Biza team will contact you with further details to confirm your business details while taking a look at the app you’ve built. We’d love to talk to you as part of that — expect a phone call.

What verification unlocks

Unlimited consumer grants: the 5-grant cap is lifted.
Public catalogue listing: you can publish your app for consumers to discover (Stage 3).

Stage 3 — Publish your app

Once you’re verified, your app can appear in the openfeed app catalogue so consumers can find it.

Before you publish

Your app is registered and working (Stage 1).
Your business is verified (Stage 2).
Ideally, prepare some catalogue polish (nice to have, not required to publish):
- Tagline: a one-line pitch.
- Category: the type of experience your app offers.
- Developer/publisher name.
- Screenshots: a handful of your app in action.
- “Login with openfeed” SSO indicator, if your app uses openfeed as a sign-in provider.

You can edit any of this after publishing.

How to publish

Publishing is a single toggle in the developer portal — set your app to public and it enters the catalogue. Flip it back to unpublish; existing consumer grants continue either way.

Stage 4 — Handling your users’ data well

You’re now a receiver of openfeed data. While the user has agreed to share the data under the Privacy Act (exiting the CDR ecosystem) the data you receive is governed by the Privacy Act once it leaves the platform. These are our expectations of a well-run integration.

Tokens

Access tokens are session credentials. Keep them server-side or in httpOnly cookies. Never write them to localStorage, and never expose them to client-side JavaScript.
Refresh tokens are higher-stakes — they can mint new access tokens without the user present. Server-side only and on an encrypted storage device.

Personal information

Under the Privacy Act 1988 and the Australian Privacy Principles (APPs), the banking and energy data you fetch is personal information about your users. Once it leaves the openfeed platform it is governed by the Privacy Act — not the CDR rules. That comes with concrete obligations:

Transparency (APP 1): maintain a clearly expressed, up-to-date privacy policy that describes what personal information you collect, why, and how you handle it.
Collection (APP 3): only collect personal information that is reasonably necessary for your service’s stated purpose. Don’t pull scopes your app doesn’t actually need.
Notification (APP 5): tell users what you’re collecting and why at or before the time of collection — your onboarding or consent screen is the natural place for this.
Use and disclosure (APP 6): use personal information only for the primary purpose for which it was collected. Don’t on-sell, share with third parties, or use it for secondary purposes (such as marketing) without separate consent or a lawful basis.
Direct marketing (APP 7): if you use financial or energy data to target users with offers, you must provide a simple opt-out mechanism and honour it promptly.
Cross-border disclosure (APP 8): if you store or process data on infrastructure outside Australia — including cloud regions — ensure equivalent Privacy Act protections are in place before transferring.
Data quality (APP 10): take reasonable steps to ensure the personal information you hold and use is accurate, up to date, and complete.
Storage and security (APP 11): encrypt personal information at rest and in transit; implement access controls; have a process to detect and respond to data breaches (see also the Notifiable Data Breaches scheme). APP 11 also requires you to destroy or de-identify personal information you no longer need.
Retention: keep information only for as long as needed for the purpose it was collected for. When that purpose ends, destroy or de-identify it.
Access and correction (APP 12 & 13): users have the right to request access to the personal information you hold about them and to have inaccuracies corrected. Have a documented, reachable path for both.
Deletion: if a user asks you to delete their information, do so. Revoking their openfeed grant stops you receiving new data — it does not delete data you’ve already fetched. That side is on you.

Review the APP quick reference and the OAIC’s CDR guidance for business before you go live.

Once data leaves openfeed it is no longer inside the CDR ecosystem. The CDR’s data minimisation, purpose limitation, and deletion rules no longer govern it — the Privacy Act 1988 and the Australian Privacy Principles do. You have already received consent to access this data, but you remain legally responsible for how you store, use, disclose, and ultimately destroy it. These are not soft guidelines — non-compliance with the APPs can attract OAIC investigation and civil penalties.

Logging

Never log tokens, JWT payloads, or account identifiers to application logs.
openfeed scrubs card numbers (PANs) from transactions on the wire — your logs are still your own responsibility.

Stage 5 — After launch

You’re live. These are the things worth watching so problems surface quickly.

What to monitor in your app

403 disclosure_grant_required rate: a normal background level is fine (users revoke), but a spike usually means a configuration regression on your side or a UX moment that’s driving users to disconnect.
402 credit_exhausted: you have run out of credits. Alert on this before it happens by tracking your credit balance in the developer portal.
429 rate limited: you’re hitting a ceiling; back off harder and investigate whether you’re polling more than you need to.
Holder-side 5xx: a specific bank or energy retailer is degraded. Retry with backoff and jitter; don’t hammer it.

Credit balance

Keep an eye on your credit balance in the developer portal and top up before you run out. 402 credit_exhausted suspends metered access for affected grants until you do — the consumer’s consent is intact, but data calls will fail until you refill.

Grant lifecycle

Watch your grant create and revoke rates over time. A rising revoke rate is a leading indicator of a UX issue worth investigating.
Watch replace rates — users amending what they share is a healthy signal that they trust your app to reflect the change.

References

APP quick reference
OAIC’s CDR guidance for business before you go live.