AI ERP with agents inside the systems you run
AI phone and voice agents for real calls
LLM.coPrivate, self-hosted LLM deployments
Legal AI infrastructure for firms
AI RFP discovery and response drafting
Automatic.coBusiness process automation
CyberAttack.aiThreat detection and defense
Secure AI virtual data rooms
REST
GraphQL & webhooks
Whatever the consumer needs
390+
Projects shipped
Since 2013
99.9%
Uptime targets
With the alerting to prove it
100%
Docs and code yours
OpenAPI from day one
What you are buying
Four kinds of API work that get sold as one thing
These have different risks, different costs and different failure modes. Quoting them as a single line item is how integration projects overrun.
Building an API others consume
A public or partner interface with versioning, authentication, rate limits and documentation. The hard part is not the first endpoint — it is that every design decision becomes permanent the moment somebody integrates against it, so the contract deserves more care than the implementation.
Integrating somebody else's
Where most of the real cost lives, and almost none of the estimating attention. The difficulty is never your code; it is their pagination, their rate limits, their undocumented error codes and their sandbox that behaves differently from production.
Making two systems agree
Synchronising data between systems that each believe they are authoritative. This is a data-modelling problem wearing an integration costume, and solving it with a nightly job that overwrites one side is how companies end up with two sets of numbers.
Webhook and event infrastructure
Receiving events reliably means signature verification, idempotency, retries with backoff, and a dead-letter queue somebody actually reads. Sending them means the same guarantees in reverse, because your consumers will be down at some point and that must not lose their data.
What makes an API worth integrating against
The five properties consumers judge you on
An API is a product with developers as its users, and they form an opinion in about twenty minutes.
| Property | What it means in practice |
|---|---|
| Predictable | Consistent naming, consistent pagination, consistent errors. A developer should be able to guess the fifth endpoint correctly after reading four. Surprise is the most expensive thing an API can contain. |
| Honest errors | A machine-readable code, a human-readable message, and a documented list of what can go wrong per endpoint. A 500 with an empty body turns a ten-minute fix into a support ticket. |
| Versioned deliberately | A stated compatibility policy and a deprecation window, decided before the first consumer arrives. Breaking changes shipped without one destroy trust faster than downtime does. |
| Documented from the source | OpenAPI generated from the implementation, so the docs cannot drift. Hand-maintained documentation is accurate exactly once. |
| Observable | Per-consumer metrics and structured logs, so when somebody says the API is slow you can tell them which endpoint, which client and since when. |
Protocols and patterns
What we build with, and when each one is the right answer
Most of these decisions are reversible only at significant cost, so they get made deliberately and written down rather than inherited from whatever the last project used.
| Approach | When it is right | What it costs you |
|---|---|---|
| REST over HTTP | The default for anything external | Cacheable at the edge, debuggable with tools every developer already has, and integrable without a client library. Unless something specific argues otherwise, this is what a partner wants to receive. |
| GraphQL | Many clients, very different data shapes | Earns its complexity when over-fetching is a measured problem rather than a theoretical one. The costs are a schema to maintain, a caching story to solve and query-depth limits to enforce before somebody writes an expensive query. |
| Webhooks | You need to tell someone something happened | Signed payloads, at-least-once delivery, exponential backoff and a replay endpoint. Consumers will be down; the design has to assume it rather than hope. |
| Message queues | Work must survive a restart | SQS, Pub/Sub or Rabbit between services so a deploy or a third-party outage delays work instead of losing it. The queue is also where back-pressure becomes visible before it becomes an incident. |
| gRPC | Internal service-to-service, high volume | Worth the tooling cost inside your own perimeter where both ends ship together. Rarely worth exposing to partners, who mostly want to curl something. |
| File and batch | The other side is a bank or an ERP | SFTP drops and fixed-width files are still how large parts of finance and logistics work. Treating that as legacy rather than as a requirement is how integration projects lose a month. |
How an engagement runs
From credentials to production traffic
Integration work has a specific shape, because the expensive discoveries are almost always about the other system rather than yours. The sequence below front-loads those.
| When | What happens | Why it is there |
|---|---|---|
| Week 1 | Contract discovery | Read their docs, then verify them against actual responses — pagination, rate limits, error codes, auth expiry, what their sandbox does differently from production. The gap between documented and real behaviour is the project's main risk and it is found here, not in week five. |
| Week 1–2 | Data model agreement | Decide which system is authoritative for each field, and what happens when both change. Written down and agreed by someone with authority, because this is the decision that quietly creates two sets of numbers if it is skipped. |
| Week 2–4 | Build behind a flag | Idempotency keys, retry with backoff, dead-letter capture and per-consumer credentials from the first commit rather than added after the first incident. Shipped dark so it can run against real traffic before anything depends on it. |
| Week 3–5 | Run against production shadow | Real volumes, real edge cases, no user impact. This is where rate limits, timeout behaviour and the records that break assumptions actually surface. |
| Cutover | Monitoring before switch | Dashboards, alerts on the dead-letter queue, and a documented rollback. Then traffic moves. An integration that goes live before it is observable is one nobody can defend at 3am. |
Where an existing integration is already live and misbehaving, the same sequence runs in reverse: shadow the current behaviour, find where it diverges from what anyone believes, then fix against evidence.
What it costs
API development and integration pricing
Real ranges. The variable that moves a quote is not endpoint count — it is how well documented the other side is, and whether it has a sandbox that behaves like production.
| Engagement | Typical range | Timeline | What it buys |
|---|---|---|---|
| Single integration | Scoped per engagement | 2 – 5 weeks | One third-party system connected properly: auth, sync, retries, error handling, monitoring. Not a script that runs nightly and hopes. |
| API build | Scoped per engagement | 6 – 12 weeks | A REST or GraphQL interface for external consumers with versioning, rate limiting, OpenAPI docs and a developer sandbox. |
| Event infrastructure | Scoped per engagement | 4 – 10 weeks | Webhook delivery or ingestion with signatures, idempotency, retries, dead-letter handling and replay. |
| Integration platform | Scoped per engagement | 3 – 8 months | Many systems, one canonical data model, and the reconciliation that stops two sources disagreeing. |
| Rescue engagement | Scoped per engagement | 2 – 6 weeks | An integration that half works. Usually idempotency, rate limiting or error handling that was never built, found and fixed against real traffic. |
Ranges assume US-based senior engineers and include testing, monitoring and documentation. An integration quoted without those three is a prototype, and the difference shows up the first time the other side has an outage.
Where integrations fail
Five traps that turn a two-week job into a two-month one
Every one of these is cheap to design for at the start and expensive to retrofit under load.
No idempotency
The same webhook arrives twice — which it will, because every reputable sender retries — and you charge the customer twice. An idempotency key at the boundary costs an afternoon. Reconciling duplicate financial records costs considerably more.
Rate limits discovered in production
The sandbox had generous limits and production does not. Backoff, queueing and a bulk strategy belong in the design, not in the incident review.
Sync built as a nightly overwrite
One side wins by default and edits made on the other side vanish overnight. Users stop trusting the data and start keeping a spreadsheet, which is the failure you were integrating to prevent.
Their outage becomes your outage
A synchronous call to a third party inside your own request path means their downtime is yours. Queue it, degrade gracefully, and tell the user something true.
Nobody watches the dead-letter queue
Failures are captured correctly and then never looked at, so the system quietly drops data for weeks. A queue with no alert on it is a queue that does not exist.
Systems we integrate against most
The integrations that come up every month
Not an exhaustive list — it is where we have already met the undocumented behaviour, which is the part you are really buying.
Payments and finance
Stripe, Adyen, Plaid, QuickBooks, NetSuite, Xero. Idempotency is non-negotiable here: a retried webhook that charges twice is the most expensive bug in this category, and every one of these senders retries.
CRM and sales
Salesforce, HubSpot, Pipedrive, Dynamics. The recurring difficulty is not the API, it is that custom fields differ per tenant, so a mapping layer belongs in the design rather than hard-coded field names.
Commerce
Shopify, WooCommerce, Magento, BigCommerce. Watch tax and currency handling — whether totals include tax varies by platform and by store setting, and getting it wrong is a reconciliation problem rather than a crash.
Identity
Okta, Auth0, Entra ID, Google Workspace. SCIM provisioning is usually the real requirement behind 'we need SSO', and it is a meaningfully larger job than the login flow.
Logistics and ERP
SAP, Oracle, Dynamics, carrier APIs, EDI. Expect batch files and fixed-width formats alongside anything modern, and budget for a sandbox that does not exist.
Communications and AI
Twilio, SendGrid, Slack, plus OpenAI and Anthropic endpoints. Rate limits and token accounting are the operational concerns; both need queueing under real load rather than synchronous calls.
Security and reliability
What has to be true before an API carries real traffic
These are the checks an integration is audited against here, and the list a client can hold us to.
Per-consumer credentials
Every consumer gets its own key or client, scoped to what it needs. A shared credential you cannot revoke for one customer without breaking the others is an incident waiting for a reason to happen.
Secrets in a managed store
Parameter Store, Secret Manager or Vault, injected at runtime. Never in the repository, never in a committed env file, and rotatable without a deploy.
Signature verification on inbound
Every webhook payload is verified against the sender's signature before it is parsed, and a replayed request with an old timestamp is rejected. An unauthenticated inbound endpoint is a public write API.
Rate limits you enforce
Limits per consumer, returned as headers so a well-behaved client can back off, with a 429 rather than a timeout when they are exceeded. Protecting your own database is the point.
Timeouts and circuit breaking
Every outbound call has a timeout and a defined behaviour when it trips. A third party that hangs must not hold your request threads open until the whole service falls over.
Alerting that reaches a person
Error rate, latency percentiles and dead-letter depth, alerting to somewhere a human reads. Dashboards nobody opens are documentation, not monitoring.
Related
Related services
Work that commonly sits either side of an integration project.
Questions
Buying API development
What teams ask before a first call.
A single third-party integration is the smallest engagement here; building an API that other companies consume is a larger one. The table above sets out the shapes.
What moves a quote is the quality of the other side — a well-documented API with a real sandbox lands at the bottom of any range, and an undocumented legacy SOAP endpoint with no test environment can cost more than the feature it feeds. That is why the number comes from a scoping call rather than a price list.
Two to five weeks for a single integration, six to twelve for an API other companies will consume. Event infrastructure sits between the two.
The schedule risk is rarely engineering. It is credentials, sandbox access, and how quickly the other side answers questions about their own undocumented behaviour.
REST unless something specific argues otherwise. It is simpler to cache, simpler to debug with tools everyone already has, and simpler for a consumer to integrate without a client library.
GraphQL earns its complexity when many different clients need very different shapes of the same data, and over-fetching is a measured problem rather than a theoretical one. Choosing it before that point buys you a schema to maintain and a caching story to solve.
Yes, and often the first useful engagement is a review rather than a build — versioning policy, error consistency, authentication, rate limiting and what the docs claim versus what the code does.
Where an existing API has consumers, we work incrementally: new behaviour behind a version, old behaviour supported through a stated deprecation window. Breaking somebody else's production to tidy your own is not a trade worth making.
OAuth 2.0 where third parties integrate, API keys with scopes for server-to-server, and short-lived tokens with refresh for first-party clients. Secrets live in a managed store, never in the repository or an environment variable committed by accident.
Whatever the mechanism, per-consumer credentials are the non-negotiable part: a shared key you cannot revoke for one customer is an incident waiting for a reason.
The code, infrastructure defined in Terraform in your own cloud account, OpenAPI documentation generated from the implementation, a Postman or equivalent collection, and monitoring with alerts that reach a human.
Also a written list of the assumptions we had to make about the other system, which is the document that saves the next engineer a week.