GBCORP BLOG · IT SERVICES
API Development: The Interface Your Apps and Partners Call
An API is the part of a system other software talks to. Get it right and every app, partner and integration is a release away. Get it wrong and every one is a rebuild.

API development produces the documented interface through which apps, websites, partners and integrations read and write a business’s data and trigger its processes. GBCORP builds every backend with an API from the first release, because its own apps, web and consoles call the same one; a partner integration later is a key and a permission, not a project. This article describes what a good business API contains and how GBCORP designs, secures, versions and prices it.
What a business API contains
| Part | What it does | How |
|---|---|---|
| Endpoints | Read and write for each record type: customers, orders, requests, products, payments | Designed from the questions the business asks |
| Authentication | Keys per app or partner; user tokens for customer actions | Issued and revoked in the console |
| Permissions | What each key may read or write, per record type | Enforced at the backend, logged |
| Limits | Requests per minute per key; quotas per partner | Configured; alerts on abuse |
| Webhooks | Notifications to other systems when something happens | Signed, retried, logged |
| Documentation | Every endpoint with parameters, examples and errors | Generated from the code, always current |
Designed from the questions, not the tables
An API that mirrors the database forces every caller to understand the database. GBCORP designs endpoints from what callers need to ask: the orders for this customer this month, the requests awaiting this partner, the products in stock in this market. The data model stays private; the questions are the interface, and they change less often than the tables do.
Keys, permissions and limits per partner
Each partner or integration gets its own key, with permissions for exactly the record types and actions it needs, a rate limit, and a log of every call. A key is revoked in the console in one click. A logistics partner sees shipments and nothing else; an accounting integration reads invoices and writes nothing. This is what makes an API safe to hand to a third party.
Versioning and documentation
A change that would break a caller ships as a new version beside the old, with a retirement date. Documentation is generated from the code, so it cannot drift. A partner integrates from the documentation without a call, which is the test of whether it is complete.
Checklist before commissioning an API
- Who will call it: your apps, partners, integrations, or all three.
- The questions each caller needs to ask, in plain words.
- What each caller may write, and what it may only read.
- Events other systems need to hear about.
- Expected volume per caller.
- Who administers keys on your side.
The numbers to expect
An API exists from the first release of any GBCORP backend at no extra charge. A partner-facing API with keys, permissions, limits, webhooks and documentation is a release of two to four weeks at a fixed price. Integrations are quoted per system. Customised or more complex functionality is quoted separately before any work starts.
A worked example
A wholesaler wanted its three largest customers to order from their own purchasing systems. GBCORP’s backend already exposed the ordering endpoints its app used; a partner release added keys per customer, permissions limited to that customer’s catalogue and orders, rate limits, order-status webhooks and generated documentation. Each customer’s IT team integrated from the documentation without a call. Orders from the three now arrive without re-keying, and the console shows calls per key and any failures with the payload.
Webhooks, retries and the audit trail
When an order ships, a payment settles or a request changes status, the backend notifies subscribed systems with a signed message. A failed delivery is retried on a schedule and shown in the console with the payload, so an integration engineer fixes it from evidence. Every call in and every notification out is logged with key, time and outcome. An audit question is answered from the log.
APIs for AI steps and automation
A model-driven step is a service behind the same API: the app calls an endpoint, the service calls the model, the result returns with a confidence and a source. Automation tools and partner systems call the same endpoints. Because the interface is stable, the model behind it can be swapped without any caller changing, which is the design principle GBCORP applies to every integration.
Documentation a partner can use alone
Every endpoint with its parameters, an example request and response, the errors it can return and what each means. Generated from the code on every release so it cannot drift. A sandbox key against test data so a partner integrates before touching production. The test of documentation is that no call is needed.
Performance and limits
Endpoints answer in under half a second at the 95th percentile under load, verified by a load test before a partner release. Rate limits protect every caller from every other. Heavy reports run in the background and return a link. Costs scale with calls and are reported monthly per key.
Ownership of the API
The code, the documentation, the keys and the logs live in the business’s own cloud project and are the business’s. Keys are issued and revoked by the business’s administrator. No credentials are retained by GBCORP after a hand-over unless a support contract requires them.
Questions we hear first
Can you build an API for a system you did not build?
Yes. The scoping week maps the system’s data and access paths; the API is delivered as a service beside it.
Is it REST?
Yes, with JSON, standard status codes and generated documentation; that is what partners expect and can integrate without a call.
How is it secured?
Keys and tokens over TLS, permissions per key at the backend, rate limits, logging, and revocation in the console.
Who owns it?
The business: code, documentation and keys, in its own cloud project.
Where to start
The GBCORP software development hub sets out the method; the GBCORP Custom App Development product is the priced starting point. For the rest of the backend, read backend development explained.
GBCORP operates across 17 countries on 4 continents through six pillars: AI & IT, Innovation, Sustainability, Infrastructure, Premium Business, and EV's & Solutions.