Sound familiar?
- Partners or resellers email you spreadsheets because there's no way to connect to your system
- Your mobile app needs a back end, and the current one was never designed for it
- A customer wants to integrate with you and asks for API documentation you don't have
- Your in-house database is the source of truth, but nothing else can talk to it
- An old API has no versioning, so every change risks breaking someone's integration
- You can't tell who is calling your API or how often
Key facts
- We build REST APIs with OpenAPI 3 specifications, and GraphQL where clients need flexible queries
- Authentication options include OAuth 2.0 client credentials, scoped API keys and signed webhooks
- Versioning is planned from day one so existing clients don't break when the API changes
- Rate limiting, request logging and audit trails are standard
- Typical stacks: Laravel (PHP 8), Node.js with TypeScript, Python with Django REST Framework or FastAPI
- We have built APIs and data feeds since the early OpenCart stock-feed days
- Fixed-price quote after a free chat; you own the code
When a business needs its own API
Most businesses consume other people's APIs. Building your own becomes worthwhile when data you hold needs to reach someone else reliably. Common triggers we see:
- Trade customers want live stock and pricing in their own systems instead of a weekly PDF.
- A mobile app or progressive web app needs a secure back end.
- Several internal systems need the same data, and point-to-point database connections have become fragile.
- A large customer's procurement team insists on a system-to-system connection before they'll buy.
- You're building a SaaS product, and an API is part of what customers are paying for.
An API turns your data into something other software can use, on terms you control: who can see what, how fast and with what record of who did it.
Design first, then code
The expensive mistakes in API work are design mistakes, because once outside developers have built against your API you can't change it freely. We write the contract before the code:
- Resources and naming. Consistent nouns (
/orders,/orders/{id}/lines), predictable filters and cursor-based pagination for large lists. - Error format. One structure for every error, with a machine-readable code and a human message. We follow RFC 9457 (Problem Details for HTTP APIs) unless there's a reason not to.
- Versioning. A version in the URL or a header from the first release, plus a written deprecation policy.
- REST or GraphQL. REST suits most business APIs: it caches well and every developer understands it. GraphQL earns its place when clients such as a mobile app need to fetch exactly the fields they want in one request.
The output is an OpenAPI 3 specification. From it we generate interactive documentation, and your partners can generate client libraries in their own language.
Security, rate limits and audit trails
An API is a door into your business data, so it gets the same care as a login screen. Our standard build includes:
- Authentication. OAuth 2.0 client credentials for system-to-system access, or hashed, revocable API keys for simpler cases. Tokens are scoped, so a partner who only needs stock levels cannot read customer records.
- Input validation on every field, with parameterised database queries throughout.
- Rate limiting per client, returning HTTP 429 with a
Retry-Afterheader so well-behaved clients back off. - Audit logging of who changed what and when, which also helps with GDPR subject access requests.
- HTTPS only, with secrets held in environment configuration, never in the code repository.
We test against the OWASP API Security Top 10 list of common weaknesses, such as broken object-level authorisation, where one customer can read another's records by changing an ID.
Webhooks: telling clients when things change
Polling an API every minute to ask "has anything changed?" wastes everyone's resources. A better pattern is to send a webhook: an HTTP POST to the client's URL when an order ships, a price changes or a stock level drops.
We sign each webhook with an HMAC signature and a timestamp so receivers can verify it came from you and reject replays. We retry failed deliveries with back-off and give clients a dashboard to see and resend events. It's the same model Stripe uses, and developers recognise it. More detail is on our webhook development page.
Testing, performance and keeping the API healthy
Every endpoint gets automated tests that run on each deployment: happy paths, validation errors, permission checks and pagination edges. We add contract tests against the OpenAPI specification so the documentation and the behaviour can't drift apart.
For performance, we index the database for the queries clients actually make, cache read-heavy responses with Redis, and send ETags so clients can skip unchanged data. Long-running work such as large exports goes onto a queue, and the API returns a job reference the client can check, rather than holding a request open for minutes.
Once live, request logs and error rates show how the API is used and which clients are struggling. That evidence guides the next version, and lets you warn a partner before a deprecated endpoint is switched off.
How we work and what you receive
After a free chat, a short scoping stage produces the API design and a list of the clients who'll use it. You then get a fixed-price quote for that scope. We build with automated tests for every endpoint, deploy to a staging environment your partners can use as a sandbox, and hand over the code, the OpenAPI specification and deployment notes. You own all of it.
If the API sits in front of an older system, it is often the first step in modernising legacy software: new applications talk to the API while the old system is replaced piece by piece. For the bigger picture of connecting your systems, start with our API integration page.
What we deliver
- API design: resources, endpoints, error format and pagination agreed in writing before coding
- An OpenAPI 3 specification and interactive reference documentation
- Authentication and per-client permissions (scopes)
- Rate limiting, request logs and an audit trail of data changes
- Outbound webhooks so clients hear about changes without polling
- Automated tests covering every endpoint, run on each deployment
- A sandbox environment for your partners to build against
How it works and what it costs
Every project gets a fixed-price quote after a free initial chat and a short scoping stage. You own the code and the data.
Free chat
Tell us the problem in plain English: what you do now, what goes wrong and what "better" looks like. No charge, no obligation.
Scoping
We map the processes, systems and data involved, agree what is in and out, and write it down so there are no surprises.
Fixed-price quote
You get a fixed price for the agreed scope, or a phased plan for bigger builds, so you can start small and prove it works.
Build and test
We build in short stages you can see and try, test against real data, then go live carefully with a rollback plan.
Hand over and look after
You own the code and the data. We can host it, support it and keep improving it, or hand it to your own team.
Frequently asked questions
Should our API be REST or GraphQL?
For most business APIs, REST. It is simpler to secure, caches well and every developer knows it. GraphQL suits cases where clients, often mobile apps, need to choose exactly which fields to fetch. dijitul developments will recommend one during scoping based on who will consume the API and how.
Will you document the API for our partners?
Yes. Every API dijitul builds comes with an OpenAPI 3 specification and interactive reference documentation, plus a short getting-started guide covering authentication, pagination, errors and webhooks. Partners can generate client libraries from the specification in their own language.
How do you stop one customer seeing another customer's data?
Every request is checked against the authenticated client's permissions, not just whether the record exists. We write automated tests for this specifically, because broken object-level authorisation is the top risk on the OWASP API Security Top 10. Access tokens are scoped so each client gets only what it needs.
Can you build an API on top of our existing database or old system?
Usually, yes. dijitul can build an API layer that reads from and writes to your existing database or legacy application, adding authentication, validation and logging the old system never had. It is a common first step in modernisation, because new software can use the API while the old system is retired gradually.
How much does custom API development cost?
It depends on the number of endpoints, the security model and what the API connects to behind the scenes. dijitul developments quotes every project at a fixed price after a free chat and a scoping stage, so you agree the cost for a defined scope before any development starts.
Who hosts the API?
You choose. We can deploy to your existing servers or cloud account, usually in Docker containers, or arrange UK hosting through our sister company dijitul DNS. Either way, you own the code and the deployment configuration, so you can move it later without asking us.
Related
Tell us what you need to build
Free chat, clear scope, fixed-price quote. You own everything we build.