Custom API Development
An API is a promise, and promises are harder to change than code.
What is custom APIs?
Custom API development means building an interface other systems call, which carries an obligation that ordinary code does not: once something depends on it, changing it affects whoever built against it.
Building an API is not the same as building software. Internal code can be changed whenever you like. An API that another system calls cannot, because changing it breaks something you may not control and may not be able to contact.
That obligation should shape the design. Fewer endpoints that do their job well are easier to keep promises about than many that expose everything, and every field you publish is a field somebody may come to depend on.
The other half is versioning. Anything published needs a way to change without breaking existing callers, and retrofitting that after a partner has integrated is considerably harder than deciding it upfront.
Why we design for the promise
Duara builds custom APIs from Nairobi for businesses whose systems need to be reachable by their own applications, their partners or their customers.
We design for the promise rather than for the immediate requirement. It is tempting to expose whatever is convenient now, and every field published becomes something a caller may depend on, which is a decision that outlives the person who made it.
Who this is for
- Partners need programmatic access to your systems
- Your own applications need a shared interface
- Customers are asking for integration
- An existing API has become difficult to change
Industries we serve
- Technology companies
- Financial services
- Logistics
- Telecommunications
- Distribution
- Any business other systems need to reach
Problems this solves
These are the situations where publishing an interface is justified, and where getting it wrong is expensive.
- Exposing more than necessary. Every published field becomes something a caller may depend on, and removing one later breaks somebody you may not be able to contact.
- No versioning strategy. The interface cannot change without breaking existing callers, and retrofitting versioning after integration is far harder than planning it.
- Partners integrating differently. Without documentation and consistency, each caller integrates in their own way and support becomes unmanageable.
- No view of who is calling. Nobody knows which callers depend on what, which makes any change a guess about who it will affect.
What we deliver
A deliberately small interface, versioning designed from the start, documentation good enough that callers do not need support, and visibility of who depends on what.
A deliberately small and stable interface
Versioning designed before publication
Documentation callers can integrate from unaided
Authentication and rate limiting
Visibility of who is calling what
A deprecation process for retiring anything
Features
- Smaller than requested. Every field published is something somebody may depend on, and fewer promises are easier to keep than many.
- Versioning from the start. Retrofitting a way to change after a partner has integrated is considerably harder than deciding it before publication.
- Documentation that removes support. A caller who can integrate unaided costs you nothing, and one who cannot costs you every time.
- Usage visible per caller. Knowing who depends on what turns a change from a guess into a decision.
- Deprecation planned. How something gets retired is agreed before it is published, since retiring without a process is how you break a partner.
Benefits
- Changes stay possible. Versioning and a small surface mean the interface can evolve rather than being frozen by its own callers.
- Support load stays low. Good documentation means partners integrate without consuming your developers time.
- Partners integrate faster. A clear consistent interface shortens the time between a partner deciding and a partner working.
- Changes affect known people. Usage visibility means you know who a change touches rather than discovering it through a complaint.
Technologies we use
- Interface design. Choosing the smallest surface that meets the need rather than exposing what is convenient.
- Versioning. A defined way to change without breaking existing callers.
- Authentication and rate limiting. Controlling who can call and how much, before anything faces outward.
- Documentation. Written so a caller integrates without contacting anybody.
- Usage analytics. Recording which callers use which endpoints, so change decisions are informed.
The discipline here is restraint. Every endpoint and field published is a commitment, and the cost of that commitment is paid later by whoever needs to change it, which is usually not the person who published it.
How the process works, step by step
A custom API usually takes three to eight weeks, and the design conversation matters more than the build.
-
Step 1
Free requirements review
We establish who will call it and what they actually need rather than what could be exposed.
-
Step 2
Surface kept small
The interface is cut back deliberately, since every field published becomes a commitment.
-
Step 3
Versioning decided
How the interface will change is agreed before publication rather than after a partner has integrated.
-
Step 4
Documented for strangers
Written so somebody who has never spoken to you can integrate, which is the only useful test.
-
Step 5
Usage visible from launch
Who calls what is recorded from the start, since retrospective visibility is not possible.
Quality assurance and how we work
The commitments attached to publishing something other people build against.
- We publish less than you ask for. Every field exposed is something a caller may depend on, and removing one later breaks somebody you may not be able to contact.
- Versioning is designed before publication. Retrofitting it after a partner has integrated is far harder than deciding it upfront, and by then you have lost the option.
- Documentation is tested on somebody who has not seen it. A caller who needs support to integrate means the documentation failed, whatever it looks like to us.
- Nothing faces outward without authentication and limits. A public interface without them is somebody else capacity and somebody else bill.
- We agree a deprecation process upfront. Retiring something without one is how you break a partner who trusted the interface.
Frequently asked questions about custom APIs
How is an API different from ordinary software?
It is a promise. Internal code can change whenever you like, while an interface others call cannot without breaking something you do not control.
Why publish less than we want to?
Because every field exposed is something a caller may depend on, and removing one later breaks somebody you may not be able to contact.
Do we need versioning from the start?
Yes. Retrofitting a way to change after a partner has integrated is far harder, and by then you have already lost the option.
How good does documentation need to be?
Good enough that a stranger integrates without contacting you. If they need support, the documentation failed whatever it looks like to us.
Should it be public?
Only with authentication and rate limiting. A public interface without them is somebody else capacity and somebody else bill.
How do we know who depends on what?
Usage recorded per caller from launch, since retrospective visibility is not possible and change decisions need it.
Can we retire an endpoint later?
With a deprecation process agreed upfront. Retiring something without one is how you break a partner who trusted you.
When could a partner start calling it?
Three to eight weeks, and the design conversation matters considerably more than the build does.
Can partners integrate without our help?
That is the goal and the test of whether it was built properly. Support load is the measure of documentation quality.
What about rate limits for partners?
Per caller, so one partner cannot consume the capacity the others depend on.
Does it need to be REST?
Usually, since it is what most callers expect. Where a different approach genuinely suits, we would explain the trade rather than defaulting.
Can it expose data from several systems?
Yes, and presenting one interface over several internal systems is frequently the actual value.
What if our internal systems change?
That is one reason to have an API. Callers depend on the interface rather than on what sits behind it, which you can then change.
How do we handle authentication for customers?
Keys or tokens per caller, scoped to what each may reach, which also makes usage visibility possible.
Can it charge for usage?
Metering is straightforward once usage is recorded per caller. Billing itself is a commercial decision we would build to rather than design.
What happens when we need a breaking change?
Versioning lets old and new run together while callers migrate, which is why it is decided before publication.
Could our developers take it over?
Yes. It is built as ordinary software and documented for somebody who did not write it, rather than as something only we understand.
Can it sit in front of an old system?
Yes, and putting a clean interface in front of a legacy system is one of the more valuable things this does.
Who can call our API?
Only callers you issue credentials to, with permissions per caller and revocation available at any time.
What does a custom API cost?
Endpoint count and integration complexity determine it, quoted after the requirements review.
Glossary of terms
API terms in plain language.
- Endpoint
- A single callable operation, and a commitment once anybody depends on it.
- Versioning
- A defined way to change an interface without breaking existing callers.
- Breaking change
- An alteration that stops existing callers working, which versioning exists to avoid.
- Deprecation
- Retiring part of an interface, which needs a process and notice rather than a decision.
- Rate limiting
- Capping how much any caller can consume, protecting both cost and availability.
- Surface
- Everything an API exposes, where smaller is easier to keep promises about.
Related services in Integrations
Talk to us about custom APIs
Write down who will call your API and what they genuinely need. That list is usually shorter than the one you would have exposed.
Start your project