API Development Services for US & EU Platforms

Decision is driven by consumer profile, not engineering taste. Public-facing APIs and third-party integrations go REST with OpenAPI 3.1 — it is the universal contract, every SDK generator supports it, every API gateway speaks it, every customer can curl it. GraphQL when you have a multi-team frontend (web + iOS + Android) hitting a deep object graph and the under/over-fetching problem is real, federated via Apollo Federation 2 or Hot Chocolate when multiple teams own different subgraphs. gRPC for internal service-to-service where latency budgets are tight (<10ms p99) and both sides are yours — protobuf gives you typed contracts, streaming, and connection multiplexing. We never use GraphQL for service-to-service and we never use gRPC for public APIs.

OpenAPI 3.1 (or proto file, or GraphQL SDL) lives in a versioned spec repo separate from the implementation. PR review on the spec happens before a line of handler code is written — product, frontend, mobile, and at least one external consumer (if applicable) sign off on the contract. Spectral lints the spec against your style guide (camelCase vs snake_case, error envelope shape, pagination contract, etc.). Spec changes flow through openapi-diff with a breaking-change CI gate — a PR that breaks the contract requires an explicit version bump label. Mock servers (Prism for REST, Mockoon, mock subgraphs for GraphQL) are auto-deployed per branch so frontend teams unblock immediately.

REST: URI-path versioning (/v1, /v2) for public APIs (clearest for third parties), header-based for internal where consumers are controlled. We commit to N-2 support: when v3 ships, v1 enters a 12-month deprecation window with Sunset and Deprecation headers (RFC 8594), 90-day, 30-day and 7-day reminder emails to API key owners, and a public changelog. GraphQL: field-level @deprecated directives with reason and migration hint, usage telemetry from Apollo Studio or Hive to confirm zero traffic before removal. gRPC: protobuf evolution rules strictly enforced (never renumber fields, never reuse field numbers, additive changes only without a major version bump).

OAuth 2.1 + OIDC for user-facing auth (Auth0, WorkOS, Clerk, or your own Keycloak/Ory Hydra when self-hosting is required). mTLS + SPIFFE/SPIRE for service-to-service. API keys with HMAC signing for partner integrations, JWT with RS256 or EdDSA (never HS256 with shared secret in 2026, and never RSA below 2048 bits). Gateway choice depends on stack: Kong or Tyk for self-hosted, AWS API Gateway / Azure APIM / Apigee for cloud-managed, Cloudflare Workers + Hyperdrive for edge-first. Rate limiting at the gateway (sliding window or GCRA, never naïve fixed-window), with per-key, per-IP, and global ceilings. WAF in front always.

OpenTelemetry from day one — traces, metrics and logs with consistent semantic conventions, exported to your backend (Datadog, Honeycomb, Grafana Tempo + Mimir + Loki, or Elastic). Every request has a trace ID surfaced in error responses so support can pull the full trace in one click. SLOs defined per endpoint (latency p95/p99, error rate, availability), error budgets tracked in Grafana, burn-rate alerts paging on-call before SLO is breached. RED metrics dashboards (Rate, Errors, Duration) auto-generated from OpenAPI spec. Synthetic monitoring via k6 cloud or Checkly hitting critical paths every minute from US-East and EU-West.

API work is fixed-scope and tiered by complexity, all-in and quoted in USD. A bridge or single integration runs from $1,800; a contract-first API with real business logic from $4,100; an API wired to multiple external systems from $5,800; a full platform API (REST plus federated GraphQL or gRPC, multi-language SDKs, N-2 versioning, per-endpoint SLOs) from $10,400. The exact number depends on the number of protocols and endpoints, integration count, gateway and auth complexity, versioning depth and domain compliance (PSD2, HL7 FHIR, ISO 20022). You see the line-item budget after a free scope assessment and sign off before any code is written. SDK generation for additional languages (TS, Python, Go, Java, C#, Swift, Kotlin) is included via openapi-generator or stainless.com — no recruitment markup, no tool surcharges, and cloud, gateway and third-party API fees run on your own accounts.

Tenant isolation is a first-class design concern, not an afterthought. We evaluate three models at the start of every SaaS API engagement. Pool model (single schema, tenant_id column on every row): cheapest to operate, appropriate for SMB SaaS with hundreds of tenants, relies on row-level security (PostgreSQL RLS or application-layer enforcement — never just a WHERE clause a developer might forget). Silo model (schema-per-tenant or database-per-tenant): strongest isolation, required when enterprise customers contractually mandate it or when regulatory frameworks (healthcare, financial data) demand provable separation; operational cost scales with tenant count. Bridge model: shared compute, isolated storage per tenant — a middle path for mid-market SaaS where pool is too risky but full silo is too expensive. At the gateway layer we enforce per-tenant rate limits and quotas independently of auth, so a single tenant spiking usage cannot degrade neighbours. Webhook delivery includes tenant-scoped HMAC signing so your customers can verify events without sharing a secret across tenants.

An API gateway sits at the north-south boundary: it is the single entry point for external traffic, handling auth, rate limiting, WAF, routing and developer-facing concerns like API keys and usage plans. A service mesh handles east-west traffic: encrypted service-to-service communication inside your cluster, mutual TLS, circuit breaking, retries and observability between microservices. You need a gateway when you have external consumers (third-party integrations, your own mobile app, partners). You need a mesh when you have enough microservices that you cannot trust every team to implement mTLS, retry logic and timeout contracts correctly in application code. For most API engagements we start with a gateway (Kong, Tyk, or managed AWS/Azure) and introduce a mesh (Istio or Linkerd) only when the microservices count crosses the threshold where per-service configuration becomes unmanageable, typically 8–12 services with distinct teams owning each.

SDKs are generated from the same spec the server validates against — the spec is the single source of truth, not a document that trails the implementation. The generation pipeline runs in CI on every spec merge: openapi-generator or stainless.com regenerates typed clients for TS, Python, Go, Java, C#, Swift and Kotlin, runs the generated SDK test suite against a mock server (Prism for REST, mock subgraphs for GraphQL), bumps the semver patch or minor version, and publishes to npm/PyPI/Maven/NuGet/Packagist automatically. Breaking changes are blocked at the spec level by openapi-diff before they reach generation — a PR introducing a breaking change requires an explicit major-version bump label, which triggers a parallel deprecation track rather than a silent break. This means your customer’s TypeScript SDK and your Python SDK are always at feature parity with the live API surface, without a manual handoff between backend and SDK maintainers.

Yes. Inherited API work starts with a contract audit: we reconstruct the spec from the live API (using traffic capture or existing code), identify undocumented endpoints, inconsistent error envelopes, auth gaps (shared secrets in code, JWT with HS256 and symmetric keys, missing token expiry), and versioning debt (v1 with no deprecation plan, breaking changes shipped without version bumps). The output is a prioritised remediation backlog separated into security-critical (fix first, often in days), stability (rate limiting, retry contracts, timeout policies) and developer-experience (SDK generation, reference docs, mock server). We can operate and improve the API in parallel — we do not require a full rewrite before taking over, and we will tell you honestly if a rewrite is the right long-term answer versus incremental remediation.