Your own API
Custom API development
Sooner or later a trade customer asks to place orders straight from their own system, a reseller wants a live stock feed, or a client wants their data in their reporting tool. A custom API lets partners and customers connect to your business directly instead of emailing spreadsheets or retyping. Offering one is a commitment, though: once others build on it, changes must be managed, questions answered and access controlled. Deciding what the API is for, who uses it and how they are supported matters as much as the code.
This page covers the business decisions. The REST API development pages cover design, security and versioning in technical detail.
Illustrative diagram
Partner API
- Use cases
- Orders
- Stock and prices
- Developer experience
- Documentation
- Sandbox
- Agreement
- Terms of use
- Change notice
- Support
- Questions
- Incidents
Why businesses offer an API
| Request | What the API provides |
|---|---|
| Trade customers want to order from their own systems | Order placement and order status |
| Resellers need current stock and prices | Product, price and availability feed |
| Clients want their data in their own tools | Read access to their records and reports |
| Partners need to be told when something changes | Webhooks for events such as despatch |
| Your own apps and portal need a back end | One API serving internal and external use |
Is an API the right answer?
A scheduled file feed or export
Suits you when
- Partners only need data daily
- They lack developers
- Volumes are small
Watch out for
- Not suitable for placing orders
- Files still need validating on both sides
A customer portal
Suits you when
- People, not systems, do the work
- Partners want self-service without integration
Watch out for
- Still manual for high-volume partners
An API
Suits you when
- Partners have systems and developers
- Actions as well as data are needed
- Several partners want similar access
Watch out for
- Ongoing support and change management
- Security and access control are your responsibility
Start from one partner's real need
Design the first version around one or two partners who have asked for it, with their actual use cases: which records they need, which actions they want to perform and how often. A general-purpose API designed for imagined users tends to expose too much and still miss what real partners need. Involve the first partners in reviewing the design and testing it in a sandbox before anyone relies on it.
Keep the first version small; adding endpoints later is easier than removing ones partners already use.
What partners will expect
Getting started
- Clear documentation with examples
- A sandbox with test data
- A simple way to request keys
Running
- Stated rate limits
- Notice before breaking changes
- A status or incident contact
Agreement
- Terms of use
- What support is offered
- How access can be withdrawn
Terms and responsibilities
Before partners connect, agree in writing what they may do with the data, how keys must be protected, what notice you give before changes, what support and availability you offer and how access ends. Where personal data is shared, the data protection position of each party needs to be clear. Take legal advice on the wording; the technical design should follow what the terms allow.
The support you are committing to
Partners will ask questions, report problems and need help when their code misbehaves. Decide who answers, how quickly, and how much help you give with their side of the integration. Good documentation and clear error messages reduce the load considerably.
Example: trade orders by API
Illustrative example — not a client case study
Situation: A wholesaler's largest customers email purchase orders that staff retype, and two of them have asked to send orders directly from their purchasing systems.
- The first version offers product and price lookup for that customer, order placement and order status, nothing more.
- Both customers test against a sandbox with sample products before going live.
- Despatch notifications by webhook are added later, after the customers ask for them.
What this shows: Orders from those customers stopped being retyped, and the API grew only as real requests arrived. This example is illustrative.
Internal and external use
The same API can serve your own portal or app and external partners, which avoids building two back ends. Partner access should still be limited to what each partner needs: their own customers, orders or products, not everyone's. Design permissions so a partner's key can only reach that partner's records, and test it deliberately.
If internal use needs far more than partners do, a separate internal API may be simpler to secure.
Knowing whether it is working
Track how many partners are connected, what share of orders or requests now arrive by API, error rates per partner and the support questions received. These show whether the API is saving the time it was built to save, and which documentation or errors need improving.
Questions about custom API development
When should we offer an API?
When partners have systems and developers and need actions or live data, not just occasional files.
Is a file feed ever enough?
Yes, for daily data to partners without developers.
How should the first version be designed?
Around one or two real partners' use cases, kept small.
What will partners expect?
Documentation, a sandbox, keys, stated limits, change notice and support.
Do we need terms of use?
Yes, covering data use, key protection, changes, support and ending access.
Where is the technical design covered?
On the REST API development pages, including security and versioning.
Request a Custom Quote
Ask about Custom API development
Thank you — your enquiry has been sent.
We have received your message and will reply by email. If you need to add anything, email info@letgetgrow.com.