REST API Examples in SaaS Product Integrations

More SaaS tools than ever, and fewer of them actually talk to each other. That tension drives every integration project right now, and REST APIs are what most engineering teams reach for to close the gap. This piece skips the theory and goes straight to what these connections look like once someone is actually writing the request.

Companies now run over 250 SaaS applications on average, up from around 200 just a couple years back, according to getknit.dev's State of SaaS Integration research. Yet Salesforce's own research puts the share of enterprise apps that stay unintegrated at 71%, a number that hasn't budged in three years. More tools, same disconnection, year after year. Deloitte's 2025 Technology Landscape Survey found 70% of CIOs plan to shift more of their IT budget toward integration work over the next two years, which confirms this stopped being optional a while ago. REST is the tool most teams reach for first, but knowing the spec tells you nothing about what Stripe or Salesforce actually expects in the request body, and that gap is where most integration work quietly goes wrong.

Why REST became the default integration layer

Somewhere between 80% and 90% of public APIs run on REST as of 2025, per techrt.com. That happened through accumulated adoption rather than any deliberate industry decision.

GraphQL has gained ground, growing from under 10% of organizations before 2021 to somewhere in the 30% to 35% range now. Shopify has been shifting certain coverage toward GraphQL on some endpoints, which signals that REST's dominance is eroding in specific areas, though it still holds across most of the ecosystem.

Over 90% of developers use APIs, and 69% work with third-party APIs specifically. The appeal is straightforward: stateless HTTP calls, JSON responses, and four verbs doing the bulk of the work (GET, POST, PUT, DELETE). The barrier to entry is low, tooling is widely available, and requests are readable without any special decoding. That combination is why large enterprises commonly running 50 or more APIs across internal systems, partner integrations, and public-facing products keep reaching for it.

What follows is a tour through five categories where those same REST building blocks produce very different implementations depending on what is being moved.

Salesforce REST API syncs CRM records

Salesforce's REST API runs on standard HTTP methods and returns JSON or XML. Most new integrations choose REST over SOAP because SOAP's overhead is difficult to justify for a new build in 2025. One caveat worth flagging early: if you are moving 50,000 or more records at once, the REST API becomes a bottleneck, and the Bulk API is the appropriate tool instead.

Three patterns appear repeatedly. A lead syncing to a marketing platform starts with the Streaming API: a PushTopic on the Lead object catches the change in real time, a REST call reads the full record, and that data is pushed to wherever marketing lives. Closed-Won deals follow the same approach: an Opportunity moves to Closed Won, REST retrieves the deal details, and the data lands in a billing system such as Zuora, QuickBooks, or NetSuite. Multi-org setups apply the same logic in reverse: an Account is created in the Sales org, a custom REST callout fires, and a matching Account appears in the Support org automatically.

Case syncing to support tools follows an identical structure. The Streaming API monitors the Case object, REST pushes the details to Zendesk or Intercom, and the support team no longer needs to export spreadsheets to stay current.

Underneath all of this sits a standard authentication layer and versioned endpoints that prevent breakage when Salesforce ships updates. Pairing an event-detection layer (Streaming API) with a separate record-retrieval call (REST) is a pattern that applies across CRM integrations broadly, not just with this vendor.

Stripe REST API manages subscription billing

Stripe handles over 250 million API requests a day and over 91 billion a year through a REST-based system that runs the billing infrastructure behind a large portion of the SaaS economy.

Slack is the frequently cited implementation example: working with Stripe, the team automated billing and payment collection across 15 countries in two weeks.

Two billing patterns appear frequently in SaaS products built on Stripe. Usage-based billing tracks consumption and feeds it into metered pricing that appears on the next invoice automatically, and this model suits products where consumption varies significantly between customers. Hybrid billing combines a fixed recurring charge with a consumption-based component, producing predictable base revenue with variable pricing on top.

Safe retry handling is required when money is involved, because a retried request that charges a customer twice creates refund costs and damages trust. Webhook events handle the asynchronous side, confirming after the fact whether a transaction actually completed. Stripe's key design contribution is that when the thing being transferred is money, idempotency and webhook-driven state management are foundational requirements built into the API from the start, not layered on afterward.

Shopify and WooCommerce sync inventory

Shopify's Admin API handles two jobs consistently. The first is CRM sync: customer profiles, purchase history, and lifetime value data flow to Salesforce, HubSpot, or Klaviyo, with webhooks keeping segments current in real time as purchases happen or carts are abandoned. The second is multi-channel inventory, keeping stock numbers consistent across Amazon, eBay, and physical point-of-sale systems, with webhook updates firing the moment inventory changes to prevent overselling.

One important caveat before building: Shopify has been shifting certain coverage toward GraphQL on some endpoints, so checking the changelog before assuming REST still covers a given endpoint is necessary. This is a live example of REST losing coverage on a major platform through actual deprecation notices.

WooCommerce operates differently. Its REST API covers orders, products, customers, and coupons, with authentication handled through a key-and-secret pair over HTTPS. The significant operational difference is that rate limiting behavior depends heavily on the merchant's hosting environment, which means mysterious timeouts may reflect infrastructure constraints rather than anything the API itself enforces.

The contrast between the two platforms is meaningful: Shopify provides a managed, versioned, hosted API with clear deprecation cycles, while WooCommerce delegates rate control entirely to the hosting provider. Both serve the same integration goal but carry different risk profiles, and selecting the wrong one for a high-volume client has a predictable outcome.

HubSpot REST API connects CRM to everything

HubSpot has been moving toward date-versioned APIs, replacing the older numeric path conventions. The versioning approach differs from Salesforce's in ways that cause confusion when engineers move between the two platforms without adjusting their assumptions.

Authentication divides into two paths, and selecting the wrong one early requires a rebuild later. One path covers internal integrations where no one outside the organization touches the connection. The other covers third-party integrations where an external application requires a user to grant access. Whether the integration is internal infrastructure or a published connector intended for other organizations' HubSpot accounts needs to be determined before any code is written, because retrofitting the authentication model after launch is not straightforward.

Several integration patterns appear consistently. HubSpot connected to Zendesk ties support tickets to HubSpot contacts and deals, giving sales visibility into open issues before renewal conversations. HubSpot connected to Shopify moves customer data, orders, abandoned carts, and product information into HubSpot so that e-commerce behavior feeds directly into CRM segmentation. A deal stage change triggering a webhook that posts a Slack message is a small pattern but appears frequently because it is inexpensive to build and produces immediate operational value. Form submissions routing to Zoho CRM or a Google Sheet represent REST handling its most common job: connecting marketing tools to wherever business operations actually run.

Custom HubSpot integrations frequently take longer than teams anticipate, and that reality should shape both budget and timeline from the start. The broader contribution HubSpot illustrates is data moving in multiple directions simultaneously, from CRM to support to e-commerce to internal communication tools, along with the reminder that the authentication model must be selected before any integration code is written.

Twilio REST API powers communications at scale

Twilio's design approach was to place a clean REST interface in front of the complexity of global carrier networks. The same HTTP verbs and JSON structures a developer uses to communicate with a CRM or payment processor work identically for SMS, voice calls, and identity verification.

Common production patterns include transactional messages triggered by application events, and verification flows where one REST call initiates a token and a second confirms it before access is granted. Inbound message handling is also standard, with incoming traffic routed to an application endpoint and the application's own logic determining what happens next.

What distinguishes Twilio from the other platforms covered here is that the request-response pattern runs in both directions by design: the application calls Twilio's endpoints, and Twilio calls the application's endpoints in return. Building only for outbound communication means the integration is structurally incomplete from the start.

Auth patterns repeat across every platform

Three authentication patterns appear regardless of which platform is involved. OAuth 2.0 covers Salesforce, HubSpot's third-party apps, and Shopify: token-based, scoped, and designed for situations where a user is delegating access to their own data. API keys and secret pairs appear in WooCommerce (consumer key plus secret), HubSpot's private apps, and Stripe's secret key in the Authorization header. These are simpler and appropriate for server-to-server connections where no user is granting permission. Bearer tokens are typically the output of an OAuth flow and travel in the Authorization header on every subsequent request.

The distinction that determines which approach applies: OAuth is about delegated authority, where a user grants an application access to their data, while API keys are about system identity, where a server proves it is authorized to call an API directly. Which one is correct depends entirely on whether a person needs to grant permission or whether two systems are communicating without user involvement. Building an OAuth flow for a machine-to-machine connection that only needed a key wastes time on consent screens that no user was ever going to see.

HTTPS is a prerequisite, not a recommendation. WooCommerce documents this explicitly (Basic auth only over HTTPS), which serves as a useful reminder that transport security must be in place before any credentials travel over the wire. Token expiry also requires explicit handling: Salesforce, HubSpot, and Shopify all require refresh token logic, and this is the kind of requirement that functions correctly in a local development environment and then fails silently weeks into production.

Webhooks outperform polling for event delivery

Polling means firing repeated GET requests on a timer to check whether something has changed. It is straightforward to implement but wasteful at any meaningful scale. Webhooks reverse the model: the platform POSTs to a specified endpoint the moment something changes, rather than waiting to be queried repeatedly.

Every platform covered here relies on this for its most important events. Salesforce's Streaming API fires on record changes, after which a REST call retrieves the full record. Stripe sends payment_intent.succeeded and invoice.payment_failed as asynchronous confirmation that a payment completed or failed. Shopify's inventory webhooks prevent products from being oversold across channels. HubSpot fires webhooks on deal stage changes to trigger downstream notifications, and Twilio POSTs inbound message data to the application endpoint the moment it arrives.

The underlying division of responsibility: REST handles the reads and writes an application initiates on its own schedule, while webhooks handle state changes the platform announces on its own schedule. Production integrations use both, and building only one half consistently surfaces as an incident report weeks after launch rather than a gap caught during design review.

Several practical problems appear regularly. Webhook endpoints must respond quickly, typically within a few seconds, or the platform begins retrying, and retries produce duplicate processing rapidly if the handler is not idempotent. Signature verification is required in production: Stripe, Shopify, and HubSpot all attach HMAC signatures to webhook payloads, and skipping validation creates unnecessary security exposure. Local testing typically requires a tool such as ngrok to expose an endpoint that webhook events can actually reach during development. Idempotency applies to both the outbound request side and the inbound webhook side without exception.

Production integrations fail at predictable points

Every example above points at the same failure mode in a different context. Salesforce illustrates what happens when event detection and record retrieval are treated as one step rather than two separate operations. Stripe illustrates what happens without idempotency keys: duplicate charges, customer complaints, and a support queue that is expensive to resolve. Shopify illustrates what happens when a team assumes REST endpoint parity without checking the changelog first. HubSpot illustrates the cost of selecting the wrong authentication model before writing any integration code. Twilio illustrates that a REST integration designed only for outbound calls is missing the inbound half of the architecture.

The teams that encounter these failures typically learn the happy path thoroughly and stop there, without working through the failure cases. Building for failure is more important than building for success: expired tokens, retried webhooks, deprecated endpoints, and rate limits enforced by infrastructure rather than the API itself are all predictable. Integrations that hold up in production are the ones where someone mapped out what happens when a request fails, not only what happens when everything works as documented.

For SaaS teams shipping this many integration patterns simultaneously, from CRM sync to billing logic to inventory updates, the challenge extends beyond building the connection. It also means ensuring the documentation explaining that connection is discoverable, by engineers searching the web and increasingly by the AI tools they are now using instead. Letterbrace, an AI-native content platform built for B2B SaaS, treats that kind of technical documentation as something measurable: whether ChatGPT or Claude cite it, alongside where it ranks in search, when a developer asks how to implement usage-based billing or authenticate against the Salesforce REST API.

REST became the default because enough engineers could adopt it quickly enough to make it universal: predictable, readable, and supported by tooling everywhere. That combination is exactly what integration work rewards, and a more sophisticated alternative mostly addresses a problem that the underlying work does not actually have.