Custom API integration is the bespoke work of connecting your business systems — ERP, CRM, e-commerce, warehouse management, accounting, marketing automation, and legacy in-house applications — so they share data automatically instead of through spreadsheets, copy-paste, and tribal knowledge. FreedomDev has built more than 200 production API integrations for mid-market companies in the last 18 years. We are not a unified API platform (Merge, Workato, Nango) — those products are right for connecting to common SaaS endpoints. We are the team you hire when the integration involves a 1996-era ERP that has no API, a custom application written in-house by someone who left in 2014, or an SAP S/4HANA flow that does not fit any product's predefined connector.
The 2026 API integration market is full of polished products: Zapier and Make for simple no-code workflows; Workato and Tray for enterprise iPaaS; Merge.dev and Nango for unified API platforms; Mulesoft for the deeply-enterprise SAP/Oracle world. Each of these is the right choice for some integration scenarios. They are the wrong choice for others.
**Off-the-shelf is the right answer when:** - Both sides of the integration are mainstream SaaS products (Salesforce ↔ HubSpot, Stripe ↔ QuickBooks, Slack ↔ Jira) - The data flow is well-defined and matches the platform's pre-built connectors - Your team can read iPaaS visual workflows and maintain them long-term
**Custom is the right answer when:** - One side of the integration is a legacy or custom system without a packaged connector - The data transformation is non-trivial (data model mismatches, business rules embedded in the mapping) - The volume or latency requirements exceed what the platform handles cleanly - You need full version control, code review, and deployment via standard CI/CD - The integration is core to your business and you want to own the code
The economic argument for custom: a typical enterprise iPaaS license runs $50k-$200k/year. A single custom integration costs $20k-$60k one-time. For mid-market companies with 5-15 integrations that change infrequently after deployment, custom is dramatically cheaper over a 3-5 year horizon — and the integrations live in your codebase, not in a vendor's cloud platform you cannot run if their service goes down.
Our engineers have built this exact solution for other businesses. Let's discuss your requirements.
Custom API integration is the bespoke work of connecting your business systems — ERP, CRM, e-commerce, warehouse management, accounting, marketing automation, and legacy in-house applications — so they share data automatically instead of through spreadsheets, copy-paste, and tribal knowledge. FreedomDev has built more than 200 production API integrations for mid-market companies in the last 18 years. We are not a unified API platform (Merge, Workato, Nango) — those products are right for connecting to common SaaS endpoints. We are the team you hire when the integration involves a 1996-era ERP that has no API, a custom application written in-house by someone who left in 2014, or an SAP S/4HANA flow that does not fit any product's predefined connector.
| Pattern | When | |---|---| | **Point-to-point REST** | Two systems, modest event volume (<10k events/day), simple data transformation | | **Message bus (Kafka, RabbitMQ, AWS SNS+SQS)** | Multiple consumers of the same event stream, high volume, decoupled producers and consumers | | **Webhook-driven event handlers** | Source system supports webhooks, destination needs near-real-time updates | | **Polling-based sync** | Source system has no webhook/event mechanism, periodic refresh acceptable | | **Change Data Capture (CDC) from database** | Source system has no API at all, only a database (legacy ERPs, custom in-house apps) | | **File-based integration (SFTP, S3)** | Bulk overnight exchange, EDI, partner integrations that predate APIs | | **Reverse ETL** | Operational data needs to land in tools (CRM, marketing automation) from data warehouse | Most projects use 2-3 of these patterns. A typical scope: "Salesforce → Custom App via REST + Webhook" (Patterns 1 + 3), or "Legacy ERP → Snowflake via CDC + S3 + Lambda" (Patterns 5 + 6 + 2).
Every custom integration project goes through the same six phases. The variability is in scope (one integration vs. many) and complexity (clean modern APIs on both sides vs. one side is a 1996 ERP). **Phase 1: Discovery (1-2 weeks).** Document each system's API surface, authentication, rate limits, and data model. Identify the data flows in scope. Map source fields to destination fields including transformations and business rules. Identify failure modes (what happens when System A says "saved" but System B rejects the same data 30 seconds later?). The deliverable: an integration specification document. **Phase 2: Architecture proposal (1 week).** Choose the integration pattern (from the table above). Define the integration service deployment target (containerized service, serverless function, on-prem if required). Document authentication, monitoring, and error-handling strategies. Define the test plan. **Phase 3: Build (4-12 weeks).** Implement the integration service in the agreed language and framework. We use Node.js/Fastify, Python/FastAPI, .NET/ASP.NET, or Go depending on the customer's existing stack. Each integration ships with unit tests for transformation logic and integration tests against sandbox environments where available. **Phase 4: Validation in lower environments (1-2 weeks).** Run the integration against staging or sandbox environments of both source and destination systems. Validate data correctness, error handling, retry logic, and observability. Catch the edge cases discovery missed. **Phase 5: Production deployment (1 week).** Deploy via CI/CD into the production environment. Run in shadow mode (logging the actions it would take without executing them) for a few days. Cut over to active mode with rollback plan ready. **Phase 6: Post-deployment stabilization (2-4 weeks).** Watch the integration in production. Fix the bugs production exposes that discovery and staging missed. Tune retry logic, error thresholds, and alerting. Hand off runbook and on-call procedures to your team.
The 80% of custom integration work that off-the-shelf tutorials skip: **Authentication.** Every API has different auth: OAuth 2.0 with refresh-token rotation, API keys, certificate-based mutual TLS, basic auth with rotating credentials, SAML assertions, signed JWTs. Custom integration code handles auth correctly, securely, and with appropriate rotation. Auth secrets live in a secrets manager (AWS Secrets Manager, Azure Key Vault, HashiCorp Vault), not in environment variables and definitely not in code. **Idempotency.** Network failures, duplicate webhook deliveries, and retry loops mean every write operation needs to be safe to repeat. We design integration logic to either be naturally idempotent (UPSERT by external ID) or to detect duplicates before re-applying (idempotency key, external transaction ID). **Rate limit handling.** Every API has rate limits. Our integration services back off exponentially on 429 responses, respect `Retry-After` headers, and surface persistent rate-limit issues to alerting rather than silently dropping requests. **Error handling and the dead-letter queue.** Some integration failures are transient (network timeout, brief downstream outage); some are permanent (validation error, schema mismatch). We retry transient errors automatically (typically 3-5 attempts with exponential backoff) and route persistent failures to a dead-letter queue with operator notification. Failed messages do not just disappear. **Observability.** Every integration ships with structured logs (JSON, with correlation IDs spanning source → integration service → destination), metrics (request volume, latency, error rates, queue depth), and alerts (error rate above threshold, queue backing up, downstream system unreachable). Without these, an integration that fails silently destroys data integrity over time and nobody knows until customer-impact symptoms surface. **Schema versioning.** APIs change. We design integration code to handle multiple versions of the source schema gracefully (defaulting unknown fields, logging unexpected schema for analysis) rather than crashing on the first new field a partner adds.
**E-commerce ↔ ERP synchronization.** Shopify, BigCommerce, or custom storefronts feeding orders into Epicor, NetSuite, Acumatica, or SAP. Inventory pushed back from ERP to e-commerce for availability checks. Bi-directional product master data sync. We have built this pattern more times than any other. **CRM ↔ ERP customer and order sync.** Salesforce or HubSpot opportunities converting to ERP sales orders. Customer master propagation in both directions. Order status updates pushed back to CRM. The challenge is usually around data model differences — CRM accounts vs. ERP customers vs. ERP business partners — and business rules that decide which CRM accounts become ERP customers and at what stage. **Warehouse Management → ERP.** Manhattan SCALE, HighJump, or Tecsys WMSes posting goods movements, picks, and shipments to ERP. High volume during business hours, often IDoc-based for SAP destinations. **Marketing automation ↔ CRM ↔ Customer Data Platform.** Salesforce ↔ HubSpot Marketing or Marketo ↔ Segment or RudderStack. The integration logic is heavy on attribution and deduplication. **Legacy in-house app ↔ Modern cloud system.** A custom-written application from 2008 that has no API, connected to Salesforce or NetSuite via a CDC pipeline from the legacy database. We have done this 20+ times. Each case is unique. **Data warehouse ETL/ELT.** Customer systems landing operational data into Snowflake, BigQuery, or Redshift. Increasingly we use modern tools (Fivetran for standard sources, dbt for transformation, custom Python orchestrated by Airflow for non-standard sources). **EDI / partner integration.** X12 850 (purchase order), 810 (invoice), 856 (advance ship notice), 940/945 (warehouse), etc. EDI translation layer either uses a commercial mapper or hand-written translators in modern languages. Final landing is usually the ERP via IDoc or REST.
For any integration scope, the build-vs-buy question depends on five factors. We work through these in discovery: 1. **Standardness of both sides.** Two mainstream SaaS products with mature APIs and well-known data models → buy. One side is legacy or custom → build. 2. **Volume.** Under 10k events/day → most off-the-shelf tools are fine. Over 100k → custom (off-the-shelf rate-limits and pricing tiers get ugly). 3. **Data transformation complexity.** Direct field mapping with no business rules → buy. Substantial transformation, business rules, conditional logic → build (the rules will need code anyway). 4. **Operational ownership preference.** Want the integration in your codebase with version control, code review, and your team's deploy process → build. Comfortable with iPaaS platform ownership → buy. 5. **3-5 year cost projection.** Buy is cheaper year 1 in most cases. Build is cheaper years 2-5 because the integration is paid off as a capex while iPaaS continues as opex. We will tell you to buy when buy is the right answer. About 30% of our discovery calls end with "you should use Zapier" or "Workato fits this scope." We do not take projects we do not fit; long-term that earns more business than fitting square pegs into round holes.
describe the integration scope, the source and destination systems, the volume and frequency
paid scope; we document both systems, propose the integration pattern, write the spec
flat-rate quote for the build; deliverables and milestones
typically 4-12 weeks; weekly demos to your team; we use whatever stack your engineering team prefers
staging integration; data correctness checks
shadow mode → active mode; documented rollback plan
2-4 weeks watching production, tuning, transferring knowledge
code in your repository, runbook in your wiki, on-call procedures documented We do not retain client integrations as black-box dependencies. Code lives in your repository. Your team can read it, modify it, and run it without us.
