Most small businesses run on four to eight software tools that don’t talk to each other. Orders come in through one system, get manually entered into another, and somewhere in the middle data gets lost or wrong. API integration fixes that at the source. But how you approach it — and whether custom code is actually the right tool — matters more than most clients realize before they start.

What API Integration Actually Means

An API — application programming interface — is a set of rules that lets two software systems exchange data. When your e-commerce platform sends an order to your fulfillment system automatically, that’s an API integration working. When you’re copying rows from a spreadsheet into a CRM by hand, that’s the absence of one.

I build custom integrations between the tools you use: CRMs, ERPs, accounting systems, scheduling platforms, payment gateways, marketing automation tools, and internal databases. The goal is that data enters the system once, at the source, and flows where it needs to go without human intervention.

Common Integration Scenarios

  • CRM to accounting: New customer in Salesforce or HubSpot automatically creates a record in QuickBooks or similar
  • Form submission to workflow: A lead form submission triggers tasks in a project management tool and a follow-up sequence in email
  • E-commerce to fulfillment: Orders flow from WooCommerce or Shopify to a 3PL or warehouse system without anyone touching a keyboard
  • Internal app to external service: Your custom application pushes data to Stripe, Twilio, a shipping carrier, or a government database
  • Legacy system modernization: Old software that has no public API gets a middleware layer that reads its database directly and exposes it to modern tools

Authentication: What You’re Actually Dealing With

Every API has an authentication mechanism, and they are not all the same. The three most common: API keys (a static token passed with each request — simple, but requires secure storage and rotation), OAuth 2.0 (a delegated authorization flow where the user grants access without sharing their credentials — more complex to implement, standard for user-facing integrations with platforms like Google, Salesforce, or QuickBooks), and JWT — JSON Web Tokens — (a signed token issued after authentication, common in custom-built APIs and internal systems). Knowing which mechanism you’re dealing with shapes how the integration is built, how credentials are stored, and what happens when tokens expire. I mention this because clients sometimes think “API integration” is one thing — it’s a category that spans from passing an API key in a header to managing OAuth refresh token cycles across multiple user accounts.

Webhooks vs. Polling

Two patterns for getting data from a system: polling (your integration checks the source system on a schedule — every five minutes, every hour) and webhooks (the source system pushes a notification to your endpoint the moment something happens). Polling is simpler to set up but creates latency and unnecessary API calls. Webhooks are faster and more efficient but require a publicly accessible endpoint to receive them and error handling for when the source system can’t reach you. Most modern platforms support webhooks. Legacy systems and simpler APIs often don’t. The right choice depends on how time-sensitive the data is and what the source system supports.

Data Transformation: Where Things Actually Break

The mapping exercise — figuring out how fields in one system correspond to fields in another — is where most integration projects surface their real complexity. A customer record in your CRM has a “Company Name” field. Your accounting system has “Business Name” and “DBA” as separate fields. Your shipping system wants a single “company” string with a 40-character limit. These mismatches are routine, and handling them correctly requires knowing the business rules: which field wins, what gets truncated, what triggers a validation error downstream.

Phone number formatting is a classic one. CRM stores “(602) 555-1234”. The destination system expects “+16025551234”. Pass the wrong format and the record either fails silently or creates a downstream error that doesn’t surface until someone tries to use the data. Good integration work maps every field, documents the transformation rules, and tests with real data — not sample data — before going live.

Off-the-Shelf vs. Custom Integration

Zapier, Make, and similar tools handle a wide range of standard integrations well. If your workflow fits their templates, use them — they’re cheaper and faster to set up. Where they fall short is custom business logic: conditional routing, data transformation, error handling, or connecting tools that don’t have pre-built connectors. That’s where custom API work earns its cost. I cover this in more detail in the comparison of Zapier vs. custom automation.

Rate Limiting and Retry Logic

Every external API has rate limits — a ceiling on how many requests you can make per second, per minute, or per day. Hit that ceiling and your integration fails. Handling this correctly means building retry logic with exponential backoff: when a request fails due to rate limiting, wait, then retry with increasing delays before giving up and logging the failure. This is not glamorous engineering. It is also the difference between an integration that runs reliably for two years and one that starts mysteriously failing whenever transaction volume spikes. I build retry logic into every integration that touches an external system with rate limits.

What the Build Process Looks Like

Good integration work starts with mapping the data flow: what enters the system where, what needs to happen to it, and where it needs to land. That mapping exercise often reveals that the data model in one system doesn’t match the other — fields are named differently, data types differ, required fields on one end don’t exist on the other. Sorting that out before writing code saves time and avoids brittle integrations that break when either system updates.

I build integrations that handle errors gracefully: failed API calls get logged and retried, not silently dropped. I also document what was built so your team understands what’s running and can report accurately when something goes wrong. That documentation is not optional — an integration nobody understands is one that takes three times as long to debug six months later.

REST vs. GraphQL

Most APIs you’ll encounter are REST-based — requests to specific endpoints return specific data. GraphQL is an alternative where you send a query describing exactly what data you want and get precisely that back. GraphQL reduces over-fetching (getting more data than you need) and under-fetching (needing multiple requests to get what you need). For integration work, the practical difference is mainly in how you structure queries and handle errors. If the system you’re connecting to offers both, REST is usually easier to work with for straightforward data sync; GraphQL becomes worth it when you need fine-grained control over what data moves.

When Integration Becomes a Larger Software Project

Sometimes the integration project reveals that one of the systems being connected isn’t doing its job. If your CRM is wrong for how you sell, connecting it more tightly to everything else just automates bad data. In those cases the honest conversation is about replacing or rebuilding that system, not integrating it further. The broader software development page covers when a custom build makes more sense than wiring together tools that don’t fit.

Rates

Simple two-system integrations with standard APIs start around the lower end of custom software pricing. Complex multi-system integrations, middleware layers, or work involving legacy systems without documented APIs are scoped individually after a discovery call. Strategy consults are $500/hr if you want to think through the architecture before committing.

The right integration removes friction you’ve probably stopped noticing because you’ve worked around it so long. The software development overview is a good starting point if you want to understand how API work fits into a broader system design.