Hi, I'm Ari 👋
I can help you automate tasks and answer questions about your business.
Services > API and System Integrations
API AND SYSTEM INTEGRATIONS
Custom code integrations for the work that does not fit Zapier, Make.com, or n8n. Direct API connections, custom auth flows, webhook architectures, ETL pipelines, and embedded integrations. Production-grade reliability, fully owned by you.
A POST request to /v2/orders with Bearer token authorization. The request body contains a customer_id field set to cust_4823 and an items array. The API responds with 201 Created, returning an order_id of ord_8472 and status of created.
A real integration in 13 lines of code. We write the rest. Auth, retries, validation, monitoring, deployment.
Production integrations shipped. Node.js, Python, TypeScript, Go. AWS, GCP, on-prem.
WHEN TO PICK THIS
No-code automation platforms are excellent at what they were designed for: standard integrations between common SaaS tools, run at moderate volume, with simple data transformations and standard auth. When the work moves outside those boundaries, the platforms either cannot do it or do it poorly. The four scenarios below are where we usually get called in.
01
When the integration is a feature your customers see, it cannot live in a third-party automation tool. Customer-facing reliability, latency, and brand control all require the integration to run in your own infrastructure as part of your own product code.
TELLTALE SIGN
Your customers experience the integration as part of your software, not as "we use Zapier under the hood."
02
OAuth 2.0 with refresh token rotation, mTLS, signed webhooks, enterprise SSO, custom JWT handling. The moment the auth model requires real implementation work, no-code platforms either lack support or implement it in ways that fail in edge cases.
TELLTALE SIGN
Your vendor's auth docs are longer than two pages.
03
At very high volume, no-code platforms either become expensive or hit rate limits. At very low latency, the abstractions in no-code platforms add overhead you cannot afford. Custom code lets you tune for the actual constraints.
TELLTALE SIGN
Your integration needs to run in under 200ms, or your monthly task usage on Zapier crossed six figures.
04
Iterating over nested arrays, joining responses from multiple APIs, computing derived fields with business logic, validating against a complex schema, denormalizing for a downstream system. At some point, the work becomes engineering work, not configuration work.
TELLTALE SIGN
Your no-code workflow has more than ten Formatter or Function nodes in a single scenario.
INTEGRATION PATTERNS
Most integration work falls into one of six architectural patterns. Picking the right pattern is half the build. The other half is implementing it without skipping the parts that make production reliable.
REST API integration
PATTERNThe default for most modern SaaS integrations. We build clients that handle authentication, pagination, rate limits, retries, and schema validation. Often the foundation that other patterns sit on top of.
Webhook receiver with queue
PATTERNAccept high-volume webhook events into a queue, process them in workers, handle retries on failure. The right architecture when you cannot guarantee the downstream system will be available when the event fires.
GraphQL aggregation
PATTERNA single GraphQL endpoint that aggregates data from multiple backend APIs. Reduces round trips for client applications, lets you evolve the API contract without coordinating with every consumer.
ETL data pipeline
PATTERNExtract from one system, transform with business logic, load into another. Scheduled or event-driven. For data warehouse loads, reporting feeds, or system-to-system migrations that need to run repeatedly.
Event-driven architecture
PATTERNPublish events to a bus (Kafka, SNS, EventBridge, Pub/Sub). Multiple downstream services subscribe and react independently. The right pattern when one upstream change needs to trigger many downstream actions reliably.
Embedded customer integrations
PATTERNIntegrations your customers configure inside your product to connect their tools. White-labeled, multi-tenant, with secure credential storage and per-customer error isolation. Common in vertical SaaS and platform companies.
AUTHENTICATION
Most integration failures happen in the authentication layer. Tokens expire. Refresh flows break. API keys leak. The five auth methods below cover almost everything we work with. We implement each one with the failure modes baked in.
We have also implemented enterprise SSO (SAML, OIDC), custom auth schemes from legacy systems, and the long tail of one-off auth requirements that show up in real integration work.
REAL PROJECTS
Anonymized for client confidentiality. The architecture and decisions are real. The metrics are approximations where exact numbers would identify the client.
Our client's customers wanted to sync their CRM data into our client's product without IT lift. We built an embedded Salesforce integration where customers connect their own org via OAuth, choose which objects to sync, and the data flows in real-time through webhooks plus a fallback sync.
WHY CUSTOM CODE
Customer-facing reliability and multi-tenant credential storage made no-code platforms unsuitable. The integration is a product feature, not a backend automation.
A payment processor sending 50,000+ webhook events per day to our client. The existing webhook handler was missing events under load and double-processing on retries. We rebuilt it with proper queue topology, idempotency keys, and replay protection.
WHY CUSTOM CODE
At this volume, no-code platforms either rate-limit or silently drop events. The reliability requirements demanded a real engineering solution with monitoring and dead-letter queues.
A healthcare client needed to bridge an older HL7-based clinical system with a modern FHIR-compatible application. Required full HIPAA compliance, audit logging of every message, and no third-party data processing.
WHY CUSTOM CODE
HIPAA compliance, custom message format translation, and on-prem deployment requirements ruled out every no-code option. This was bespoke middleware work.
An e-commerce brand selling on five channels needed a single internal source of truth for orders. Each channel had different webhook payloads, refund flows, and inventory deduction logic. We built the aggregation layer that normalized everything into a single canonical order model.
WHY CUSTOM CODE
Five distinct schemas, complex deduplication logic, and downstream fulfillment routing made this far beyond what no-code platforms can model cleanly.
A SaaS platform wanted to offer customers an integration marketplace where third-party developers could build apps that connect to customer accounts. We built the OAuth provider side of the equation: app registration, consent flows, scoped tokens, revocation, audit logs.
WHY CUSTOM CODE
Being the OAuth provider (not consumer) is engineering work that no-code platforms do not even attempt. This required deep understanding of the OAuth 2.0 spec and PKCE flows.
THE STACK
No religion about languages or frameworks. We pick what fits the use case, the team that will inherit the code, and the infrastructure already in place. Below is the spread of what we work with most.
LANGUAGES
Languages and runtimes
FRAMEWORKS
Frameworks and libraries
INFRASTRUCTURE
Cloud and runtime
DATA AND QUEUES
Data stores and queues
OBSERVABILITY AND OPS
Plus the operational stack
PRODUCTION RELIABILITY
The difference between an integration that works in a demo and one that survives in production is the six things below. Skip any of them and the integration becomes someone's problem at 2am within a year. We build them in from day one.
Every operation that creates or modifies data should be safe to retry. Network failures happen. Workers crash. Requests time out. Without idempotency, a retry causes duplicate orders, duplicate charges, duplicate emails. We build it in by default.
WHAT WE BUILD IN
Idempotency keys, deduplication windows, exactly-once delivery semantics where possible, at-least-once with safe-to-retry handlers everywhere else
Transient failures are the rule, not the exception. Network blips, vendor API hiccups, rate limit windows. Retries should be smart: exponential backoff, jitter to avoid thundering herd, max retry caps to avoid infinite loops, dead-letter queues for what cannot be saved.
WHAT WE BUILD IN
Exponential backoff with jitter, retry caps (typically 3-5 attempts), dead-letter queue routing after exhaustion, alerting on DLQ growth
Every third-party API has rate limits. The polite integration respects them. The smart integration uses them as a signal for self-pacing. Our integrations track remaining quota, slow down before hitting the wall, and queue requests instead of hammering the API.
WHAT WE BUILD IN
Token bucket or leaky bucket pacing, 429 response handling, retry-after header respect, per-tenant quota tracking for multi-tenant integrations
If you cannot see it, you cannot fix it. Every integration ships with metrics on throughput, error rate, latency, and queue depth. Alerts fire on anomalies. The first time you know something is wrong is not a customer complaint.
WHAT WE BUILD IN
Per-endpoint metrics, structured logging, error rate alerts, latency p95/p99 alerts, queue depth alerts, runbook documentation for each alert
API keys, OAuth tokens, signing secrets, certificates. Storing them in env vars or config files is how integrations end up in breach reports. We use proper secret stores with rotation, audit logging, and per-environment isolation.
WHAT WE BUILD IN
AWS Secrets Manager, GCP Secret Manager, HashiCorp Vault, or your existing solution. Per-environment isolation. Rotation hooks built in.
When a downstream system is down, your integration should not bring down your application. We design for partial failure: feature flags, circuit breakers, fallback paths, cached responses where appropriate. The integration fails softly while the rest of the system keeps running.
WHAT WE BUILD IN
Circuit breaker patterns, timeout budgets, fallback to cached data, feature flag kill-switches, separate failure domains per integration
HOW WE BUILD
Integration work that ends up in production needs to be reviewed like production engineering work, not like configuration work. Below is how we build it, including the checkpoints where your team signs off before we move forward.
Map the systems involved, understand the data flows, identify the auth requirements, sketch the architecture options. We document constraints (volume, latency, compliance) before designing anything.
REVIEW POINT
You review and approve the architectural approach before we move to design.
Detailed design: API contracts, data schemas, error handling strategy, deployment topology, monitoring approach. Documented as written specs your team can review like a real design doc.
REVIEW POINT
Your engineering team reviews the design doc. We adjust based on feedback before writing code.
Implementation against the design. Test-driven where it makes sense. Includes unit tests, integration tests, and load tests proportional to the production volume the integration will see.
REVIEW POINT
Code review by your team if you want one. We push to a branch in your repo (or ours) with documented PRs.
Deploy to your staging environment first. Run end-to-end tests with real (test mode) credentials. Cut over to production with monitoring in place from the first minute. Rollback plan documented.
REVIEW POINT
Production cutover happens on a schedule you control, with you in the room or on the call.
Full documentation: architecture diagrams, runbooks, incident response procedures, on-call playbook. Optional retainer if you want us to stay on for ongoing operations and improvements.
REVIEW POINT
Your team can either take operations from here or retain us for ongoing support. Both are common.
FAQ
What engineering leaders ask before signing. Click to expand any answer.
READY TO TALK SHOP
Forty-five minutes. Walk us through the systems involved, the constraints (volume, latency, security, compliance), and what your team has already tried. We will tell you what an integration looks like, what stack we would pick, and what production-grade actually means for your case.
Book an integration scoping callNo pressure. Just value.
Hi, I'm Ari 👋
I can help you automate tasks and answer questions about your business.