API Gateway Development & Management

API gateway development puts routing, authentication, rate limits and request logs in one layer, so each service stops inventing its own front door. Mobile apps, a public partner API and your own admin tools call one hostname. Behind it, orders, catalogue and billing stay separate processes with separate deploys.

At CodeWiz we design and run that layer for Laravel and Node.js systems, for a monolith that is about to be split, and for a set of services that already exist and are reached through a tangle of Nginx locations. The gateway is configuration and a small amount of policy. Business rules stay in the services, where they can be tested without a network hop.

The work is for teams exposing an API to more than one client, for companies adding partners who need keys and quotas, and for anyone who wants a single place to see latency, errors and abuse. A single application on a single domain often needs only the reverse proxy it already has. When the second and third service appear, a gateway earns its place.

For services, open-source tools are the default when they fit the job.

API Gateway Development Starts With Request Routing

Routing is the map from an incoming request to the process that should answer it. A clear map is a product decision as much as a network one: which URL is public, which header selects a tenant, which share of traffic may see a new version.

A services engagement starts from the system you already run.

What a route is allowed to decide

• Match on host, path, method and, when it truly matters, a header. A route that depends on a vague regular expression becomes unreadable the moment a second person edits it.
• Send the request to a named upstream, with a connect timeout, a response timeout and a health check. A dead upstream is removed from rotation instead of hanging callers.
• Strip the external prefix, set X-Request-Id if the caller did not, and pass only the headers the service is supposed to trust.
• Shift a slice of traffic to a new version for a canary. The slice is a number you can change without a service deploy.

Retries and timeouts

A retry is safe for a GET that did not reach the service. It is dangerous for a POST that creates an order: the first attempt may have succeeded and the response was the part that failed. We retry only idempotent calls, and we keep the timeout shorter than the caller’s own timeout so a slow upstream fails visibly instead of stacking up. A short route definition looks like this:

The concrete file is Traefik, Kong, APISIX or Nginx, depending on the hosting. The shape stays the same: match, upstream, auth, limit. Traefik’s routing model is documented in the Traefik routers reference, which is a good picture of declarative routes even when the engine is different.

Rate Limiting and Quotas in Front of Every Service

Rate limiting at the gateway protects capacity before a request spends a database connection. It is the coarse gate: so many requests per key, per token or per IP, in a window. The service behind it can still enforce a business rule, such as “five searches a minute on the free plan”, because that rule needs data the gateway does not have.

• Identity of the caller is the key whenever you have one. An IP limit is a backstop for anonymous traffic and a poor primary limit for customers who share an office NAT.
• Plans become numbers: a free key, a partner key and an internal key carry different budgets. The gateway reads the tier from the credential and applies the matching policy.
• A 429 is a contract. The response includes Retry-After and a stable error body, so client libraries can back off instead of looping.
• Bursts are explicit. A checkout may legitimately send a handful of calls at once. The limit allows a short burst and still caps the sustained rate.

The patterns, including where a limit should live, are in our guide to API rate limiting. On the gateway we implement the edge half of that design and leave domain quotas in the application.

Authentication Before a Request Reaches a Service

The gateway is the place that proves who is calling, so twenty services do not each implement JWT validation slightly differently. Authorization that depends on an order, a role inside a tenant or the contents of a row still belongs to the service that owns the data. Splitting those two jobs is the whole point.

• API keys for server-to-server partners, stored hashed, scoped to a set of routes, and revocable without a deploy.
• JWT validation for first-party web and mobile apps: signature, expiry, issuer and audience checked at the edge. The service receives the verified claims, not the raw token to parse again.
• OAuth2 when a third party acts on behalf of a user. The gateway introspects or validates the access token and forwards the subject.
• mTLS between the gateway and internal services, or between two of your own networks, so a stolen bearer token is not enough to call a service that was never meant to be public.

Services accept identity headers only from the gateway’s network. Direct access to upstream ports is closed. A client that can bypass the gateway can bypass the limits and the audit log, which makes the rest of the design decorative.

Monitoring, Logs and Traces for Every Hop

A gateway that routes and forgets becomes a place where incidents go to hide. Every request that crosses it should be attributable: who called, which route matched, which upstream answered, how long it took, and which status came back.

• Access logs with a request id, route name, consumer, status, latency and upstream latency. The same id is logged inside the service, so one failed checkout can be followed from the edge to the query.
• Metrics per route: request rate, error rate, and latency percentiles. An alert watches the error rate and the saturation of a limit, not a single noisy 500.
• Traces via OpenTelemetry when more than one service handles the call. The gateway starts or continues the trace, and the services pick it up.
• A dashboard someone opens during an incident, with the top routes by latency and by 401, 403, 429 and 5xx. If the picture takes a day to assemble, it will not be assembled at the moment you need it.

Outside the gateway, a simple availability check still matters. A self-hosted uptime monitor tells you the hostname answers; the gateway metrics tell you which route is responsible when it is slow.

Kong, Traefik, NGINX, APISIX or Cloudflare

The engines differ in how you configure them and in which policies already exist as plugins. They do not differ in the job. We pick from the way you deploy and from who will edit a route six months later.

Kong’s plugin model is described in the Kong Gateway documentation. We use the open-source distribution when plugins are the reason to pick Kong. Where the site already sits behind Cloudflare, the edge configuration from our Cloudflare configuration notes and the origin gateway share the work: Cloudflare stops junk early, the origin gateway understands your routes and credentials.

An API Gateway, a Payment Gateway and a BFF

The names collide, and the systems should not. An API gateway fronts your own HTTP services. A payment gateway takes card details and talks to a processor. A backend-for-frontend is an application that shapes data for one client, and it may sit behind the API gateway rather than replace it.

Card payments are a separate build, covered in our article on payment gateway integration. The API gateway can route /v1/payments to that service. It should not collect card numbers itself.

Common API Gateway Mistakes We Fix

• Moving order logic, pricing or permissions-by-row into gateway plugins, until the gateway is a second monolith nobody can test locally.
• No upstream timeout, so a stuck service holds a worker in every layer and the outage spreads.
• Retrying POST requests and creating duplicate orders on a blip.
• Leaving upstream ports open on the public network, so clients skip the gateway whenever it is inconvenient.
• One shared API key for every partner, which means a leak cannot be revoked for a single caller.
• Logs without a request id, which turns “checkout failed at 14:02” into a guessing game.
• An IP rate limit as the only control, which locks out an entire office and still lets a stolen key run from many addresses.

What Drives the Cost of API Gateway Development

We estimate after listing the routes, the callers and the policies. A reverse proxy in front of one application is a small configuration job. A partner-facing gateway with keys, tiers and a migration off direct access is a larger one.

• How many routes and upstreams exist, and how stable their URLs already are.
• Which credentials you need: API keys, JWT, OAuth2, mTLS, or a combination.
• Whether quotas differ by plan, and whether those plans already exist in your database.
• The migration: today, which clients call services directly and must be moved without a break.
• Environments. A gateway that exists only in production will surprise you on the first staging test.
• Who operates it afterwards: a handover with dashboards, or ongoing changes as new services appear.

API gateway development is scoped from that list, and the estimate is agreed before the first route is cut over. If the current Nginx config is already the right size, we say that and stop there.

How We Work

1. Discovery: we inventory hosts, paths, callers, credentials and the timeouts each service can actually meet.
2. Plan: we choose the engine, draw the routes, and agree what is policy (the gateway) and what is domain logic (the service).
3. Build: we write the config, the auth, the limits and the dashboards, and we close direct access to upstreams in a staging environment first.
4. Test: we check each route, a revoked key, a burst over the limit, a dead upstream and a request id that shows up in both logs.
5. Launch: we move callers one group at a time, with the old path still available until that group’s traffic has been clean.
6. Support: we keep routes, plugins and certificates updated, and we adjust limits when a real launch changes the shape of traffic.

Why CodeWiz

• Full-stack: we build the Laravel, Node.js and WordPress services behind the gateway, so the routes match the way the code actually behaves.
• Open-source first: Traefik, Kong, APISIX, NGINX and OpenTelemetry, with Cloudflare where an edge you already pay for should do the first filtering.
• Right-sized: a clear Nginx config when you have one app; a gateway with consumers and quotas when partners show up.
• Fair pricing: premium development without premium prices, from Banja Luka, working remotely with clients locally and internationally since 2023.
• Performance and security together: timeouts, limits, TLS and logs are one delivery, not a follow-up project. More about the studio is on the about CodeWiz page.

Frequently Asked Questions

How much does API gateway development cost?

A single proxy in front of one or two services, with TLS, timeouts and basic logs, is a short engagement. Keys, per-plan quotas, several upstreams and a migration of existing clients cost more, mostly in the inventory and the cutover. You get a written estimate after that inventory, before we change production traffic.

Do we need an API gateway?

You need the behaviours: one public hostname, authentication, a limit, and a log. A single application can get those from Nginx or Caddy without a separate product. A gateway pays off when several services, or several external consumers, would otherwise each grow their own copy of that front door.

Should we choose Kong, NGINX or Cloudflare?

NGINX fits a server you already operate and a handful of routes. Kong or APISIX fit many API keys and plugins. Cloudflare fits a global edge and traffic you want scrubbed before it hits your origin, and it still leaves route-level auth to something that knows your consumers. We pick from the deploy model and the people who will edit routes later.

Is an API gateway the same as a payment gateway?

No. A payment gateway moves money and speaks to card processors. An API gateway routes and protects your own HTTP APIs. The same project often needs both: the API gateway sends /v1/payments to a service, and that service talks to Stripe, PayPal or a bank.

Will a gateway make the API slower?

A local gateway adds a small, stable amount of latency, typically well under the time a database query takes. The slowdown people notice comes from a timeout that is too long, a retry storm, or a plugin that calls another network service on every request. We keep the gateway’s own work to checks it can do from the request and from local config.

Can you put a gateway in front of an existing Laravel or Node.js API?

Yes. The application keeps its routes and its domain checks. The gateway terminates TLS, validates the credential, applies the limit and forwards the request. We migrate callers onto the gateway hostname and then close the old public port.

Ready to Put One Front Door on Your APIs?

Tell us which services are public today and which callers should have keys, quotas or a private network path. We will propose an engine, a route map and a cutover that does not interrupt the clients you already have. Contact us to go through it, or see our API gateway services.