How SIs & Agencies Use Declarative APIs for Faster Enterprise Integrations

The pattern is depressingly familiar. You just signed a six-figure enterprise contract. The buyer loves your core SaaS product, the technical evaluation went perfectly, the security review passed without a hitch, and procurement has signed off. There is just one catch: deployment is contingent on a custom, bi-directional integration with their heavily customized Salesforce instance, a legacy HRIS, or a deeply modified ERP like NetSuite.

Your internal engineering team is booked for the next two quarters building core product features. You have no appetite to drain their velocity, so you hand the project to a System Integrator (SI) partner or your internal professional services team. Eight months later, the integration is still in QA, the codebase is a tangled mess of edge cases, the customer is frustrated, and your revenue remains unrecognized.

This scenario is the quiet killer of enterprise SaaS growth. As we've noted in our breakdown of why enterprise integration projects fail, if your enterprise deals are stalling because the prospect needs a custom integration, the answer is rarely "hire more engineers." The problem is not a lack of engineering talent; it is the fundamental architecture used to build these connections.

When SIs rely on imperative, custom-coded scripts to connect disparate systems, they spend 80% of their time reinventing boilerplate infrastructure—authentication flows, pagination logic, and rate limit handling—instead of mapping business logic.

The faster path is to equip your professional services team or SI partner with a declarative unified API—an architecture where new connectors and custom field mappings ship as configuration data, not as freshly written, compiled, and deployed code. This shift turns a 12-week imperative coding project into a 1-2 week mapping exercise.

This guide is for senior PMs and professional services leaders who keep getting pulled into integration escalations. Building on our PM guide to integration solutions without custom code, it covers why custom enterprise integrations fail so often, the architectural difference between imperative and declarative integration platforms, and exactly how system integrators can use declarative unified APIs to deliver custom work faster without tripping over rigid schemas.

The Enterprise Integration Bottleneck: Why Deals Stall at the Finish Line

Enterprise software is never purchased in a vacuum. It is purchased to act as a node in a massive, interconnected graph of data. If your application cannot read and write to the buyer's existing systems of record reliably, the deal will stall—a reality reflected in recent data on how integrations close enterprise deals.

The macro picture explains why this is now standard. According to MuleSoft's Connectivity Benchmark, organizations now average 897 applications, but only 29% are integrated. The other 71% are data silos waiting for someone to bridge them. Companies with strong integration achieve 10.3x ROI from AI and automation initiatives versus 3.7x for those with poor connectivity. Buyers increasingly treat integration depth as a hard procurement gate, not a nice-to-have.

When a SaaS company moves upmarket, the standard integration playbook stops working. SMBs might accept a generic Zapier template or a basic webhook. Enterprise buyers require native, bi-directional syncs that respect their specific data governance rules, custom fields, and complex object relationships.

To bridge this gap, SaaS vendors typically turn to SIs. But the technical reality of this work is brutal. To build a custom connection, the SI must:

• Read poorly maintained third-party API documentation.
• Figure out how to securely store and refresh OAuth tokens without race conditions.
• Write custom logic to handle cursor-based pagination for one endpoint, link-header pagination for another, and offset-based pagination for a third.
• Build infrastructure to catch, normalize, and back off from HTTP 429 rate limit errors.
• Write imperative mapping scripts to translate the buyer's custom fields into the SaaS product's schema.

Every new enterprise customer requires a slightly different version of this code. The codebase quickly devolves into a sprawling mess of if (customer === 'AcmeCorp') statements. When the third-party API deprecates an endpoint, the SI has to rewrite and redeploy the code. This model does not scale to the long tail of enterprise customizations that buyers actually demand.

The High Cost of Custom Enterprise Integrations

Let's put numbers on it. Custom integration projects do not fail in subtle ways. They fail loudly, expensively, and predictably. The financial and temporal costs of the imperative approach are staggering.

1. Build Cost: Research from Monetizely indicates that mid-complexity to enterprise-wide integrations typically cost between $75,000 and $500,000+ to build. A complex enterprise platform with multi-tenant architecture and compliance requirements easily pushes toward the $1 million mark. A single complex integration to a system like NetSuite sits squarely in the mid-to-high end of that range when you factor in custom object mapping, edge case handling, and sandbox rework.

2. Specialist Labor Premium: A Forrester study found that the average mid-sized enterprise spends approximately $250,000 annually on SaaS customizations across their tech stack. Hiring an SI to write a custom Workday or Salesforce integration in imperative code (Python, TypeScript, Java) means relying on a rotating cast of platform specialists. Because of their domain knowledge, these specialists command 15-30% premium rates over general developers.

3. Maintenance is the Silent Killer: Custom modifications don't end at deployment. According to McKinsey, ongoing maintenance typically accounts for 15-25% of the initial custom development expense annually. A $200,000 integration becomes a $30,000 to $50,000 annual line item forever—and that is before any upstream vendor breaks their API or changes an authentication requirement.

4. Exceptionally High Failure Rates: In 2026, 70% of digital transformation and ERP implementation projects still fail to meet their objectives. A Gartner survey found only about 48% of projects fully meet or exceed their targets, and globally these failed efforts cost organizations an estimated $2.3 trillion per year. Integration complexity is consistently cited among the top three causes of those failures.

Now stack those numbers against your sales cycle. An enterprise SaaS sale takes 8 months to close on average. If your custom integration delivery is also 6-12 months, you have effectively doubled your time-to-revenue and dramatically increased the chance the deal evaporates before go-live. The math simply does not work, which is why it is critical to build integrations your B2B sales team actually asks for.

Declarative Integration Architecture vs Custom Code

To solve this, we have to look at how integrations are architected at the platform level. There is an architectural distinction that changes everything. There are two ways to build integration software:

The Imperative Approach (Strategy Pattern)

Most integration platforms—including legacy iPaaS solutions and code-first developer tools—use the strategy pattern.

In an imperative, strategy-pattern architecture, each integration is a separate module of code. If you want to connect to HubSpot, you write a HubSpotAdapter.ts file. If you want to connect to Salesforce, you write a SalesforceAdapter.ts file. Each file has its own auth handler, pagination logic, error parser, and field mapper.

While this organizes the code neatly, it forces every change—even a single custom field mapping for a single customer—through the same engineering bottleneck: write code, pull request, code review, CI/CD pipeline, deploy, and monitor. Adding integration #51 means writing file #51. Modifying integration #23 risks causing a regression in the other 50.

The Declarative Approach (Interpreter Pattern)

A declarative architecture takes a radically different approach. It uses the interpreter pattern at platform scale.

In a declarative system, the runtime engine is entirely generic. It contains zero integration-specific code. Integration behavior is defined entirely as data, not code. A new integration is simply a JSON configuration blob that describes the API's base URL, authentication scheme, endpoints, and pagination rules, paired with a set of mapping expressions describing how to translate between unified and native formats.

graph TD
    subgraph Imperative Architecture - Strategy Pattern
        A[Unified API Interface] --> B(HubSpotAdapter.ts)<br>Code
        A --> C(SalesforceAdapter.ts)<br>Code
        A --> D(NetSuiteAdapter.ts)<br>Code
    end

    subgraph Declarative Architecture - Interpreter Pattern
        E[Unified API Interface] --> F{Generic Execution Engine}<br>One Code Path
        F --> G[Integration Config]<br>JSON Data
        F --> H[Integration Mapping]<br>JSONata Data
        F --> I[Customer Overrides]<br>JSONata Data
    end

The key implementation detail in modern declarative platforms is the use of a transformation language like JSONata for field mapping. JSONata is a Turing-complete, functional query language purpose-built for reshaping JSON objects. A complete Salesforce-to-unified-CRM mapping lives as one expression in one database row. No compilation. No deployment. No engineering team in the loop.

The practical consequences for delivery speed are massive:

flowchart LR
    A[New customer<br>requirement] --> B{Imperative<br>or Declarative?}
    B -->|Imperative| C[Write code]
    C --> D[PR + Review]
    D --> E[Merge + CI]
    E --> F[Deploy]
    F --> G[Monitor]
    G --> H[Live: 2-12 weeks]
    B -->|Declarative| I[Edit JSONata<br>mapping]
    I --> J[Test in sandbox]
    J --> K[Save to DB]
    K --> L[Live: hours to days]

For an SI, this architectural shift changes the entire economics of an integration project. SIs are typically not staffed with senior backend engineers who can ship production-grade adapters in your core codebase. They are staffed with strong consultants who understand customer data models, can read API docs, and can write data transformation expressions. Declarative platforms put the work where the talent already is.

To see exactly how this works under the hood, read our deep dive on shipping API connectors as data-only operations.

How System Integrators Deliver Faster with Declarative Unified APIs

The primary advantage of a declarative unified API is that it isolates the complexity of the third-party system from the business logic of the integration. Here is exactly how system integrators and agencies can use this architecture to deliver custom enterprise integration projects faster.

1. Outsource the Infrastructure Plumbing

When an SI uses a declarative platform, they immediately eliminate the need to build authentication and pagination handling.

If the enterprise buyer needs to connect to a highly complex system like Oracle NetSuite, the SI does not need to learn the intricacies of NetSuite's Token-Based Authentication (TBA) or build a SOAP client. They do not have to debug an OAuth 2.0 refresh token race condition or translate link-header pagination into offset pagination.

They simply use the declarative configuration already defined in the platform. The execution engine handles the HTTP requests, applies the authentication, manages the pagination, and returns the raw data. This turns a multi-week infrastructure project into a five-minute configuration step. You can see how this applies to complex ERPs in our guide on architecting a reliable NetSuite API integration.

2. Standardize Rate Limit Handling

Every API handles rate limits differently. Some return HTTP 429, some return HTTP 403, and some return HTTP 200 with an error message in the body. Some use X-RateLimit-Reset headers, while others use Retry-After.

A declarative unified API normalizes this chaos. The platform evaluates the upstream API's response against a declarative configuration. If a rate limit is detected, it normalizes the response into a standard HTTP 429 and applies IETF-compliant headers:

• ratelimit-limit
• ratelimit-remaining
• ratelimit-reset

3. Transform Data with JSONata

Once the infrastructure is handled, the SI focuses on the 20% that actually matters to the enterprise buyer: mapping the data.

In an imperative model, this requires writing fragile JavaScript or Python scripts that break whenever a field name changes. In a declarative model, SIs use JSONata to define complex transformations—including conditionals, string manipulation, date formatting, and array transforms—as pure data strings.

Here is an example of a JSONata expression mapping a complex, nested Salesforce Contact object into a clean, unified CRM schema:

response.{
  "id": Id,
  "first_name": FirstName,
  "last_name": LastName,
  "name": $join($removeEmptyItems([FirstName, LastName]), " "),
  "email_addresses": [{ "email": Email, "is_primary": true }],
  "phone_numbers": $filter([
    { "number": Phone, "type": "phone" },
    { "number": MobilePhone, "type": "mobile" }
  ], function($v) { $boolean($v.number) }),
  "custom_fields": {
    "acme_account_tier": Account_Tier__c,
    "acme_renewal_date": Renewal_Date__c
  },
  "created_at": CreatedDate,
  "updated_at": LastModifiedDate
}

Because this transformation is stored as a string in the database rather than hardcoded in a deployed script, the SI can update, version, and hot-swap mappings instantly without requiring a code deployment or server restart. For a deeper walkthrough, see our JSONata mapping examples for API integration.

4. Utilize the Proxy API for Edge Cases

Unified APIs are incredible for standard resources like CRM Contacts or HRIS Employees. But enterprise deals often involve highly specific, proprietary objects that do not fit into a standard unified schema.

Many first-generation unified API providers force SIs into a rigid, lowest-common-denominator schema. If the endpoint is not supported by the unified model, the SI is blocked.

A well-architected declarative platform provides an escape hatch: a Proxy API (or passthrough API). The Proxy API allows the SI to make authenticated pass-through requests directly to the third-party API, utilizing the platform's authentication and rate-limit normalization, without forcing the data through a unified schema. If the enterprise buyer has a custom Fleet_Vehicle__c object in Salesforce, or requires a custom Workday RaaS report, the SI simply calls the Proxy API. They get the exact data they need instantly.

5. Define Custom Resources for the Long Tail

When a customer's instance has objects that do not exist in any standard unified model, declarative platforms let SIs define those resources as configuration too. They can add new endpoints, schemas, and mappings directly into the platform's execution engine without touching the source code, bringing full unified API capabilities to entirely bespoke customer workflows.

Handling Custom Objects with a 3-Level Override Hierarchy

The single most painful part of enterprise integration delivery is custom field handling. No two enterprise Salesforce instances look the same. Every NetSuite instance has tens of custom records added over a decade.

If an SI is using a traditional integration platform, they must fork their codebase for every customer to handle these unique custom fields. This destroys scalability and makes maintenance a nightmare. First-generation unified APIs solve this by surfacing a generic custom_fields blob, which falls apart the moment a customer wants their custom "Lead Score" field surfaced as a first-class property in your product.

Declarative architectures solve this through a 3-Level Override Hierarchy that allows SIs to customize API mappings at different scopes without touching the underlying source code.

When a request is made, the execution engine deep-merges these configurations.

If an enterprise buyer requires their proprietary Lead_Score__c field to be mapped to the priority field in your SaaS product, the SI simply applies a Level 3 JSONata override to that specific account's configuration:

{
  "priority": response.Lead_Score__c > 80 ? "High" : "Standard"
}

The base mapping remains intact for all other customers. The SI workflow is radically simplified:

flowchart TD
    A[Discovery call:<br>map custom fields] --> B[Write JSONata<br>response_mapping override]
    B --> C[Apply at account level<br>via API or UI]
    C --> D[Test against<br>customer sandbox]
    D --> E{Works?}
    E -->|Yes| F[Promote to production]
    E -->|No| G[Iterate on mapping<br>no redeploy needed]
    G --> D

Notice what is missing: no code commit, no pull request, no deploy, no migration. Each override is just a row in a database. The iteration loop is measured in minutes, not days. We cover this pattern in depth in our piece on 3-level API mapping overrides without code and why unified data models break on custom Salesforce objects.

Equipping Your Professional Services Team for Scale

If you are a product manager or engineering leader trying to decide how to staff this work, the calculus is straightforward:

1. Hire a small pro-serv team and arm them with a declarative platform. Two or three configuration-savvy consultants can deliver more custom integration work, faster, than five backend engineers writing imperative adapters. They do not need to be senior engineers—they need to be strong at reading API docs, writing transformation expressions, and talking to customer admins.

2. Partner with SIs for surge capacity. Established SI firms already have consultants who know NetSuite, Workday, and Salesforce intimately. Bringing them onto a declarative platform means they can apply that domain knowledge directly to mapping work, instead of getting blocked on your platform's coding conventions.

3. Keep your core engineering team out of customer-specific integration work entirely. Their job is the platform and the product, not customer #47's custom Salesforce field. The whole point of the declarative model is that the engineering team builds capabilities once (auth, pagination, rate limits, error normalization) and the pro-serv team applies those capabilities to specific customer cases endlessly.

The platforms that genuinely support this model share a few characteristics: zero integration-specific code in the runtime engine, a transformation language powerful enough to handle real enterprise edge cases (like JSONata), per-account override hierarchies, and a passthrough proxy layer for the genuinely irreducible long tail. If your current vendor cannot demonstrate all four, your delivery teams will hit a wall the first time a customer asks for something interesting.

Where to Take This Next

Enterprise integration delivery does not have to be a multi-month slog that burns engineering cycles and delays revenue recognition.

The delays and failures associated with custom integrations are symptoms of using the wrong architectural approach. Writing imperative scripts to handle OAuth flows, pagination cursors, and rate limits is a solved problem. Your SIs and professional services teams should not be billing hours to reinvent it.

The declarative model is not a magic bullet. JSONata has a learning curve. Customers will still demand things that do not fit any unified model, and you will still need a passthrough escape hatch. But what changes is the unit economics. Custom enterprise integration delivery moves from a specialized engineering project to a productized consulting engagement.

By equipping your delivery teams with a declarative unified API, you shift their focus entirely to business logic and data mapping. This is how you turn integration delivery from a deal-blocking liability into a predictable, scalable operational motion.