Atmora Tech

Engineering

APIs your partners
can integrate unaided

An API is a promise you cannot quietly withdraw once somebody has built against it. We design the contract first, publish it, and put the versioning and deprecation policy in writing before a single endpoint reaches production.

Overview

Contract-first interfaces with versioning, quotas and deprecation rules agreed up front.

The expensive mistakes in API work are made in week one and paid for in year three. A resource named after an internal database table, a field that means two different things depending on the caller, an enum that grows without a version bump: each one becomes permanent the moment a partner ships production code against it.

So we write the OpenAPI or GraphQL schema before the implementation, review it with the teams who will consume it, then generate server stubs, mock servers and client SDKs from that single source. The specification stops being documentation that drifts away from reality and becomes the artefact the build itself depends on.

Operationally, an API is a product with users. It needs a sandbox holding realistic data, quotas that reject politely with a retry hint, request logs a partner's engineer can search when their integration breaks at 19:00 on a Friday, and a deprecation notice period sized to their release cycle rather than yours.

3 days
median partner integration, key issue to first live call
0 breaking
changes shipped outside the published policy in 26 months
48 ms
p95 gateway overhead including auth and quota checks

Capabilities

What this covers

Six areas we staff properly. If your problem sits outside them, the honest note at the foot of this page says so.

  • Contract-first design

    OpenAPI 3.1 or GraphQL schemas written and reviewed with consumers before implementation begins, with server stubs, mock servers and client SDKs generated from that single source of truth.

  • Versioning and deprecation policy

    Explicit compatibility rules, a version scheme consumers can reason about, sunset headers on retiring versions, and a notice period measured against your partners' release cycles rather than your roadmap.

  • Authentication and authorisation

    OAuth 2.1 and OIDC flows, mutual TLS for partner traffic, scoped tokens and per-client key rotation, with authorisation decisions evaluated centrally instead of reimplemented endpoint by endpoint.

  • Rate limiting and quota design

    Per-client limits with burst allowances, informative 429 responses carrying retry hints, and quota tiers reflecting the commercial agreement rather than a single global ceiling nobody can explain.

  • Developer experience and onboarding

    A sandbox with realistic seed data and a reset endpoint, worked examples in three languages, per-client searchable request logs, and self-service keys so integration starts without an email thread.

  • Gateway, catalogue and governance

    Kong or AWS API Gateway configuration, an internal catalogue recording owner and status per API, and linting rules that stop naming, error and pagination conventions diverging across teams.

Deliverables

What you get

  • Reviewed OpenAPI 3.1 or GraphQL schema held under version control
  • Generated client SDKs for the languages your consumers actually use
  • Published versioning, compatibility and deprecation policy
  • Sandbox environment with realistic seed data and a reset endpoint
  • Contract tests running against every release candidate on both sides
  • Gateway configuration with quotas, key issuance and per-client logging

Stack

What we build it with

  • OpenAPI 3.1
  • GraphQL
  • gRPC
  • Go
  • Node.js
  • Kong Gateway
  • AWS API Gateway
  • Spectral
  • Pact
  • Keycloak
  • Redis
  • Postman

Process

How the engagement runs

Two-week increments against a written definition of done. You can stop at any increment boundary and keep everything built so far.

  1. Consumer interviews

    We talk to the people who will call the API, internal and external, and design around their workflow. Endpoints modelled on your database schema always leak your org chart.

  2. Write the contract

    The schema is written, linted against conventions and reviewed before implementation starts. Consumers build against a generated mock while the real service is still being written.

  3. Implement against the contract

    Contract tests run in CI on both sides, so a response drifting from the specification fails a build instead of surprising a partner in production three weeks later.

  4. Harden and instrument

    Auth flows, quotas, error taxonomy and per-client logging land before launch, with load tests confirming limits behave under abuse rather than only under polite traffic.

  5. Publish and support

    Documentation, SDKs and sandbox go live together, alongside a changelog, a deprecation calendar, and a support path that reaches an engineer rather than a ticket queue.

When this is the wrong engagement

If the only consumer is a single internal application you deploy in lockstep with the service, a published API contract adds ceremony without buying the independence it exists to provide.

FAQ

Questions we get asked

REST or GraphQL?

REST for partner-facing and machine-to-machine integration, where caching, simple tooling and a stable contract matter most. GraphQL where a first-party client assembles varied views and round trips hurt. Running both is legitimate; exposing GraphQL to external partners usually creates support load nobody priced.

How do you handle breaking changes?

By avoiding them where we can and scheduling them where we cannot. Additive changes ship continuously. Anything breaking gets a new version, dual running for an agreed period, sunset headers on the old version, and direct contact with every client the logs still show using it.

Can you expose an API over a legacy system?

Yes, and it is a common request. We put a facade in front of the legacy system that speaks a clean contract, absorbs its quirks and caches what it safely can. That facade also creates the seam you will need later when the legacy system is finally replaced behind it.

Who monitors the API once it is live?

You do, using the instrumentation we leave behind. Dashboards break traffic down by client, endpoint and version, alerts fire on error rate and quota rejections per consumer rather than aggregate throughput, and the runbook covers the failure modes that drive most partner tickets.

Related

More in Engineering

Start a project

Tell us what is
breaking.

We reply within one working day, and the first call is with an engineer who would actually work on it — not an account manager. If we are not the right studio for the problem, we will say so on that call.

Start a project