Skip to main content
GullySystem

API Development

API development covers predictable errors, correct status codes, revocable keys, rate limits, a sandbox and a published reference. Versioned endpoints keep older callers, such as a dealer’s IT system, working.

Share your requirements

Who will call the API

Your own app

A private interface shaped around screens. It can change whenever both sides ship together.

A customer or dealer system

A contract that cannot be altered to suit your release plan, because their team deploys on its own schedule and not on yours. Changes are announced first.

A marketplace or gateway

Their rules and formats apply. A webhook from them has to be accepted at any hour, so retries and duplicate deliveries are handled. Failures are logged.

Decisions made before endpoints are written

Authentication

Keys, tokens or OAuth are chosen based on who calls the API. A single partner can be revoked without disturbing the others.

Errors and status codes

A failed validation returns a 400 that names the field. A 200 with an error buried inside is avoided. Callers can trust the code.

Rate limits

The number of calls a partner may make in a set period is agreed, and a partner who goes past the limit receives a clear response that says why. Limits are visible.

Keeping the API usable over time

Versioned endpoints

Older callers keep working while new fields arrive for everybody else. A change never breaks a partner without notice. Deprecations are announced.

A sandbox

Test keys and sample data let a partner build without touching live records. Their developers work independently.

A published reference

The reference is generated from the code, with examples a developer can copy and run. It stays current.

FAQ

Frequently asked questions

Should the API be REST or GraphQL?

REST for most business systems, since it is simpler to cache, debug and hand over to whoever inherits it later. GraphQL suits cases where many clients want different slices of the same data.

Can you document an API we already have?

Yes. The code is read, the reference is written, and every place where behaviour and existing documentation disagree is listed. That list is often the most useful part of the work.

How do partners test against it?

Through a sandbox with its own keys and sample records. Nothing they do touches live data. A short guide lets them start without contacting your team, and support is available.

Talk to us

Tell us what you need.

Share your requirements and one of our engineers will come back to you within one business day.

What happens after you share your requirements

  1. A senior engineer reads your answers. Nobody phones first.
  2. Within one business day you get a written note: what we understood, what we would start with, and the questions we still have.
  3. If it fits, a proposal follows with the order of work, what we need from you and what you receive at each step.
  4. No call is booked and nothing is paid until you have read the note. Your details stay with us.

Start with your requirements

Seven short steps that tell us what you need. A senior engineer reads them before anyone gets in touch.

Share your requirements