---
title: Unified APIs That Don't Force Standardized Data Models
slug: unified-apis-that-dont-force-standardized-data-models
date: 2026-07-02
author: Roopendra Talekar
categories: [Engineering, General]
excerpt: "Why rigid common data models fail on Salesforce custom objects, and how declarative mapping architectures solve enterprise SaaS integrations without custom code."
tldr: "Traditional unified APIs drop custom objects, forcing developers to use passthrough endpoints. Modern architectures use JSONata and multi-level overrides to map custom fields dynamically without code."
canonical: https://truto.one/blog/unified-apis-that-dont-force-standardized-data-models/
---

# Unified APIs That Don't Force Standardized Data Models


Your integration infrastructure just cost you a six-figure enterprise deal.

The technical evaluation was flawless. The demo went perfectly. The buyer's RevOps team was excited to move forward. Then their Salesforce administrator sent over the schema for their organization: 147 custom fields on the Contact object, a highly modified `Deal_Registration__c` object with nested relationships that drives their entire partner pipeline, and a `Revenue_Forecast__c` rollup field that powers their quarterly board decks.

Your unified API provider's common data model flattened all of it into `first_name`, `last_name`, and `email`. It completely dropped the custom objects. To get the data your application actually needed, your engineering team was forced to bypass the unified schema entirely and write raw Salesforce SOQL against a passthrough endpoint. You were back to reading vendor documentation, managing provider-specific authentication quirks, handling custom pagination, and maintaining custom code for a single tenant. The abstraction you paid for just evaporated, and the deal died in technical review.

If you are evaluating integration infrastructure for the enterprise market, you are likely looking for a **unified API that doesn't use standardized data models for custom objects**. Traditional unified APIs force data into a rigid, lowest-common-denominator schema. Modern unified API architectures solve this by replacing rigid schemas with a declarative mapping architecture that translates per-tenant schema variations dynamically, requiring zero integration-specific code.

This guide breaks down exactly why rigid schemas fail in the enterprise, the architectural flaws of both the "passthrough" and "code-first" alternatives, and how to architect an integration layer that adapts to infinite schema variations using functional transformation languages and multi-level override hierarchies.

## The Enterprise Reality of Custom Objects and Fields

Custom fields are not edge cases. They are the default state of every enterprise SaaS deployment.

When building B2B software, you quickly learn that no two enterprise companies operate the exact same way. A logistics company uses their CRM to track freight manifests and driver schedules. A healthcare software provider uses the same CRM to track patient intake forms and clinical trial statuses. A financial services firm tracks assets under management and compliance review dates.

To accommodate these wildly different business models, platforms like Salesforce, HubSpot, and NetSuite are designed as highly flexible relational databases. According to Salesforce's own technical documentation, the Salesforce Enterprise Edition allows organizations to create up to 200 custom objects and 500 custom fields per object. The Unlimited Edition allows up to 2,000 custom objects. 

Whenever a user creates a custom field or object in Salesforce, the system automatically appends `__c` at the end of the identifier. This suffix is required when writing SOQL queries or using API integrations, as it ensures the system correctly identifies custom fields versus standard objects. 

When a mid-market or enterprise customer connects their CRM to your SaaS product, they expect your software to understand their specific business context. If your product only syncs standard fields like name and email, while ignoring the `Freight_Manifest__c` or `Patient_Record__c` objects that actually drive their revenue, your product is fundamentally useless to them.

This creates a massive engineering bottleneck. If you want to move upmarket, you have to support custom fields. But if you rely on [rigid data models that break on custom Salesforce objects](https://truto.one/why-unified-api-data-models-break-on-custom-salesforce-objects-and-how-to-fix-it/), your engineering team will spend all their time writing custom integration logic instead of building your core product.

## The Limitations of the Common Data Model (CDM)

The first generation of unified APIs attempted to solve the integration problem by introducing the Common Data Model (CDM). The premise was simple: take the schemas of 50 different CRMs, find the overlapping standard fields, and create a single, unified schema that maps to all of them.

In theory, this allows developers to write code against one schema and instantly support dozens of platforms. In practice, this architectural approach fails spectacularly in B2B environments.

Unified APIs provide an abstraction layer that assumes a large degree of overlap between vendors, which inherently struggles with entirely custom objects created by users in CRMs like Salesforce. As noted in industry research by Kloudless, the lowest-common-denominator approach means that any data field that does not fit neatly into the predefined common model is simply discarded during the normalization process.

This is a fundamental flaw in how CDMs are architected. Enterprise data models attempt to force a single integrated definition of data, but without specific context (like a tenant's unique business process), these models break down and fail to capture reality, as highlighted by Feststelltaste's analysis of enterprise data modeling.

When a unified API encounters a Salesforce instance with 150 custom fields, the underlying code typically looks something like this:

```typescript
// Traditional Unified API mapping logic (Code-First Strategy Pattern)
function mapSalesforceContact(rawResponse) {
  return {
    id: rawResponse.Id,
    first_name: rawResponse.FirstName,
    last_name: rawResponse.LastName,
    email: rawResponse.Email
    // All 150 custom __c fields are silently dropped here
  };
}
```

The abstraction forces the data into a rigid shape. Because the unified API provider hardcodes these mapping functions in their own backend, you have no ability to modify them. You cannot tell the unified API to map `Deal_Registration__c` to your application's internal schema because the unified API's schema is immutable.

When you complain to the unified API provider that your enterprise customer's data is missing, they will inevitably point you toward their "passthrough" endpoint.

## Why Passthrough Endpoints Are a Trap

Passthrough endpoints are the integration industry's escape hatch for failed abstractions. When the common data model cannot handle a [custom field or object](https://truto.one/how-do-unified-apis-handle-custom-fields-2026-architecture-guide/), the provider allows you to send raw, unmapped HTTP requests directly to the underlying third-party API through their proxy layer.

Falling back to passthrough endpoints defeats the entire purpose of buying a unified API.

When developers are forced to use passthrough APIs to access custom objects, they have to write native API queries (like SOQL), manage provider-specific quirks, and handle raw rate limits themselves, as documented by Hotglue's analysis of CRM integrations. 

If you have to use a passthrough endpoint, you are immediately exposed to the following engineering burdens:

**1. You are writing vendor-specific code again.**
You must read the Salesforce API documentation, learn how to construct a SOQL query, and write a specific code path in your application just for Salesforce. If your next customer uses HubSpot custom objects, you have to write a completely different code path using HubSpot's specific search syntax. The unification is gone.

**2. You lose standardized pagination.**
Every API paginates differently. Salesforce uses a `nextRecordsUrl`. HubSpot uses cursor-based pagination inside a `paging.next.after` object. When you use a passthrough endpoint, you are receiving the raw, unmapped response. Your engineering team must write custom pagination handlers for every single API you interact with.

**3. You are exposed to raw rate limits.**
Rate limiting is one of the most complex aspects of API integration. When you hit a passthrough endpoint, you are directly exposed to the underlying API's rate limit headers. Every provider uses different header formats (`X-RateLimit-Remaining`, `RateLimit-Remaining`, `Retry-After`). 

*Note on rate limits:* A properly architected integration platform should normalize this chaos without hiding the reality of the network. For example, when an upstream API returns an HTTP 429 (Too Many Requests), Truto does not swallow the error or apply hidden backoff logic. It passes that error directly to the caller, but it normalizes the upstream rate limit information into standardized headers (`ratelimit-limit`, `ratelimit-remaining`, `ratelimit-reset`) following the IETF specification. The caller is responsible for implementing retry and exponential backoff logic, but they can do so using a single, standardized set of headers instead of parsing fifty different provider formats.

Relying on passthrough endpoints for custom objects means your codebase will quickly become littered with provider-specific `if/else` statements, completely negating the ROI of purchasing an integration platform.

## The Code-First Alternative Doesn't Scale

Recognizing the limitations of rigid data models and passthrough endpoints, another category of integration tools emerged: embedded iPaaS and code-first developer platforms.

These platforms argue that because B2B SaaS companies eventually outgrow pre-built unified APIs due to custom fields, the solution is to give developers a platform where they can write their own integration scripts. Instead of providing a unified schema, they provide a managed execution environment where your engineers write custom JavaScript or TypeScript to map data between your app and the third-party API.

While this solves the flexibility problem, it creates a massive scalability problem.

Architecturally, code-first platforms rely on the **Strategy Pattern**. Each integration is a separate module or class that implements a common interface. This means that for every integration you want to support, your engineering team must write, test, deploy, and maintain custom code.

If you want to integrate with 30 different CRMs, you have to write 30 different mapping scripts. When an enterprise customer requests support for their specific custom objects, your engineers have to open the codebase, add conditional logic for that specific tenant, and deploy a new version of the integration script.

```typescript
// The maintenance nightmare of code-first integrations
export async function syncContacts(provider, tenantId) {
  if (provider === 'salesforce') {
    if (tenantId === 'enterprise_corp_123') {
      // Custom SOQL for specific tenant
      return executeQuery('SELECT Id, FirstName, Freight_Manifest__c FROM Contact');
    }
    return executeQuery('SELECT Id, FirstName FROM Contact');
  } else if (provider === 'hubspot') {
    // Completely different logic and syntax
  }
}
```

This approach creates linear technical debt. The maintenance burden grows in direct proportion to the number of integrations and the number of enterprise customers you onboard. When third-party APIs introduce breaking changes, your engineering team has to manually update and test dozens of custom scripts. You are effectively building an internal systems integration agency rather than a scalable software product.

## Architecting a Unified API Without Standardized Data Models

To solve the custom object problem without forcing developers to write custom code or rely on passthrough endpoints, you need a fundamental shift in architecture. You must move away from rigid, hardcoded schemas and adopt a **declarative mapping architecture**.

In this architecture, integration behavior is defined entirely as data - JSON configuration blobs and functional expressions - rather than executable code. The runtime engine is a generic pipeline that reads this configuration and executes it without any awareness of which specific integration it is running.

### JSONata as a Universal Transformation Language

Instead of writing TypeScript to map fields, modern integration architectures use JSONata, a functional query and transformation language purpose-built for reshaping JSON objects. JSONata is declarative, Turing-complete, and stores logic as pure string data rather than compiled code.

This allows a unified API to handle incredibly complex custom field logic dynamically. For example, to handle an enterprise customer's Salesforce instance where you need to extract every custom field ending in `__c`, the JSONata expression simply looks like this:

```yaml
response_mapping: >-
  response.{
    "id": Id,
    "first_name": FirstName,
    "last_name": LastName,
    "custom_fields": $sift($, function($v, $k) { $k ~> /__c$/i and $boolean($v) })
  }
```

This single expression dynamically captures an infinite number of custom fields without requiring a single line of integration-specific code in the backend engine. The unified API engine simply evaluates the string against the incoming payload and returns the normalized result.

### The 3-Level Override Hierarchy

To truly support enterprise schema variations without code, a declarative mapping architecture must support a multi-level override hierarchy. This allows mapping rules to be modified at different scopes without affecting the global system.

Truto implements this through a [3-level API mapping hierarchy](https://truto.one/3-level-api-mapping-per-customer-data-model-overrides-without-code/):

```mermaid
flowchart TD
  A["Level 1: Platform Base<br>(Default JSONata mapping)"] --> D
  B["Level 2: Environment Override<br>(Your SaaS application's custom schema)"] --> D
  C["Level 3: Account Override<br>(Individual enterprise tenant's schema)"] --> D["Deep Merged Mapping Configuration"]
  D --> E["Generic Execution Engine"]
  E --> F["Third-Party API"]
```

**Level 1 - Platform Base:** The default mapping provided by the platform that works for 80% of standard use cases.

**Level 2 - Environment Override:** Your engineering team can override the base mapping across your entire application. If your product requires a specific custom object from Salesforce, you define a JSONata override at the environment level. The platform merges this override with the base mapping at runtime.

**Level 3 - Account Override:** This is where enterprise deals are won. If a single enterprise customer has a highly modified Salesforce instance, you can apply a JSONata override specifically to their connected account record. When that specific tenant makes an API request, the engine applies their unique mapping rules, extracting their `Revenue_Forecast__c` field without affecting any of your other customers.

This means a customer can add their own custom fields to the unified response, change how filtering works for their specific setup, and route requests to custom object endpoints - all through configuration data, without a single code deployment.

### Zero Integration-Specific Code

The ultimate benefit of a declarative mapping architecture is the elimination of integration-specific code. 

When adding a new integration is a data operation (uploading a JSON config and JSONata expressions) rather than a code operation, the platform becomes infinitely extensible. The same generic execution engine that handles a HubSpot CRM contact listing also handles Salesforce, Pipedrive, and every other CRM using the exact same code path.

Bugs get fixed once and every integration benefits. When the generic engine's pagination logic is improved, all 100+ integrations get the improvement simultaneously. The maintenance burden is decoupled from the number of integrations supported.

## Evaluating Integration Infrastructure for the Enterprise

When procurement and product teams evaluate integration vendors for enterprise deployments, the conversation must move beyond "Do you support Salesforce?" to "How do you handle infinite schema variations?"

Use this architectural checklist during your technical evaluations:

1.  **The Custom Object Test:** Ask the vendor to map a nested custom object to a unified schema during the demo. If they open an IDE to write JavaScript, or if they point you to a passthrough endpoint where you have to write SOQL, they fail the test.
2.  **The Tenant Override Test:** Ask how you can support a custom field for Customer A without exposing that field to Customer B. If the vendor requires you to maintain separate code branches or deploy separate integration scripts per tenant, the maintenance overhead will crush your engineering team.
3.  **The Rate Limit Test:** Ask how HTTP 429 errors are handled. If the vendor claims to magically absorb all rate limits, they are likely hiding critical network failures. If they force you to parse raw provider-specific headers via passthrough endpoints, they are pushing the work back onto you. Look for transparent error passing with standardized IETF headers.
4.  **The Pagination Test:** Verify that custom objects and fields can be queried using standardized pagination cursors, rather than forcing you to handle native provider pagination logic.

Enterprise SaaS requires flexibility. Your integration infrastructure must adapt to the reality of highly customized CRMs, HRIS platforms, and ticketing systems without forcing your engineers to write custom code for every new deal.

## Next Steps

Rigid common data models kill enterprise deals by dropping the custom objects that matter most to your buyers. Passthrough endpoints and code-first platforms solve the flexibility problem but introduce massive technical debt and maintenance overhead.

By adopting a declarative mapping architecture powered by JSONata and a multi-level override hierarchy, you can support infinite schema variations dynamically - delivering deep, enterprise-grade integrations with zero integration-specific code.

> Stop losing enterprise deals to rigid data models. See how Truto's declarative mapping architecture handles infinite custom objects with zero integration-specific code.
>
> [Talk to us](https://cal.com/truto/partner-with-truto)