Custom API Development Services

Description

Service Custom API development: design, security, versioning and documentation

An API is the contract that lets your app, your partners or your other systems read and change your data without touching the database. WavX designs and builds REST and GraphQL APIs with authentication, versioning, rate limits and documentation agreed before code is written. If the systems you want to connect already have APIs, you need an integration, not a new API.

Tell us what you need built Last updated 2 October 2026

Three kinds of API project

"We need an API" usually means one of three things, and they are priced and built differently.

Kind

Who calls it

What matters most

Product API

Your own web and mobile apps

Speed of change; the API and the apps are released together

Partner or public API

Customers, resellers, other companies' systems

Stability, documentation, versioning, limits per caller

Integration layer

Your own systems talking to each other, or a modern API in front of an old system

Reliability, retries, and a clear record of what was sent

If you are new to the term, what is an API explains it in plain language.

When you do not need a custom API

The systems already have APIs. Connecting a store to an accounting package, or a CRM to WhatsApp, is integration work: using existing APIs, not building a new one.

A connector already exists. If a standard connector or an automation tool moves the data reliably at your volume, building an API to do the same thing is waste.

Only one internal screen needs the data. A report or an export may be all that is required.

REST or GraphQL

WavX builds both. The choice depends on who the callers are, not on which is newer.

REST

GraphQL

Model

Resources at many URLs, operated on with standard HTTP methods

One endpoint; the GraphQL documentation describes a server as operating on a single URL, usually /graphql

Response shape

Decided by the server for each endpoint

Decided by the caller, who lists the fields wanted

Versioning

Usually explicit: /v1/ , /v2/

The GraphQL documentation takes "a strong opinion on avoiding versioning" and evolving the schema by adding fields

Caching

Standard HTTP caching works on GET requests

Requests are normally sent by POST (GET is optional for queries), so HTTP caching needs extra design

Tooling for partners

Very wide; almost every language and tool speaks it

Good, but partners need to learn the schema and a client library

Usual fit

Partner and public APIs, integrations, simple product APIs

Product APIs serving several front ends with different data needs

The longer treatment, with examples, is in REST vs GraphQL: which API should you use .

What an API build includes

Part

What it is

What goes wrong without it

Contract

An OpenAPI description or a GraphQL schema, agreed before coding

Front-end and partner teams build against guesses

Authentication

Proof of who is calling

Anyone with the URL can call it

Authorisation

A check, on every request, that this caller may touch this record

One customer reads another customer's data

Validation and errors

Input checked against the contract; errors in one consistent format

Bad data in the database; callers cannot tell what failed

Versioning and deprecation

A rule for what counts as a breaking change, and how notice is given

An update on your side breaks a partner's system

Rate limiting

A ceiling on requests per caller

One faulty script slows the service for everyone

Idempotency

Repeating a request does not repeat its effect

A retry after a timeout creates a second order or payment

Pagination and filtering

Large lists returned in pages

One request tries to return the whole table

Webhooks

Your system tells callers when something happens

Callers poll every few seconds; see what is a webhook

Documentation and sandbox

Reference, examples, test credentials

Every integration needs your developer on a call

Logging and monitoring

Who called what, when, and how long it took

Problems are reported by partners, not noticed by you

Automated tests

Tests that call the API as a client would

Nobody knows whether a change broke the contract

Authentication and authorisation

Method

How it works

Use it for

API key

A secret string sent with each request, issued per caller

Server-to-server calls from partners; simple, and easy to revoke

OAuth 2.0

A framework, defined in RFC 6749, that lets an application obtain limited access to a service on a user's behalf

Third-party apps acting for your users; "connect your account" flows

Signed tokens

Short-lived tokens such as JSON Web Tokens (RFC 7519), which carry claims the server can verify

Your own mobile and web apps after login

Signed requests

The caller signs the request body with a shared secret

Webhooks and payment-style calls where tampering matters

Authentication answers who is calling. Authorisation answers whether they may see this particular order, invoice or customer, and it has to be checked on every request. The OWASP API Security Top 10 (2023) puts broken object-level authorisation first and broken authentication second. In practice the fault is an endpoint that confirms the caller is logged in, then returns whichever record ID was asked for. A WavX API build includes an automated test of this check for each endpoint that returns customer data.

Versioning, limits and errors

Versioning. Adding a field is safe. Removing one, renaming one, or changing its meaning is a breaking change. For a REST API the usual rule is a version in the path and a written promise about how long the old version stays up. Two published standards help callers find out in good time: the Deprecation response header (RFC 9745) signals that a resource is or will be deprecated, and the Sunset header (RFC 8594) gives the date it is likely to stop responding.

Rate limiting. HTTP defines status code 429, Too Many Requests, for this purpose, and the response may carry a Retry-After header telling the caller how long to wait (RFC 6585). Limits are set per caller, published in the documentation, and generous enough that honest use never meets them. OWASP lists unrestricted resource consumption among its API risks; a limit is also what protects your hosting bill.

Errors. RFC 9457 defines a standard "problem details" format for machine-readable errors, so an API does not need to invent its own. Whichever format is used, it should be the same on every endpoint.

Idempotency. For calls that create something or move money, the caller sends a unique key and the server treats a repeat of that key as the same request. The pattern is described in an IETF Internet-Draft, the Idempotency-Key header, which has not been published as an RFC, so it is a convention to state in your documentation, not a standard to assume.

Documentation a buyer should receive

The OpenAPI Specification describes itself as a standard, language-agnostic interface description for HTTP APIs that lets people and computers understand a service without reading its source code. As of October 2026 the current version is 3.2.1, published on 10 September 2026. For a REST API, ask for the description file itself, not only a PDF. From it you can generate reference pages, client libraries and test collections.

A complete hand-over includes:

The OpenAPI file or GraphQL schema, kept in the same repository as the code.

A getting-started page: how to get credentials and make a first call.

An example request and response for every operation, including the error cases.

The rate limits, the versioning rule and the deprecation notice period, in writing.

A sandbox or test mode with data that can be safely changed.

A changelog.

What to ask a developer or company for

Can we see the API contract before you start coding?

How do you test that one customer cannot read another's data?

What is your rule for breaking changes, and how will our partners be warned?

What happens when a caller exceeds the limit, and where is that documented?

What happens if the same create request arrives twice?

Who owns the code, the documentation and the API keys at the end?

How will we know the API is slow or failing before a partner tells us?

Plain answers to these are a good sign. On the sixth, WavX's position is that the client owns the source code and everything shipped with it.

Planning range

In the WavX cost model a public API is a line item of ₹70,000 added to the system it belongs to; it is not priced as a product on its own. The worked example below uses the same model as the software cost estimator . The range is the subtotal less 15% to the subtotal plus 25%. It is a planning range, not a quote.

Scenario

Cost model inputs

Subtotal

Timeline band

Web application with a documented partner API

Custom web application base ₹4,50,000; auth and roles ₹60,000; public API ₹70,000; third-party integrations ₹60,000

₹6,40,000

₹5,44,000 to ₹8,00,000

10–16 weeks

Assumptions: small scale (multiplier 1.0), standard interface design, REST with an OpenAPI description. Two cases fall outside the model and are quoted after scoping: adding an API to an existing system that WavX did not build, which starts with reading that code, and an API that has to meet a regulator's or a large partner's security review. Yearly maintenance is 15–25% of the build cost, as set out in the maintenance cost guide .

How the build runs

Callers and use cases. Who will call the API, to do what, how often.

Contract. The OpenAPI file or schema is written and reviewed with the people who will consume it.

Mock. A fake server that follows the contract lets front-end or partner teams start at once.

Build and test. Each operation is built with its permission tests.

Documentation and sandbox. Written from the contract, checked by someone who was not on the build.

First consumer. One real caller integrates, and what confused them is fixed in the documentation.

Operate. Monitoring, key rotation, and a version policy that is actually followed.

API design and development is listed with web application development and custom software and business systems at WavX.

Frequently asked questions

Who can develop an API for my business?

Any competent backend developer can expose data over HTTP. What separates a usable API from a liability is the work around it: a written contract, authentication, permission checks on every record, versioning, limits and documentation. Ask a developer or company for those by name, and ask to see API documentation they have written.

Should we choose REST or GraphQL?

REST for most business APIs, partner integrations and anything that benefits from standard HTTP caching and tooling. GraphQL when several different front ends need different slices of related data from the same backend. Many products use REST for partners and GraphQL for their own apps.

Do we need an API if we only have a website?

Not as a separate project. A website with a contact form does not need one. You need an API when a mobile app, a partner, a branch system or an automation has to read or change the same data as your main system.

How is an API kept secure?

By authenticating every caller, checking on every request that the caller may access that specific record, validating all input, limiting request rates, and logging access. The permission check is the one most often missed, which is why OWASP lists broken object-level authorisation first in its API security risks.

How much does API development cost?

In the WavX cost model a public API is a ₹70,000 line item on top of the system it belongs to. A worked example on this page comes to a planning range of about ₹5.4 lakh to ₹8 lakh for a web application with roles, a public API and third-party integrations. Adding an API to software we did not build is quoted after reading the code.

Sources

GraphQL: Serving over HTTP · read 2 October 2026

GraphQL: Schema design (versioning) · read 2 October 2026

OpenAPI Initiative: OpenAPI Specification v3.2.1 · read 2 October 2026

OWASP: API Security Top 10, 2023 · read 2 October 2026

RFC 6749: The OAuth 2.0 Authorization Framework · read 2 October 2026

RFC 7519: JSON Web Token (JWT) · read 2 October 2026

RFC 6585: Additional HTTP Status Codes (429 Too Many Requests) · read 2 October 2026

RFC 9457: Problem Details for HTTP APIs · read 2 October 2026

RFC 9745: The Deprecation HTTP Response Header Field · read 2 October 2026

RFC 8594: The Sunset HTTP Header Field · read 2 October 2026

IETF: The Idempotency-Key HTTP Header Field (Internet-Draft) · read 2 October 2026

Related

What is an API?

REST vs GraphQL: which API should you use?

What is a webhook?

Custom software and business systems

Build your own software — your way, your pricing.

WavX Solutions is here to create your own software in a fully custom way, built exactly how you work — with a pricing model that fits your business. Connect now and let's build it.

Contact Now helpwavx@gmail.com