Truto vs Hotglue: Declarative JSON vs Code-First Python for B2B Integrations

You are a startup product leader or engineering director staring at a pipeline of lost deals. The pattern is obvious: prospects evaluate your product, love the core feature set, and then ask, "Do you integrate with Salesforce, Workday, or NetSuite?" You reply that it is on the roadmap. By the time your engineering team ships the connector, the prospect has signed with a competitor.

If you're evaluating Truto vs Hotglue for embedded B2B integrations, the short version is this: Hotglue is a code-first embedded ETL platform built on Python where you write transformation scripts for each integration. Truto is a unified API platform where every integration is defined entirely as declarative JSON configuration and JSONata expressions - no integration-specific code at all. They solve overlapping problems from fundamentally different architectural layers, and the right choice hinges on whether your team wants code-level control over data pipelines or zero-code normalization across entire SaaS categories.

This guide breaks down the technical tradeoffs between imperative code and declarative configurations, the maintenance implications each approach carries at scale, and where each platform's tradeoffs will impact your engineering velocity.

Why Integration Architecture Matters More Than Feature Lists

Before comparing two specific platforms, it helps to understand the stakes. The pressure to ship integrations is a mathematical reality for modern software companies.

Organizations now use an average of 106 different SaaS tools, according to BetterCloud's 2026 State of SaaS report. Every one of those tools is a potential integration point your customers demand you support. 60% of all SaaS sales cycles now involve integration discussions, and for 84% of customers, integrations are either very important or a dealbreaker, per the 2025 State of SaaS Integrations Report by Partner Fleet. In fact, the ability to support the integration process is the number one sales-related factor in driving a software decision, based on analysis of Gartner's 2024 Global Software Buying Trends data.

The retention benefits are equally stark. 98% of companies report customers with integrations are less likely to churn. If your product does not connect to the tools your customers already use, you will bleed deals and churn accounts.

So the question isn't whether to invest in integrations. It's which architecture lets a small engineering team cover the most ground without drowning in maintenance. When evaluating infrastructure to solve this, engineering teams often narrow the field to two distinct approaches: Hotglue and Truto.

The Architectural Divide: Python Scripts vs. Declarative Configs

The core philosophical difference between Hotglue and Truto is imperative vs. declarative - and this distinction cascades into everything: how fast you ship new integrations, how much you maintain, how you customize per-customer, and what happens when an upstream API changes.

Hotglue positions itself as an embedded integration platform for developers, operating largely as a specialized ETL (Extract, Transform, Load) pipeline. It is embeddable, code-first, and built on the Python ecosystem. When you need to pull contacts from a CRM or push invoices to an accounting system, you write a Python script. Hotglue provides the infrastructure to run that script, handle the OAuth token lifecycle, and manage the sync schedules.

Truto takes a radically different approach. Truto is a unified API platform with a zero-code architecture. The entire platform - including the proxy layer, the unified API engine, sync jobs, and webhook processing - contains absolutely zero integration-specific code. There are no Python scripts, no if (provider === 'hubspot') statements, and no custom endpoint handlers. Instead, integration behavior is defined entirely as data. Truto uses a generic execution engine that reads declarative JSON configurations to understand how to talk to an API, and JSONata expressions to translate between the third-party schema and Truto's unified schema.

Here is the simplest way to visualize the architectural difference:

graph TD
    subgraph "Hotglue (Imperative Python)"
        A[Sync Trigger] --> B[HubSpot Python Script]
        A --> C[Salesforce Python Script]
        B --> D[Custom API Logic & Pagination]
        C --> E[Custom API Logic & Pagination]
        D --> F[Database / Destination]
        E --> F
    end

    subgraph "Truto (Declarative JSON)"
        G[Unified Request] --> H[Generic Execution Engine]
        H --> I[(Integration Configs <br> JSON & JSONata)]
        I -.->|Reads mapping| H
        H --> J[Standardized HTTP Request]
        J --> K[Unified Response]
    end

Hotglue's Code-First Python Approach: Flexibility with a Maintenance Cost

Engineers often gravitate toward Hotglue initially because Python is comfortable. Writing a script to fetch data from an API feels like standard backend development. You have total control over the execution flow, the data transformation, and the specific quirks of the endpoint.

Hotglue enables developers to leverage the Python ecosystem to compose transformation scripts, combining the power of Python modules like Pandas and Dask in a JupyterLab-powered workspace. It provides over 600 open-source connectors and natively supports all Singer spec and Airbyte YAML connectors.

How it works in practice: You configure the OAuth credentials in the Hotglue UI. Then, Hotglue's connectors extract raw data from a third-party API. That data lands in a staging area where your Python script transforms it - renaming fields, filtering rows, joining across data sources, applying business logic. The transformed data is then loaded into your target destination.

This is a real strength for certain use cases. If you need to correlate QuickBooks invoices with Salesforce opportunities and match them programmatically, Hotglue was designed to correlate data across third-party systems, and this type of behavior is possible because its integrations are stateful - developers have access to a full picture of a user's data through snapshots.

The Hidden Technical Debt

The tradeoff? Every integration carries a code artifact. The problem with the code-first approach is not the first integration. It is the fiftieth.

When you write Python scripts for every integration, you are building a linear scaling problem for your engineering team. Every new integration requires new code. Every API deprecation requires a code change, a pull request, a code review, and a deployment.

Consider the realities of maintaining 50 different Python scripts for 50 different REST APIs:

• Pagination drift: HubSpot uses cursor-based pagination with an after parameter. Salesforce uses a nextRecordsUrl. Workday uses offset pagination. In a Python-scripted environment, your engineers must manually implement these pagination loops in every script. If an engineer introduces an off-by-one error in the Pipedrive script, it does not affect the Zoho script, making bugs harder to track and fix systematically.
• Error handling inconsistencies: Third-party APIs are notorious for returning non-standard error structures. If you are writing Python scripts, your team has to manually parse and normalize these errors within each script to ensure your application can react predictably.
• The deployment bottleneck: If a third-party API changes a field name from firstName to first_name, updating a Python script requires going through your standard CI/CD pipeline.

Hotglue's focus on data synchronization and ETL means it offers fewer advanced workflow automation features compared to full-featured iPaaS platforms. While Hotglue gives you the flexibility of a Turing-complete programming language, it forces you to own the maintenance burden of that code forever. At 10 integrations, this is manageable (though as we've noted in our breakdown of models for product integrations, teams often hit a breaking point around 10-15). At 50, you have a small integration engineering team doing nothing but script maintenance.

Truto's Zero-Code Architecture: JSONata and Declarative Mappings

Truto eliminates integration-specific code entirely. To understand how this works, we have to look at the architecture of the generic execution engine.

Instead of giving developers a runtime to execute their code, Truto provides a generic execution engine that reads declarative configuration and executes it. When a unified API request comes in - say, GET /unified/crm/contacts for a HubSpot account - the engine executes a single, uniform code path:

1. Loads the HubSpot integration config (a JSON blob describing the API's base URL, endpoints, auth scheme, pagination strategy).
2. Loads the CRM contacts mapping (JSONata expressions that translate between HubSpot's native format and the unified schema).
3. Transforms the request using the query/body mapping expressions.
4. Makes the HTTP call using values from the config.
5. Transforms the response using the response mapping expression.
6. Returns normalized data.

The same code path handles Salesforce, Pipedrive, Zoho, and every other CRM. Because pagination is declarative, the generic engine handles the loops automatically. If an integration uses cursor pagination, the config simply states { "format": "cursor", "config": { "cursor_field": "paging.next.after" } }. The engine reads this and pages through the API without a single line of custom code.

The JSONata Mapping Layer

To translate data between the unified schema and the target API's native format, Truto uses JSONata - a lightweight, functional query and transformation language purpose-built for JSON.

Instead of writing a Python script to map Salesforce fields to your unified model, you store a JSONata expression in the database.

Example: HubSpot Response Mapping (JSONata)

response_mapping: >-
  (
    {
      "id": response.id.$string(),
      "first_name": response.properties.firstname,
      "last_name": response.properties.lastname,
      "email_addresses": [
        response.properties.email ? { "email": response.properties.email, "is_primary": true }
      ]
    }
  )

Example: Complex CRM Contact Mapping (JSONata)

response_mapping: >-
  response.{
    "id": Id.$string(),
    "first_name": FirstName,
    "last_name": LastName,
    "email_addresses": [{ "email": Email }],
    "phone_numbers": $filter([
      { "number": Phone, "type": "phone" },
      { "number": MobilePhone, "type": "mobile" }
    ], function($v) { $v.number }),
    "created_at": CreatedDate,
    "updated_at": LastModifiedDate
  }

This is a single JSONata expression. It handles field renaming, type coercion, nested object construction, and conditional filtering. It's stored as data. No compilation, no deployment, no CI/CD pipeline. Change the expression, and the behavior changes immediately, enabling hot-swappable API integrations without code deploys.

Why Declarative Wins at Scale

When adding a new integration is a data operation rather than a code operation, your velocity skyrockets. If you need to fix a bug in how a specific field is mapped, you update the JSONata expression in the database. Furthermore, because all integrations flow through the exact same generic execution engine, an improvement to the core proxy layer - such as a more resilient retry mechanism for network timeouts - instantly benefits all 100+ integrations simultaneously.

The tradeoff here is real too: JSONata is powerful, but it's not Python. If your integration requires complex stateful orchestration across multiple API calls with intermediate persistence, a declarative mapping layer is more constrained than a full scripting runtime. Truto handles multi-step orchestration through before and after step configurations, but there are edge cases where a general-purpose language gives you more room.

Handling API Edge Cases: Rate Limits, Auth Failures, and Custom Fields

The true test of an integration platform is not how it handles a standard GET /contacts request. It is how it handles the painful edge cases of enterprise software: custom objects, complex filtering, aggressive rate limits, and auth token failures.

Transparent Rate Limit Normalization

A common misconception about embedded iPaaS and unified APIs is that they magically absorb API rate limits. If an upstream API only allows 10 requests per second, no middleware platform can force it to accept 100. Platforms that attempt to queue, throttle, or silently backoff requests often introduce opaque latency, causing your application to hang unpredictably while the middleware waits out a penalty window.

Truto takes a radically transparent approach to handling API rate limits. Truto does not automatically retry, throttle, or apply backoff on rate limit errors. When an upstream API returns an HTTP 429 (Too Many Requests), Truto passes that 429 error directly back to the caller immediately.

However, Truto normalizes the chaotic landscape of upstream rate limit headers into the standardized IETF RateLimit specification. Every response from Truto includes consistent headers regardless of the underlying provider:

• ratelimit-limit: The maximum number of requests permitted in the current window.
• ratelimit-remaining: The number of requests remaining in the current window.
• ratelimit-reset: The number of seconds until the rate limit window resets.

Why this matters: By passing the 429 error and standardized headers back to your application, your engineering team retains total control over the retry strategy. Your background workers or AI agents can read the ratelimit-reset header, pause execution for the exact required duration, and resume. This predictable, deterministic behavior is essential for building resilient distributed systems.

In contrast, Hotglue's ETL jobs run on a schedule. Rate limiting is primarily handled at the connector level - Singer and Airbyte connectors typically have their own built-in backoff logic. This is fine for batch ETL workloads where you can afford to wait, but it means rate limit handling is scattered across hundreds of open-source connector implementations with varying quality.

Authentication Lifecycle Management

Truto proactively manages OAuth token refreshes. The platform schedules token refresh ahead of expiry (with a buffer window), and if refresh fails, the connected account is flagged as needing re-authentication and a webhook event fires. All credential fields are encrypted at rest, and the system supports five auth types natively.

Hotglue handles authentication through its connector layer. Users securely authenticate and connect their integrations with prebuilt components. But because connectors are open-source Singer/Airbyte taps, the auth lifecycle management depends heavily on the connector's implementation quality.

Taming Custom Fields and Objects

Enterprise customers heavily customize their CRMs and ERPs. A standard unified API schema will inevitably miss the custom_billing_tier__c field your largest customer relies on—a common issue with rigid unified API schemas.

In a Python-scripted environment like Hotglue, supporting a customer's custom fields usually means branching your script. You end up writing logic that says, "If customer ID is 123, fetch these extra fields and append them to the payload." For one customer, that's trivial. For 50 customers, you're maintaining complex branching logic or parameterized scripts.

Truto handles this elegantly through its declarative architecture. Because custom fields are mapped via JSONata, the engine can dynamically sift through API responses and extract custom data based on pattern matching.

For example, to extract all Salesforce custom fields (which end in __c), the base JSONata mapping simply includes:

"custom_fields": $sift($, function($v, $k) { $k ~> /__c$/i and $boolean($v) })

This single line of configuration automatically captures any custom field a customer has created, without requiring you to write custom code for their specific Salesforce instance.

Customization at Scale: The Override Hierarchy vs. Forked Scripts

Here's a scenario every B2B SaaS company hits eventually: Customer A uses Salesforce with standard fields. Customer B uses Salesforce with 20 custom fields and a non-standard data model. Customer C uses Salesforce with a completely custom object they've built. All three expect your integration to "just work."

Truto's Three-Level Override System

Truto solves this through a declarative override hierarchy that allows per-customer customization without touching source code:

Because mappings are just JSON data, Truto can deep-merge these configurations at runtime, with later levels taking precedence.

If Customer B requires their HubSpot industry field to be mapped to a specific format, you simply attach an account-level JSONata override to their specific integrated_account record. When Customer B makes a request, Truto merges their specific mapping on top of the base mapping. Customer B gets their bespoke behavior. Customers A and C are unaffected. Your engineering team did not have to write, review, or deploy a single line of code.

Hotglue's Approach to Per-Customer Customization

Hotglue allows users to customize how data is mapped, or control mappings on their behalf using code. In practice, this means you can fork a transform script per tenant or add conditional logic based on tenant context.

This works, but it creates a fork management problem as you scale. If you have 10 variants of a Salesforce transform script across 10 customers, and Salesforce deprecates an API version, you need to update all 10 scripts. The overhead is linear with the number of customizations.

Unified API vs. Embedded ETL: Different Problems, Different Strengths

It's worth being precise about what each platform actually is, because the labels matter for your architecture.

Hotglue is an embedded ETL platform. Its architecture and feature set are optimized specifically for B2B SaaS vendors building customer-facing integrations. Its sweet spot is batch data ingestion: pulling data from a customer's SaaS tools, transforming it, and loading it into your system on a schedule. If your primary need is "sync all of Customer X's QuickBooks invoices into our database every hour," Hotglue is purpose-built for that.

Truto is a unified API. Its sweet spot is real-time, normalized CRUD access across entire SaaS categories. If your primary need is "let me read and write CRM contacts across Salesforce, HubSpot, Pipedrive, and 20 other CRMs through one API call with one schema," that's what Truto is built for. It also supports batch sync through its sync job engine, webhooks, and auto-generated MCP tool definitions for AI agent integrations.

The overlap is in data normalization - both platforms let you get data from third-party APIs into a consistent format. But they approach it from opposite ends:

Which Embedded Integration Platform Should You Choose in 2026?

The choice between Truto and Hotglue comes down to a fundamental question: Who is responsible for the integration logic, and how much technical debt are you willing to carry?

Choose Hotglue if:

• Your primary use case is batch data ingestion (ETL) rather than real-time API access.
• You have a dedicated data engineering team that prefers writing, testing, and maintaining Python scripts.
• You are integrating with a small number of platforms (under 15) and can absorb per-integration script maintenance.
• You need to correlate data across multiple sources with complex stateful logic before loading it into your system.
• You want Python-level control over data transformation with a white-label, embeddable integration UI.

Choose Truto if:

• Your engineering team needs to ship normalized CRUD access across entire software categories (CRM, HRIS, ATS, Ticketing, Accounting) rapidly.
• You want to eliminate the maintenance burden of writing integration-specific code and avoid linear maintenance cost growth.
• You need predictable, deterministic API behavior with transparent rate limit handling (IETF standard headers).
• You require the ability to customize mappings for individual enterprise customers without deploying new code or branching logic via an override hierarchy.
• You are building AI agent workflows and need auto-generated MCP tool definitions.
• You are evaluating embedded iPaaS vs unified API architecture and want an architecture that scales linearly.

Neither platform is a magic bullet. Hotglue gives you the full power of Python but asks you to maintain code for every integration. Truto eliminates integration-specific code but constrains you to what's expressible in JSONata and declarative configuration.

Integrations are no longer a feature request; they are the baseline requirement for entering the B2B market. For most B2B SaaS teams scaling their integration catalog in 2026, the maintenance cost question will dominate - and that's where the declarative approach has a structural advantage. By adopting a declarative, zero-code architecture, you can stop building API connectors and get back to building your core product.