API Integration: Connecting Business Apps at Scale

Every business integration starts with an API

APIs are the connection points between business systems. If an application doesn't expose an API, it can't be integrated — at least not cleanly. You can scrape screens, parse email attachments, or export CSVs on a schedule, but those are workarounds, not integrations. Real integration means structured, programmatic access to another system's data and operations.

Most API discussions in the integration space boil down to three protocol families.

REST won. Virtually every SaaS application built after 2010 uses REST with JSON payloads. Shopify, HubSpot, Salesforce, Stripe, Amazon — all REST. The pattern is consistent: resources as URLs, HTTP verbs for operations, JSON for data. If you're integrating modern SaaS tools, you're working with REST APIs.

SOAP still exists in enterprise and legacy systems. NetSuite's older SuiteTalk SOAP API, SAP's web services, and many financial systems still expose SOAP endpoints with XML payloads, WSDL definitions, and envelope structures that feel like 2006. SOAP isn't inferior for all use cases — it has built-in support for transactions, security, and strict typing that REST lacks — but it's harder to work with, requires more tooling, and most developers today avoid it unless they have to.

GraphQL is growing in ecommerce. Shopify migrated to a GraphQL-first API strategy several years ago. It gives clients precise control over what data they retrieve, which reduces payload sizes and API call counts. For integration purposes, though, GraphQL adds complexity without much benefit over REST. You're not building a mobile app that needs to minimize network calls — you're syncing bulk data between systems. REST handles that just fine.

NetSuite is a useful case study because it exposes all three generations of API thinking. SuiteTalk SOAP is the legacy option. SuiteTalk REST is the modern default. SuiteQL lets you query NetSuite data with SQL-like syntax. RESTlets let you build custom API endpoints backed by SuiteScript. Each serves a different purpose, and most integrations end up using more than one. We covered the specifics in our NetSuite API guide for developers.

---

Custom API integration vs iPaaS

This is the foundational decision for any integration project. Build it yourself, or use a platform?

Custom API integration

Developers write code that calls API endpoints directly. Node.js, Python, .NET — pick your stack. A developer reads the API documentation, writes the authentication logic, builds the data mapping, handles errors, and deploys it to a server or serverless function.

What you get:

• Maximum flexibility. Any data transformation, any business logic, any edge case — you can code it.
• No licensing fees. You're paying for developer time and hosting.
• Exact behavior. No platform abstractions getting in the way.

What it costs you:

• Developer time runs $50-200/hour depending on seniority and location. A moderately complex integration (say, syncing orders between Shopify and NetSuite with inventory, customer, and fulfillment data) takes 200-400 hours to build properly. That's $10K-80K before you've synced a single record.
• Maintenance runs 20-30% of the original build cost per year. APIs change, edge cases surface, business requirements shift. Someone has to maintain this code.
• Single point of failure. If the developer who built it leaves, you now have custom code that nobody on your team understands. We've inherited integrations where the previous developer's approach was so idiosyncratic that rebuilding from scratch was cheaper than reverse-engineering the existing code.

iPaaS integration

A platform — Celigo, Boomi, Workato, MuleSoft — handles the API connectivity, data mapping, error handling, and monitoring. You configure integration flows through a visual interface. The platform vendor maintains the connectors and infrastructure.

What you get:

• Speed. An integration that takes months to build custom can deploy in weeks on an iPaaS platform. Pre-built connectors for common systems (Shopify, NetSuite, Salesforce) come with pre-mapped fields and standard business logic.
• Built-in monitoring, error queuing, alerting, and retry logic.
• Accessibility. Business analysts and NetSuite admins can manage flows without writing code.
• Vendor responsibility. When Shopify changes their API, Celigo updates their connector. That's their problem, not yours.

What it costs you:

• Licensing fees. Expect $20K-80K/year depending on platform, flow count, and data volume. Celigo runs $600-6,000/month for mid-market deployments. Boomi is similar. MuleSoft is significantly more.
• Less flexibility for unusual requirements. iPaaS platforms handle 80-90% of scenarios well. The remaining 10-20% can require awkward workarounds or custom scripting within the platform.
• Platform dependency. Migrating off an iPaaS platform costs 60-80% of the original implementation.

Making the call

For one or two simple integrations, custom code might be cheaper over a three-year window. A straightforward NetSuite-to-Shopify sync with limited data types could justify the custom approach if you have a developer on staff who'll maintain it.

For three or more integrations, or for complex multi-step data flows, iPaaS wins on total cost of ownership almost every time. The monitoring, error handling, and maintenance burden of multiple custom integrations compounds fast. By the time you're managing five custom integrations, you're spending more on maintenance than a platform license would cost — and getting worse visibility into what's working and what isn't.

---

API authentication patterns

Authentication is the first thing that breaks when you're wiring systems together, and every platform handles it differently. An integration connecting five systems might use four different authentication methods.

API Keys are the simplest approach. A static key passed as a header or query parameter. No token exchange, no refresh logic, no OAuth dance. API keys work well for server-to-server integrations where both endpoints are trusted and the risk of key exposure is managed. Many internal tools and smaller SaaS products use API keys.

The limitation: API keys don't expire automatically, can't be scoped to specific permissions easily, and if compromised, they're compromised until someone rotates them manually.

OAuth 2.0 is the industry standard for user-authorized API access. Salesforce, HubSpot, Google, and most modern SaaS platforms use OAuth 2.0. The flow involves obtaining an authorization code, exchanging it for access and refresh tokens, and using the access token for API calls. When the access token expires, the refresh token gets a new one.

OAuth 2.0 is more secure than API keys — tokens expire, permissions are scoped, and users can revoke access without changing credentials. The complexity is in the initial setup and in handling token refresh correctly. Integration platforms abstract this entirely, which is one of their underappreciated benefits.

Token-Based Authentication (TBA) is NetSuite's preferred method. You create an integration record in NetSuite, generate a consumer key/secret, then create tokens scoped to a specific user role. API requests are signed using all four values (consumer key, consumer secret, token ID, token secret). It's similar to OAuth 1.0 in structure.

TBA is reliable once configured but getting it right the first time trips up developers who haven't worked with NetSuite before. The token has to be mapped to a role with the correct permissions, and NetSuite's error messages when authentication fails are not particularly descriptive.

Certificate-based authentication shows up in some enterprise scenarios — banking APIs, government systems, EDI networks. More secure than token-based approaches but significantly more complex to configure and manage. Certificate expiration is a common source of integration outages.

iPaaS platforms abstract all of these methods behind a unified "connection" interface. You configure the auth once, and the platform handles token refresh, key management, and retry logic for authentication failures. For teams managing integrations across 5-10 systems, this abstraction alone justifies the platform cost.

---

SaaS integration patterns

How data moves between systems matters as much as what data moves. Different integration scenarios call for different patterns.

Request-response is the default. Your integration calls an API, sends or receives data, and processes the response. Synchronous and straightforward. A nightly script that pulls all new orders from Shopify and creates sales orders in NetSuite is request-response. It works, but it doesn't scale well for high volumes or time-sensitive data. Each API call blocks until it completes, and throughput is limited by the slowest endpoint.

Webhook-driven integrations flip the model. Instead of polling for changes, the source system pushes a notification when something happens. Shopify fires a webhook when an order is placed. Your integration receives it and acts immediately. Near-real-time, efficient on API calls, and no wasted requests checking for changes that haven't occurred.

The downside: webhooks can be dropped if the receiving endpoint is down, they arrive out of order under load, and not every system supports them for every event type. You need a reliable receiving infrastructure and often a queue to buffer incoming webhooks.

Polling checks for changes on a schedule — every 5 minutes, every hour, whatever the business requires. Less elegant than webhooks but universally reliable. If a system doesn't support webhooks (or doesn't support them for the event you need), polling is your fallback. Most iPaaS platforms default to polling with configurable intervals.

Batch/bulk processing handles large datasets on a schedule. Nightly inventory syncs. Daily financial extracts. Weekly customer data reconciliation. Batch integrations are appropriate when data freshness isn't critical and volume is high. Processing 50,000 inventory updates at 2 AM is more efficient than trickling them through one at a time throughout the day.

NetSuite's concurrency limits make batch processing a design consideration. You get roughly 10 concurrent API requests per account. A batch process that fires 500 parallel API calls will get throttled immediately.

Event streaming — Kafka, RabbitMQ, Amazon EventBridge — is enterprise-grade real-time data movement. Events are published to a stream, and multiple consumers can process them independently. Powerful, scalable, and complex to operate. For most mid-market companies doing $20M-$200M in revenue, event streaming is overengineered. You don't need Kafka to sync 500 orders a day between Shopify and NetSuite.

---

API governance and monitoring

Building an integration is the easy part. Keeping it running is where most teams underinvest.

Rate limiting is the first wall you'll hit. Every API imposes limits on how many requests you can make in a given time window. NetSuite allows roughly 10 concurrent requests per account. Salesforce enforces daily API call limits tied to your license tier. Shopify uses a leaky bucket algorithm that limits calls per second. Hit these limits and your integration stops — sometimes with a clear error, sometimes with a vague timeout.

Good integrations respect rate limits by design. They batch requests where possible, implement backoff logic when limits are approached, and schedule heavy operations during off-peak hours.

Error handling is non-negotiable. APIs fail. Network timeouts, invalid data, changed field requirements, expired tokens, rate limit hits, server errors on the remote end. Every failure mode needs a response: retry with exponential backoff for transient errors, queue for manual review for data validation failures, alert for authentication issues.

The difference between a fragile integration and a resilient one is almost entirely in how it handles failure. A custom integration that processes orders but crashes silently on a malformed address field will cause hours of investigation. An iPaaS flow that catches the error, queues the failed record, notifies the team, and continues processing the remaining orders keeps the business running.

API versioning catches teams off guard. APIs change. Fields get deprecated. Endpoints move. Response formats evolve. Shopify has deprecated multiple API versions over the past three years. NetSuite's REST API continues to add record types and change field behaviors between releases. You need a process for monitoring API changelogs and testing integrations against new versions before they become mandatory.

Logging is the diagnostic foundation. Every API call should be logged — timestamp, endpoint, request payload, response payload, response code, and execution time. When an integration breaks at 3 AM on a Saturday (and it will), you need the raw data to diagnose the problem. "Something failed" is not a useful error report. "POST to /services/rest/record/v1/salesOrder returned 400 with body {validationError: 'subsidiary is required'} at 03:14:22 UTC" is.

iPaaS platforms provide logging and monitoring out of the box. Custom integrations require you to build this infrastructure yourself — logging framework, storage, search capability, dashboards, alerting. It's not hard to build, but it's consistently underscoped in custom integration projects.

---

When to hire API integration services

Some integration projects are straightforward enough to handle internally. Connecting Zapier to send Slack notifications when a form is submitted doesn't require outside help.

But several scenarios push the complexity beyond what most internal teams can handle efficiently.

You don't have developers with API integration experience. General software development skills don't automatically translate to integration work. Integration developers need to understand authentication protocols, data transformation patterns, error handling strategies, and the quirks of specific APIs. A React developer can learn this, but the learning curve costs time and money.

The integration involves multi-step orchestration. If syncing an order requires creating a customer record (if it doesn't exist), checking inventory levels, applying pricing rules, creating the sales order, triggering fulfillment, and updating the source system with the order ID — that's orchestration. Each step depends on the previous one, failures at any point need to be handled gracefully, and the whole thing needs to be idempotent (running it twice shouldn't create duplicate records).

You need ongoing monitoring and maintenance. A one-time data migration is a project. An integration is an ongoing operational system. Someone needs to watch it, respond to errors, update it when APIs change, and scale it as volume grows. If that's not a role on your team, external support fills the gap.

You're connecting to NetSuite. NetSuite's API has characteristics that general API developers won't anticipate. Governance limits, SuiteScript execution contexts, saved search performance, custom record structures, subsidiary-specific behaviors — these are learned through experience, not documentation. A developer who's built 50 NetSuite integrations will deliver faster and more reliably than one building their first.

---

Here's how we've applied API integration strategy for a client managing CRM and ERP data flows.

Frequently Asked Questions

Frequently Asked Questions

What is an API integration service?expand_more

How much do API integration services cost?expand_more

What is the difference between REST and SOAP APIs?expand_more

How long does it take to build an API integration?expand_more

Do I need an iPaaS platform or can I build integrations with custom code?expand_more

API integration is a core part of what we do. Whether you're evaluating platforms, scoping a complex integration, or dealing with a custom build that's become a maintenance headache, we can help you sort through the options and build something that holds up.