Free banking APIs in Australia: sandbox vs production access

Free banking API access in Australia can mean public product information, a bank's own developer API or a sandbox with sample customer data. Choose the access model that answers your question before comparing prices. None of those labels establishes free, unrestricted production access to customers' accounts across Australian banks.

Fiskil's Testing guide describes self-serve signup without a credit card or sales call, and free, unmetered sandbox usage. That makes it a starting point for evaluating an integration. Live customer-data access has a separate approval process and commercial scope.

Choose the right kind of banking API

Start with the information your app needs and whose data you want to access.

Access option	Use it to	Check before relying on it
Public product API	Compare advertised products, rates, fees and eligibility	It provides product information, not a customer's private balances or transactions
Bank-specific developer API	Build within one bank's documented access model	Who may use it, which accounts it exposes and whether third-party applications are permitted
Multi-bank sandbox	Develop a linking and data-retrieval workflow using sample data	Which journeys and fixtures it supports; sandbox providers do not establish live bank coverage
Live customer-data access	Operate an approved service using customer-authorised banking data	Institution and account eligibility, access arrangement, production approval, operating responsibilities and price

For example, AMP's public product APIs expose product information without authentication. Up's developer API uses a personal access token and describes its current access model as access to your own data. A personal token is not permission to collect other customers' banking data or a substitute for a multi-bank service.

These are access categories, not a ranking of providers. For a broader provider comparison, use our Australian open banking API buyer's guide.

What Fiskil's free sandbox includes

The Testing guide documents unlimited sandbox end users and consents, with realistic sample data across Banking and Energy. Those allowances describe the test environment; they do not define a production plan.

The documented route is to create a Fiskil Console account, generate a key pair in API Keys and exchange it for an access token. Follow the authentication guide and keep credentials in your backend.

Create a test end user, then create an auth session from the Console. Select the relevant sandbox provider, complete the email OTP step using an address you can access, choose an available sample account and confirm sharing. Keep the Testing guide as the implementation reference for the current steps and sample-account pages.

A compact evaluation checklist

Use the following as a proposed evaluation method. Record each result as passed, failed or untested, and label its evidence as documentation, a sandbox test, a provider confirmation or an approved live test.

1. Define the required data. List the accounts, fields and history your first feature needs. Retrieve the relevant sample records and finish pagination. A successful response containing one page does not establish complete history.
2. Follow the journey beyond account linking. Record consent completion, dataset availability and your backend's retrieval result separately. Fiskil's Banking guide describes webhook notifications as each dataset becomes available; a browser redirect alone does not prove every dataset is ready.
3. Exercise your application's recovery paths. Check cancellation, delayed data and repeated notifications. Use supported sandbox scenarios or clearly labelled application fixtures where a case cannot be produced in the sandbox. Do not report a simulated failure as an observed bank incident.
4. Keep a separate coverage list. Record the intended institutions, account products, personal or business customers and required permissions. Ask what is supported in the proposed production service, then validate the critical journeys after live access is approved.
5. Make the production decision explicit. Identify the access arrangement, consent purposes, data-handling responsibilities, support needs and current commercial offer. Leave unresolved requirements visible.

For a test charter and evidence log, follow our banking API proof-of-concept guide. It expands the evaluation process; the Testing documentation supplies the current sandbox instructions.

Sandbox success and production readiness are different milestones

A sandbox can show that your application handles the supplied data and journeys. It cannot establish real-bank availability, customer eligibility, production data freshness or a service commitment.

For CDR data sharing, the OAIC explains the roles of data holders and accredited data recipients and the consumer's consent to data transfer. Confirm the arrangement that applies to your business and proposed service before handling live customer data.

Fiskil's Go Live Checklist describes requesting live access through the Console onboarding questionnaire, completing application, company and security information, and reviewing the compliance and developer checklists. Once approved, configure production and run a final end-to-end test. Completing a sandbox journey does not replace that review.

Ask pricing questions against your intended usage

Before paying for production, request a quote with clear definitions:

• Which institutions, datasets and services are included?
• What is the billed unit, and when does it start or stop counting?
• How are inactive users, multiple connections and reconnections treated?
• Do minimum commitments, setup charges or optional services apply?
• What support, service commitments and offboarding terms are included?

These are buying questions, not statements about Fiskil's tariff. Use the current written offer for your expected usage.

Start with the sandbox Testing guide, use the proof-of-concept guide to record what you learn, and review live requirements before promising production functionality to customers.