We design REST and GraphQL APIs that other developers actually like consuming, and wire up the messy 3rd-party integrations that keep your business running. Versioned, documented, monitored, and idempotent — production-grade from the first deploy.
APIs that look fine in week one become the slowest part of your roadmap by month six. The cause is almost always one of these four — and each is fixable with the right discipline up front.
Inconsistent naming, mix of REST + RPC + ad-hoc shapes, status codes that mean different things on different routes, errors returned as 200 with `{success:false}`. Every consumer needs a per-endpoint cheat-sheet to use it.
No signature verification, no idempotency, no exponential backoff, no replay UI. When the consumer is briefly down — and they will be — the event is lost forever. Reconciliation becomes a weekly cron job everyone secretly fears.
No versioning strategy means every breaking change becomes its own world. Old clients break silently, new clients can't trust contracts, and you can never deprecate anything because nobody knows who's still on the old shape.
Docs hand-written and out of date the moment the next PR merges. No interactive console, no schema validation, no examples for partner devs to copy-paste. Onboarding a new integrator takes a week of Slack threads.
The "API" word covers a lot of jobs. Here's how we slice the engagement based on what you actually need.
You're opening up your product to integrators, building a marketplace, or shipping APIs as a paid product. The bar is "third-party developers love consuming it" — versioned, rate-limited, documented, monetised.
Your web app, mobile app, and admin dashboard all need the same backend. We design it as one versioned API surface so the team isn't writing the same logic three times.
You don't need to build the API — you need to consume someone else's properly. Stripe, Xero, Sage, HubSpot, Salesforce, SAP B1, SARS eFiling. We wire them up so the data is right, the failures are loud, and the recon is automatic.
Inbound webhooks from gateways and partners. Outbound webhooks to your customers. Internal event buses for decoupled microservices. Everything signed, retried, and replayable.
These are the principles every Sitect API ships with. They're not optional, they're not negotiable, and they're not "phase 2".
Every entity follows the same envelope: `id`, `created_at`, `updated_at`, a stable shape across endpoints. Predictable to consume, easy to type, easy to cache.
2xx for success, 4xx for caller error, 5xx for our error. No 200 OK with `{success:false}` ever. The status is the first signal — make it accurate.
Every error returns `error.code`, `error.message`, `error.field`, `error.docs_url`. Clients can pattern-match on codes; humans can read the message.
Every POST/PUT accepts an `Idempotency-Key` header. Retried requests return the original response. No duplicate orders, ever.
Cursor-based pagination for performance. `next_cursor` + `has_more` in the response. No "page=999 timeout" surprises.
Major versions in the URL (`/v1`, `/v2`). Additive changes only within a version. Deprecation announced 6 months ahead with `Sunset` headers.
`X-RateLimit-Limit`, `X-RateLimit-Remaining`, `X-RateLimit-Reset` headers on every response. Per-plan tiers. 429s include retry hints.
Every request gets a `X-Request-Id`. Logs include request ID + tenant + user. Tracing across services. "Tell me which request failed" → instant answer.
Every one of these has been wired up by Sitect at least twice. We have the war stories, the working patterns, and the integration runbooks.
Payments · Billing · Webhooks
Card · Recurring · Reporting
SA gateways · Webhooks
Invoices · Contacts · Ledger
Stock · Customers · GL
ERP · BOM · Orders · GL
SA ERP · Inventory · Recon
CRM · Deals · Marketing
Accounts · Opportunities
Twilio · 360dialog · Meta
SA courier APIs
LLM · Embeddings · Vision
Each protocol has its sweet spot and its disaster zone. We pick by job, not by what's trendy this year. Here's how we think about each.
Predictable, cacheable, easy to consume from any language. Our default for public APIs and most internal APIs. OpenAPI 3.1 specs generated from the code.
When clients need flexible field selection or aggregate data from multiple resources in one round-trip. Schema-first, with per-field auth + complexity limits.
Internal high-throughput service-to-service calls where Protobuf strictness and bidirectional streams matter. Not for partner-facing endpoints.
Push-based notifications for long-running or async work. Signed, idempotent, retried with exponential backoff. Dead-letter queue + replay UI standard.
Code is necessary but not sufficient. An API isn't real until the docs are usable, the monitoring is on, the SDKs work, and the SLAs are documented.
Tested, deployed, MIT-licensed in your repo. Domain logic separated from HTTP concerns so the API can evolve without rewriting business rules.
Auto-generated from code annotations, always in sync. Used to drive interactive docs, client SDKs, and contract tests.
Scalar / Redoc / Stoplight portal at `docs.api.yourdomain.com` with try-it-now console, code samples in 6 languages, search.
Unit + integration test suites. Contract tests in CI that fail if a breaking change ships without a version bump. Mock server for consumers.
Per-endpoint latency + error-rate dashboards, SLO definitions, alerting to your on-call. The day a customer hits a bug you know first.
Any defect we ship gets fixed free for 60 days. We watch your logs daily during the window and respond inside 1 business day.
Most engagements run 1–4 weeks depending on scope. The flow below applies whether we're designing a brand-new API or wiring up a 3rd-party integration.
Map use-cases, consumers, auth model, data shapes, SLAs, edge cases.
Day 1–2OpenAPI / GraphQL schema drafted & reviewed before code is written.
Day 3–5Endpoints implemented against the schema, unit + integration + contract tests.
Week 2–3Interactive docs portal, SDKs generated, dashboards + alerts in place.
Week 3Production deploy, partner onboarding, 60-day defect warranty active.
Week 4Indicative metrics across SA API + integration engagements, measured 60 days post-launch. The biggest wins come from disciplined webhooks + clean contracts.
Every API project is scoped per build — these are the bands we usually land in. 50% on signature, 50% on go-live.
Honest answers about REST vs GraphQL, when an API is "real", what we won't build, and how to know if you need this work.
Whether you have an existing API to audit, a partner you need to integrate, or a clean-slate design for a new platform — share the context, and we'll come back with a recommended tier and an indicative budget.