REST API development is how your software talks to everything else: your mobile app, your web shop, your partners, your accounting system and the dozens of SaaS tools your business already pays for. A well-designed API turns those systems into one workflow – orders flow into the ERP, payments update invoices, stock levels reach every sales channel – while a poorly designed one becomes the place where data silently goes missing and every new feature takes twice as long as it should.
Contents
At CodeWiz we design, build and document custom REST APIs, and we connect existing applications to third-party services such as payment providers, CRMs, shipping carriers, marketplaces and AI platforms. We care about the parts that decide whether an API survives real traffic: consistent resource design, clear error handling, idempotent writes, retries, versioning, documentation and sensible limits.
This service is for companies building a mobile or single-page app that needs a backend, businesses that want to stop copying data between tools by hand, SaaS products opening a public or partner API, and teams whose existing integrations break every time a vendor changes something. Whether you need one integration or a complete API platform, the goal is the same: reliable data exchange that your team can understand and extend.
Custom REST API Development Built Around Your Business
A custom API starts with your domain, not with a framework. Before writing code we map the resources (customers, orders, bookings, documents), who may read or change them, and which operations must be fast, atomic or asynchronous. That model becomes a contract that frontend, mobile and partner developers can rely on for years.
Design principles we apply to every API
- Predictable resources and verbs: plural nouns (
/orders,/orders/{id}/items), correct HTTP methods and status codes –201with aLocationheader on create,404versus403used deliberately,409for conflicts and422for validation errors. - One error format everywhere: we use the Problem Details standard (RFC 9457), so every client handles errors the same way instead of parsing ad-hoc messages.
- Cursor-based pagination for large or frequently changing collections, plus filtering, sorting and sparse fieldsets so mobile clients do not download what they never show.
- Idempotency keys on writes: a client that retries
POST /paymentsafter a timeout must not charge the customer twice. - Versioning from day one: a
/v1prefix or a version header, additive changes by default and a published deprecation policy for breaking ones. - Caching and concurrency control:
ETagandIf-None-Matchfor cheap re-reads,If-Matchto prevent two users from overwriting each other’s changes.
Here is what a consistent validation error looks like to the client:
HTTP/1.1 422 Unprocessable Content
Content-Type: application/problem+json
{
"type": "https://api.example.com/problems/validation",
"title": "Validation failed",
"status": 422,
"errors": [
{ "field": "email", "message": "Must be a valid email address" },
{ "field": "quantity", "message": "Must be at least 1" }
]
}Choosing the stack
We build APIs in the language that fits your team and existing systems rather than forcing one stack onto every project:
| Stack | Strengths | Typical use | Trade-offs |
|---|---|---|---|
| Laravel (PHP) | Fast delivery, Eloquent ORM, queues, Sanctum and Passport built in | Business backends, e-commerce, admin-heavy products | Needs Octane or careful tuning for very high request rates |
| Node.js (Fastify, NestJS, Express) | Non-blocking I/O, shared TypeScript types with the frontend | Integration hubs, real-time features, BFF layers | CPU-heavy work must move to workers |
| Python (FastAPI) | Automatic OpenAPI docs, Pydantic validation, AI and data libraries | AI/ML services, data pipelines, scraping backends | Async ecosystem is less uniform than Node.js |
| Go | Very low latency and memory use, single static binary | High-throughput services, proxies, internal tooling | More code for things frameworks give you for free |
Typical deliverables are the API itself with automated tests, an OpenAPI specification, database migrations, a Docker setup, a CI pipeline and a short operations guide.
Third-Party API Integrations That Keep Working
Most businesses do not need more software; they need the software they already have to share data. We integrate payment providers (Stripe, PayPal, regional card processors), CRMs (HubSpot, Pipedrive, Salesforce), accounting and ERP systems, shipping carriers, marketplaces, email and SMS services, Google and Meta APIs, and AI providers such as OpenAI or self-hosted models. Payments in particular deserve care, which we cover in our article on secure payment gateway integration.
What makes an integration reliable
- Queues instead of inline calls: a slow CRM should never slow down your checkout. We push outbound calls to Laravel queues, BullMQ or a message broker and process them in workers.
- Retries with exponential backoff and jitter for timeouts and
5xxresponses, and no retries for permanent4xxerrors. - Circuit breakers and timeouts on every outbound request, so one failing vendor cannot exhaust your connection pool.
- Webhooks verified and deduplicated: we check signatures, store event IDs and process each event exactly once, even when the vendor sends it three times.
- Reconciliation jobs that periodically compare both systems and fix drift caused by missed webhooks.
- Credential hygiene: API keys in a secrets store, scoped to the minimum permissions, and rotated without code changes.
Webhook verification is short but frequently skipped. A minimal HMAC check in Node.js looks like this:
import crypto from "node:crypto";
function verifyWebhook(rawBody, signatureHeader, secret) {
const expected = crypto
.createHmac("sha256", secret)
.update(rawBody)
.digest("hex");
const a = Buffer.from(expected);
const b = Buffer.from(signatureHeader || "");
return a.length === b.length && crypto.timingSafeEqual(a, b);
}The comparison is constant-time, and the signature is computed over the raw request body, not the parsed JSON – a detail that breaks many integrations after a framework upgrade.
API Documentation Developers Actually Use
API documentation is part of the product. Without it, every integration starts with a call to your developers; with it, partners and your own frontend team can work independently. We document every API we build with an OpenAPI 3.1 specification and turn it into readable reference pages.
Design-first or code-first
For public and partner APIs we prefer design-first: the OpenAPI contract is written and reviewed before implementation, so frontend developers can build against a mock server (Prism) while the backend is still in progress. For internal APIs, code-first generation from annotations or types (FastAPI, NestJS Swagger, Scramble for Laravel) keeps documentation in sync with minimal effort. Either way, the specification lives in Git and changes go through code review.
paths:
/v1/orders/{id}:
get:
summary: Get a single order
parameters:
- name: id
in: path
required: true
schema: { type: string, format: uuid }
responses:
"200":
description: The order
content:
application/json:
schema: { $ref: "#/components/schemas/Order" }
"404":
$ref: "#/components/responses/NotFound"What good documentation includes
- Interactive reference pages generated with Redoc, Scalar or Swagger UI.
- A getting-started guide: authentication, the first request and common workflows end to end.
- Real request and response examples for every endpoint, including error cases.
- Postman or Bruno collections and, where useful, generated client SDKs.
- A changelog and deprecation schedule, so consumers know what changes and when.
- Contract tests (Schemathesis or Dredd) in CI that fail when the implementation drifts from the specification.
Rate Limiting and Usage Quotas for Your API
Every API needs limits. Rate limiting protects your servers from traffic spikes, buggy clients stuck in loops, credential stuffing and scrapers, and it keeps one heavy customer from degrading the service for everyone else. For SaaS products, quotas are also part of the pricing model.
| Algorithm | How it works | Good for | Weakness |
|---|---|---|---|
| Fixed window | Counts requests per minute or hour | Simple quotas, daily limits | Bursts at window edges can double the allowed rate |
| Sliding window | Weighted count over a rolling period | Fair per-user limits on public APIs | Slightly more storage and computation |
| Token bucket | Tokens refill at a steady rate; each request spends one | Allowing short bursts with a steady average | Harder for clients to reason about |
How we implement it
- Limits per API key or user, not only per IP address, with separate tiers for anonymous, authenticated and premium clients.
- Stricter limits on expensive or sensitive endpoints: login, search, exports, AI calls.
- Shared counters in Redis, so limits hold across multiple application servers.
- Clear responses:
429 Too Many RequestswithRetry-Afterand rate limit headers, so well-behaved clients slow down instead of hammering the API. - Edge protection with Cloudflare or the gateway for volumetric abuse, application limits for business rules.
We have published two in-depth guides on the topic: a complete guide to API rate limiting and a practical walkthrough of rate limiting in Node.js and Express.
REST, GraphQL, gRPC or Webhooks: Choosing the Right API Style
REST is the right default for most business APIs, but not the only option. We recommend a style based on who consumes the API and how:
| Style | Best when | Avoid when |
|---|---|---|
| REST | Public or partner APIs, CRUD-heavy domains, HTTP caching matters | Clients need very different shapes of the same data |
| GraphQL | Several frontends with different data needs, deeply related data | Simple CRUD, heavy reliance on CDN caching |
| gRPC | Internal service-to-service calls, low latency, streaming | Browser clients without a proxy, third-party consumers |
| Webhooks | Notifying other systems when something happens | The receiver cannot expose a public endpoint |
Many systems combine them: a REST API for partners, webhooks for events and gRPC between internal services.
API Security Essentials
APIs expose your data directly, so security is designed in, not bolted on. The OWASP API Security Top 10 is our checklist, and the most common real-world issue is still broken object-level authorization: an endpoint that returns /orders/1043 to any logged-in user, not just its owner.
- Authorization checks on every object, enforced in policies rather than scattered through controllers.
- Strict input validation and explicit output serialization, so internal fields never leak.
- Token-based authentication (OAuth 2.0, JWT or Laravel Sanctum) with short-lived tokens and scoped API keys.
- TLS everywhere, CORS restricted to known origins and security headers on every response.
- Audit logs for sensitive operations and alerts on unusual access patterns.
Testing, Versioning and Monitoring APIs in Production
An API is only as good as its behaviour on a bad day. We write feature tests for every endpoint (Pest or PHPUnit, Jest or Vitest, pytest), contract tests against the OpenAPI specification and load tests with k6 for critical paths. In production we track latency percentiles, error rates per endpoint and per client, and slow database queries, with structured logs and request IDs that follow a call across services. Uptime checks catch outages before customers do – even a self-hosted uptime monitor covers the basics.
Common REST API Mistakes We Fix
- Returning
200 OKwith an error message in the body, so clients cannot detect failures reliably. - Exposing database tables one-to-one as endpoints, coupling every client to your schema.
- N+1 queries hidden behind list endpoints that get slower as data grows.
- No pagination, so one request for “all orders” eventually times out or exhausts memory.
- Breaking changes deployed without a new version, discovered by partners in production.
- Synchronous calls to third-party services inside user requests, with no timeout.
How We Work
- Discovery: we map the systems involved, the data that must flow between them, the consumers of the API and the non-functional requirements such as volume, latency and compliance.
- Contract: we design resources, endpoints, errors and authentication in an OpenAPI specification and review it with you and your frontend or partner teams.
- Build: we implement the API and integrations with queues, retries, logging and automated tests, delivering in small increments you can try on staging.
- Test: we run contract, integration and load tests, test failure scenarios such as vendor outages, and review security against the OWASP API Top 10.
- Launch: we deploy with monitoring and alerting in place and publish the documentation for consumers.
- Support: we maintain integrations when vendors change their APIs, add endpoints and handle version upgrades.
Why CodeWiz
- Full-stack perspective: we build the frontends, mobile backends and infrastructure that consume APIs, so we design APIs that are pleasant to use, not just correct.
- Broad integration experience: payments, e-commerce platforms, search, scraping, AI and automation are all part of our everyday work.
- Open standards, no lock-in: OpenAPI, open-source frameworks and documentation that lets any competent team take over.
- Tailored solutions: a single integration or a full API platform – we scope to what your business actually needs.
- Fair pricing: premium development without premium prices, from Banja Luka, working remotely with clients locally and internationally. Read more about CodeWiz.
Frequently Asked Questions
How much does custom REST API development cost?
Cost depends on the number of resources and endpoints, the complexity of business rules, how many third-party systems are involved and the documentation and security requirements. A single integration between two systems is a small project; a public API platform with SDKs and usage tiers is a large one. We provide a fixed scope and estimate after discovery.
How long does it take to build an API or integration?
A focused integration, such as syncing orders from a web shop to an accounting system, typically takes days to a couple of weeks including testing. A complete backend API for a new product usually takes several weeks and is delivered in increments, so your frontend team can start early.
Can you integrate a system that has poor or no documentation?
Often, yes. We analyse existing traffic, vendor SDKs and sandbox behaviour, and wrap fragile systems behind a clean internal API so the rest of your stack is shielded from their quirks. Where no API exists at all, careful data extraction may be an option.
Should my API be REST or GraphQL?
For most business and partner APIs, REST is simpler to cache, secure and document. GraphQL pays off when several frontends need very different views of richly connected data. We will recommend the option that fits your consumers, and both can coexist.
Will you maintain the integrations after launch?
Yes. Vendors deprecate endpoints and change payloads regularly. We can monitor integrations, update them when providers change and extend the API as your business grows.
Need a Reliable API or Integration?
Tell us which systems need to talk to each other and where data gets stuck today, and we will propose an API design and integration plan that fits your budget. Contact us to discuss your project, or explore our REST API and integration services.