An API is the part of your software that other software talks to: addresses where a customer's ordering system, a supplier, or your own website can read your records and write new ones without anyone logging in to re-key them. It is for businesses whose system holds data others need to reach. Ozwebnet writes APIs from scratch in Adelaide, South Australia, for businesses across Australia: one fixed quote staged against milestones, and the source code handed over with the IP assigned to you.
DETAIL OF SHEET 07 — SYSTEMS INTEGRATION →
An API (application programming interface) is a set of addresses your software answers on, so other software can ask it for records or send it new ones. Your website reads stock levels from your warehouse system. A customer's purchasing system sends orders straight into your job system. A supplier posts delivery updates that appear in your portal. None of it needs a person logging in. A business needs one when its own system holds data that others must reach, and the alternative is an emailed spreadsheet, a shared login or a nightly export.
Which records other software may read, which it may create or change, and the exact name and meaning of every field — agreed in writing before an endpoint is built, and kept as the reference the other side reads.
An address to list records with filters and paging, one to fetch a single record, and one each to create and update it — orders, customers, stock, jobs, whatever your system holds.
Your website, a customer's purchasing system and a supplier each get their own key, see only the records they are allowed to, and can be switched off on their own without touching the rest.
A request with a missing field or an unknown product is refused with a message naming the field and the reason, so the developer on the other side can fix it without ringing you.
When an order is dispatched or a price changes, the systems that asked to know are told straight away, instead of asking your API over and over to check.
A page for each endpoint with example requests and replies, and a test copy of the API loaded with sample data, so an outside developer can build and test without touching your live records.
Every call is written down with who made it and when; a limit stops one caller from slowing everyone else; and changes are released as a new version, so a system already connected keeps working.
TYPICAL SCOPE FOR THIS KIND OF SYSTEM — YOUR EXACT SCOPE IS FIXED IN WRITING AT THE SPECIFICATION STAGE.
Not sure which? Ten minutes on 1300 699 321 tells you — Mon–Fri 9–5 ACST.
One fixed quote, set in writing at the specification stage (02 Blueprint) and staged against the five milestones below. Each milestone ends with a working system; stop at any milestone and keep what has been built.
SEE THE FIVE STAGES ANIMATED →We list who needs to read or write your data — customers, suppliers, your own website or app — and which records and actions each of them needs.
Every endpoint, field, permission and error message is specified in writing; the fixed quote is set here, staged against milestones.
Built one group of endpoints at a time, reads before writes; each milestone ends with a working API the other side can call.
Every endpoint is tested against the written list with bad requests as well as good ones, before any outside system is given a key.
The API goes live with its documentation and sandbox, and you receive the source code with the IP assigned to you.
One fixed quote, set in writing before the build and staged against milestones. Reads are built before writes, and each milestone is an API the other side can already call, so you can stop at the endpoints you need.
You do — source code delivered, IP assigned to you. Your own developers, or any other, can add endpoints later.
An integration connects software you already run, using the APIs those products expose. API development gives your own system an API, so other software — a customer's, a supplier's, your website or app — can read and write your records. Many businesses need both: the API first, then the connections that use it.
Yes. Reference documentation and a sandbox loaded with sample data are part of the typical scope, and every refused request says which field was wrong and why, so an outside developer can build and test against it on their own.
Yes — Adelaide first, Australia-wide. The API is written in Adelaide and called from wherever the other software runs.
Call, or answer a few short questions — what you run, what breaks, when you need it working — and we reply within one business day. The quote is fixed in writing before any build starts.
