How to Publish a Connector Coverage Matrix & Supported Objects

If your SaaS integration page is just a grid of 50 provider logos, you are actively losing enterprise deals. When a mid-market or enterprise buyer evaluates your software, they do not just want to know if you connect to Salesforce. If they cannot tell—within five seconds—whether you support bidirectional sync for Custom Objects, read specific standard fields, or listen to real-time webhooks without exhausting API quotas, they assume your integration is shallow and move on to a competitor.

Buyers do their research before they ever speak to your sales team. To stop your account executives from constantly fielding the question, "Does it sync custom fields?" on discovery calls, you must publish a connector coverage matrix and explicitly list supported objects per provider. This is not just a documentation task for technical writers. It is a structured, public document that allows enterprise buyers, security reviewers, and AI agent builders to self-qualify before a sales call, making it a core product marketing and revenue-generating motion.

This guide breaks down exactly how product managers should design, document, and publish a connector coverage matrix that holds up under enterprise scrutiny, highlights the difference between integration breadth and depth, and explains how modern architectural patterns make maintaining this documentation effortless.

What a Unified API With Real-Time Data Fetching Looks Like

If you are evaluating an integration platform for your enterprise SaaS product, you will encounter the term "unified API" everywhere. Here is what it means in concrete, operational terms - and why it directly shapes how you should document your connectors.

A unified API provides a single, normalized interface for a category of third-party APIs - CRM, HRIS, ATS, Accounting - abstracting away differences in authentication, pagination, schemas, and rate limits. Instead of learning HubSpot's nested properties objects, Salesforce's SOQL query syntax, and Pipedrive's entirely different field names, your engineering team makes one call:

GET /unified/crm/contacts?integrated_account_id=abc123&limit=10

The response comes back in a normalized schema - same field names, same structure - regardless of whether the connected account is HubSpot, Salesforce, or any other CRM. The original provider response is always preserved in a remote_data field, so your application never loses access to provider-specific data.

This matters for coverage documentation because every object and operation your unified API supports is inherently documented by the schema itself. If your platform is built on declarative configuration rather than hardcoded adapters, the coverage matrix becomes a direct reflection of what the runtime actually does.

Real-Time Data: Webhooks, Polling, and What to Document

Enterprise SaaS products that need up-to-the-minute data cannot rely on polling APIs every 15 minutes. Real-time event delivery is a hard requirement for workflows like syncing new hires into payroll, updating deal stages in a dashboard, or triggering alerts when a support ticket escalates.

Unified API platforms generally support three event-delivery models:

• Native webhooks - the source system pushes events immediately when supported (e.g., HubSpot's contact.propertyChange, Stripe's invoice.paid)
• Virtual webhooks - the platform polls the source API on a short interval, detects changes, and emits webhook-style events for providers that lack native webhook support
• Sync-based notifications - a scheduled sync runs, and the platform notifies your app that data may have changed

When a unified webhook system normalizes provider-specific events into canonical types like record:created or record:updated, your application subscribes to one event format and handles updates from every provider through the same code path. No separate parsers for each provider's payload structure.

In your coverage matrix, explicitly state which model each connector supports per object. A row that says "Webhooks: native (contact.creation, contact.propertyChange)" tells the architect far more than "real-time sync supported."

Why You Must Publish a Connector Coverage Matrix

A connector coverage matrix is a public, per-provider table that documents which objects, operations (read/write/delete), custom field types, and event triggers your product supports for each integration. It acts as the technical resume of your integration portfolio.

Enterprise software ecosystems are sprawling, and the revenue argument for documenting them is sharp. The average enterprise now manages 897 applications across departments (up from 843 in 2023, a 6.4% year-over-year increase), yet only 29% of those applications are integrated, according to MuleSoft's 2025 Connectivity Benchmark Report. This creates an ever-expanding web of disconnected tools, and procurement teams are aggressively trying to consolidate workflows.

During assessment, buyers are primarily concerned with a software provider's ability to provide integration support (44%) and their willingness to collaborate (42%), according to Gartner's 2024 Global Software Buying Trends report. Integration capabilities have shifted from a "nice-to-have" to a strict pass/fail requirement. Buyers are not asking whether you integrate. They are asking exactly how deeply you integrate with the core systems they already run.

A coverage matrix answers that question without a sales call. It also serves three operational purposes:

• Reduces inbound support tickets: Customers stop asking "does it sync custom fields?" because the documentation already answers it.
• Pre-qualifies enterprise deals: Security and architecture teams audit your matrix to ensure their specific data models are supported before booking a demo.
• Forces internal discipline: You cannot publish a matrix you haven't actually built. The exercise itself surfaces architectural gaps.

If you do not explicitly document what your API integration coverage matrix includes, technical buyers will assume the worst. You will be cut from the vendor shortlist before your sales reps even know there was an active deal.

The Difference Between Integration Breadth and Depth

When building an integration strategy, product teams often obsess over breadth: hitting the arbitrary milestone of "100+ integrations" to look competitive with a massive logo wall. But enterprise buyers buy on depth.

Mid-market companies moving upmarket to enterprise establish software vendor selection criteria based heavily on scalability and integration capabilities. They need to know the plumbing actually works for their specific workflows.

Breadth is Marketing. Depth is Revenue.

Breadth means you support OAuth for 50 CRMs. Depth means you document supported objects in API integrations, detailing exactly which endpoints you interact with, which operations are supported (Read, Write, Update, Delete), and how you handle pagination, rate limits, and custom fields.

Here is the distinction in operational terms:

Consider the difference in how these two approaches communicate value:

• Shallow Documentation: "We integrate with Jira to keep your engineering team in sync."
• Deep Documentation: "Our Jira connector supports bidirectional sync for Epics, Issues, and Sprints. We support full CRUD operations on all standard Jira fields, automatically discover and map your Jira Custom Fields, and utilize Jira webhooks for real-time state updates with a maximum latency of 3 seconds."

Only the second statement gives a solutions architect the confidence to sign off on a purchase.

A depth-first matrix forces you to name your trade-offs. If you only support read on QuickBooks Invoices but read+write on Bills, say so. Hiding these gaps does not protect the deal—it just shifts the discovery to a procurement call where the cost of saying "we don't support that" is much higher.

graph TD
    A[Buyer Evaluates Integrations] --> B{Is there a Coverage Matrix?}
    B -- No --> C["Assumes Shallow Integration<br>Drops Vendor"]
    B -- Yes --> D[Reviews Supported Objects]
    D --> E{Supports Custom Fields?}
    E -- No --> F[Fails Technical Review]
    E -- Yes --> G["Passes Architecture Review<br>Moves to Procurement"]

How to Document Supported Objects per Provider

To build a highly effective connector coverage matrix, you need a standardized framework that applies to every third-party provider your platform supports. A usable coverage matrix has five required columns per object, and three optional ones that move enterprise deals.

1. Required columns

1. Object name - the unified name in your product (e.g., Contact, Invoice, Employee).
2. Provider-native name - what it maps to in the upstream API (e.g., HubSpot contacts, Salesforce Contact, Pipedrive persons).
3. Supported operations - explicit read, create, update, delete. Don't use vague terms like "sync."
4. Custom field support - one of none, read-only, read-write, or via passthrough.
5. Real-time signal - webhook, polling interval, or none.

2. Optional but high-impact columns

6. Pagination behavior - cursor, offset, page-token. Matters for bulk ingest planning.
7. Rate limit ceiling - tenant-level requests/minute the provider allows.
8. Known edge cases - e.g., "Pipedrive Deals: stage transitions emit two events instead of one."

Here is what one row looks like in practice for a CRM connector:

provider: hubspot
object: contact
native_name: contacts
operations: [read, create, update, delete]
custom_fields: read-write
real_time: webhook (contact.creation, contact.propertyChange)
pagination: cursor (after parameter)
rate_limit: 100 req/10s per OAuth app
edge_cases:
  - hs_additional_emails returns semicolon-delimited string, not array
  - associations require separate API call unless requested via ?associations=

That block is worth more than any marketing copy. It tells the buyer's architect: yes, this works, and here is how it behaves under stress.

3. A Standard Taxonomy for Operations (CRUD)

For every provider, list the distinct resources your integration interacts with. Use a tight vocabulary so customers can grep the matrix programmatically:

• R - read (list + get)
• W - write (create + update)
• D - delete
• S - search (provider-side filtering)
• WH - webhook events available
• CF - custom fields supported
• CO - custom objects supported

For a simpler, highly readable marketing view, use a matrix format:

Sample Unified API Responses: Normalized Data With Raw Provider Payload

The most effective coverage documentation includes concrete API response examples. Enterprise architects evaluating your platform want to see what the data actually looks like - not just a list of supported fields.

Here is what a unified CRM contact response looks like when the connected account is Salesforce. The result array contains objects with consistent, normalized field names. The remote_data field on each object preserves the unmodified provider API response.

Request:

GET /unified/crm/contacts?integrated_account_id=sf_account_01&limit=1

Response:

{
  "result": [
    {
      "id": "501",
      "first_name": "Jane",
      "last_name": "Rodriguez",
      "name": "Jane Rodriguez",
      "email_addresses": [
        { "email": "jane@acme.com", "is_primary": true }
      ],
      "phone_numbers": [
        { "number": "+1-555-0199", "type": "phone" },
        { "number": "+1-555-0200", "type": "mobile" }
      ],
      "account": { "id": "802" },
      "custom_fields": {
        "Lead_Score__c": 87,
        "Preferred_Language__c": "Spanish"
      },
      "created_at": "2025-03-10T08:45:00Z",
      "updated_at": "2026-01-15T14:22:00Z",
      "remote_data": {
        "Id": "003ABC123DEF",
        "FirstName": "Jane",
        "LastName": "Rodriguez",
        "Email": "jane@acme.com",
        "Phone": "+1-555-0199",
        "MobilePhone": "+1-555-0200",
        "AccountId": "001XYZ789",
        "Lead_Score__c": 87,
        "Preferred_Language__c": "Spanish",
        "CreatedDate": "2025-03-10T08:45:00.000+0000",
        "LastModifiedDate": "2026-01-15T14:22:00.000+0000"
      }
    }
  ],
  "next_cursor": "eyJsYXN0SWQiOiI1MDEifQ==",
  "result_count": 1
}

The same request against a HubSpot account returns an identical normalized structure, but the remote_data contains HubSpot's native format - nested properties, different field names, different date formats. Your application code works with the normalized fields and never needs to branch on which provider is behind the account.

Notice that custom_fields contains the Salesforce custom fields (identifiable by the __c suffix). The remote_data object is the unmodified Salesforce API response. This dual-payload pattern lets your application work with clean, normalized data by default while retaining full access to provider-specific fields when needed.

Publishing a sample response like this in your per-connector documentation tells the architect exactly three things: what normalized fields are available, how custom fields surface, and that the raw provider data is always accessible. That is worth more than a page of feature descriptions.

4. Custom Fields and Custom Objects

This is the most heavily scrutinized section by enterprise buyers. Every mature enterprise heavily customizes their CRM, HRIS, or ERP. If your integration only supports default fields, it is functionally useless to them.

Explicitly document how your platform handles custom data. Do you automatically discover custom fields? Do users need to manually map them in a UI? Do you support custom objects entirely, or just custom fields on standard objects? Document whether unified fields preserve type fidelity (date, picklist, multi-select) or coerce to string.

Read more on How Do Unified APIs Handle Custom Fields?.

Per-Customer Mapping Overrides for Enterprise Instances

Large enterprises do not just add a few custom fields. A Salesforce instance at a 10,000-person company often has hundreds of custom fields, renamed standard fields, and custom objects that drive core business processes. A one-size-fits-all mapping breaks down fast.

If your integration platform supports per-customer mapping overrides, document that capability explicitly in your matrix. Truto, for example, supports a three-level override hierarchy that handles this directly:

1. Platform default - The base mapping that works for standard instances. Defines how unified field names map to provider-native fields for the general case.
2. Environment override - A customer's environment can modify response field mappings, query translations, or default parameters without affecting other customers. These overrides are stored separately and deep-merged at runtime.
3. Account override - Individual connected accounts carry their own mapping adjustments. If one customer's Salesforce instance uses Primary_Contact_Email__c instead of the standard Email field, only that account's mapping changes.

Each level is merged on top of the previous at request time, so overrides only need to specify what differs from the default. This means a coverage matrix can state "full custom field support with per-customer mapping overrides" - and the statement is architecturally backed, not aspirational.

When documenting this for buyers, add a row or footnote to your matrix indicating which customization levels are available:

This transparency directly addresses the enterprise buyer's top concern: "Will this work with our Salesforce, not just a demo instance?"

5. Visualizing the Data Model per Provider

For enterprise providers (Salesforce, NetSuite, Workday), publish a small ER diagram showing which objects you support and how they relate. Buyers' solution architects review these in minutes.

flowchart LR
    A[Contact<br>R/W/CF] --> B[Account<br>R/W]
    A --> C[Opportunity<br>R/W/WH]
    C --> D[OpportunityLineItem<br>R only]
    C --> E[Product2<br>R only]
    B --> F[Custom Objects<br>passthrough only]

A diagram like this answers more architecture questions than ten paragraphs of prose.

6. Webhooks, Rate Limits, and Error Handling

Polling APIs every 5 minutes is expensive and often violates upstream rate limits. Buyers want to know if your integration is event-driven. Document which objects support real-time webhooks.

Enterprise security teams will also ask how your integration behaves when the upstream provider goes down or when API quotas are exceeded.

SaaS Integration Directory Best Practices

The matrix is the content. The directory is the UI that lets buyers find it. Creating the data for your coverage matrix is only half the battle. How you present it dictates whether buyers actually find it.

Many companies bury their supported objects deep inside a developer portal that requires a login. This defeats the purpose. Your integration directory must serve both the non-technical buyer (marketing site) and the technical evaluator (documentation site).

1. Unify the Marketing and Technical Views

Your marketing integrations page should feature the standard grid of logos, categorized by vertical. When a user clicks on a specific provider, they should land on a dedicated page that serves both audiences. The top half of the page should explain the business value of the integration. The bottom half should embed the technical connector coverage matrix.

Read more on How to Build a High-Converting SaaS Integrations Page.

2. Make Every Connector a Dedicated URL

/integrations/salesforce should exist as its own indexable page, not a modal or anchor tag. Sales engineers link to these in RFP responses. SEO ranks them for " [your product] Salesforce integration."

3. Make it Searchable and Filterable

A buyer evaluating you for HR tooling does not want to scroll past 40 CRMs. Implement faceted filters—by category, by data direction (inbound, outbound, bidirectional), and by specific supported objects. A buyer should be able to filter by "Integrations that support bidirectional Contact sync and Webhooks."

4. Publish a Machine-Readable Connector Catalog

Beyond a human-browsable directory, enterprise buyers and AI agent builders increasingly expect structured, machine-readable metadata about your connectors. This means exposing your connector capabilities as JSON - not just rendering them as HTML.

A connector catalog endpoint should return per-provider metadata including supported objects, operations, authentication methods, and rate limit information:

{
  "connector": "salesforce",
  "category": "crm",
  "supported_objects": [
    {
      "unified_name": "contacts",
      "native_name": "Contact",
      "operations": ["read", "create", "update", "delete"],
      "custom_fields": "read-write",
      "webhooks": ["record:created", "record:updated", "record:deleted"],
      "scopes_required": ["api", "refresh_token"]
    },
    {
      "unified_name": "deals",
      "native_name": "Opportunity",
      "operations": ["read", "create", "update"],
      "custom_fields": "read-write",
      "webhooks": ["record:created", "record:updated"],
      "scopes_required": ["api", "refresh_token"]
    }
  ],
  "auth_methods": ["oauth2"],
  "pagination": "cursor",
  "rate_limit_notes": "Per-user limits enforced by Salesforce edition",
  "last_updated": "2026-05-15"
}

When your integration platform stores connectors as declarative configuration, this catalog can be auto-generated from the same data that powers runtime behavior. No manual sync between your documentation and your actual capabilities.

Expose this catalog at a stable URL (e.g., /api/v1/connectors or /integrations.json) and link to it from your integrations page. Sales engineers paste it into RFP responses. AI agents consume it to determine which tools are available. Security teams parse it during vendor assessments.

5. Link Directly to Provider API Docs and Live Status

Build trust by linking your supported objects directly to the third-party provider's API documentation. If you say you support the HubSpot Deals object, hyperlink that text to HubSpot's actual API reference. Additionally, if your connector is currently degraded, say so. Live status next to the matrix builds enormous trust.

6. Version Your Documentation

Coverage changes. A last_updated timestamp on each row signals you actively maintain the page rather than treating it as a one-time marketing artifact.

A Worked Example: Coverage Matrix for Accounting Unified APIs

Accounting is the category where coverage documentation matters most. Finance and RevOps teams evaluating a unified API for accounting software - QuickBooks Online, QuickBooks Desktop, Xero, NetSuite, Sage Intacct, or Zoho Books - are not looking at logos. They need to confirm that Invoices, Journal Entries, Payments, Contacts, Items, and Tax Rates behave predictably across every ledger their customer base runs.

This section applies the coverage matrix framework to accounting integration platforms as a concrete worked example. If you sell a product that touches financial data - AP automation, spend management, revenue recognition, close software - the following tables are the minimum you should be publishing per provider.

Connector Coverage Matrix (Per-Vendor Entity Support)

The unified accounting data model spans a common set of top-level entities: Invoices, Payments, Journal Entries, Contacts (customers and vendors), Items, Tax Rates, Accounts (chart of accounts), Expenses, Purchase Orders, Vendor Credits, Tracking Categories, and Transactions. Not every provider exposes every entity, and where they do, operation parity varies.

Here is what a per-vendor entity matrix looks like for the accounting category:

R = read (list + get), W = create/update. Blank cells indicate the provider does not expose the entity through its API. Actual capabilities vary by edition (QuickBooks Simple Start vs Advanced, NetSuite standard vs OneWorld, Xero Cashbook vs Standard) - always confirm against a real customer connection during validation, not the vendor's marketing page.

Write vs Read Parity: What's Fully Supported

Read coverage across accounting providers is broad. Write coverage is where things fall apart, and it is the single most common source of surprises in enterprise deals.

A few patterns hold across the category:

• Reads are near-universal for standard entities. Every mainstream accounting provider exposes list and get operations for invoices, payments, contacts, and journal entries. Coverage gaps here usually mean the provider itself doesn't model the concept.
• Writes are gated by provider policy. QuickBooks Online enforces strict validation on JournalEntry creation - debits must equal credits down to the cent, and every line must reference a posting account. Xero requires Manual Journals for direct GL posting and treats posted invoices as immutable (void and reissue is the only correction path). NetSuite writes always go through the REST record API even though reads are built on SuiteQL.
• Delete is rare. Most accounting providers soft-delete or void rather than hard-delete, for audit compliance. Document this explicitly - buyers assume "delete" removes the record.
• Attachments and PDF rendering are inconsistent. NetSuite requires a deployed script to render a Purchase Order PDF because the REST API has no rendering capability. QuickBooks Online supports PDF download natively. Xero exposes attachments as a separate endpoint per record type.
• Custom field write parity is edition-gated. QuickBooks Online caps custom field slots by plan tier. NetSuite exposes custom fields per form, so the same custom field may be writable through one form and hidden through another.

For an accounting unified API, write/read parity should be documented per entity, not per provider. A single "supports Xero" claim tells a finance leader nothing. "Supports read and write on Invoices, Bills, Payments, and Manual Journals; read-only on Bank Transactions and Reports" tells them everything.

Provider-Specific Caveats and Workarounds

Every accounting provider has quirks that will bite you in production. A useful matrix includes a one-line caveat column per provider so buyers can self-assess fit before booking a demo.

QuickBooks Online

• Company editions differ (Simple Start, Essentials, Plus, Advanced). Some entities and custom field slots are gated by edition; detect the edition at connection time and store it as a context flag.
• JournalEntry API rejects entries where debits don't balance credits exactly, including sub-cent rounding. Enforce balance validation in your unified layer before dispatching the write.
• Sandbox company data structure diverges from production. Test destructive operations on real customer instances before shipping features.

QuickBooks Desktop (QBD)

• No cloud API. Integration requires the Intuit Web Connector (SOAP-based polling) or a third-party sync bridge. There is no path to true real-time updates.
• Entity coverage is significantly narrower than QuickBooks Online - many objects available in QBO are not exposed at all in QBD. Document the gap explicitly rather than implying parity.
• Recommended workaround: run scheduled syncs on a fixed cadence (typically 5-15 minutes) and expose last_synced_at to your users so freshness is transparent.

Xero

• Rate limits are strict: 60 requests per minute and 5,000 per day per tenant, with a daily app-wide cap on uncertified apps. Bulk backfills need queue-and-throttle logic with exponential backoff.
• Posted invoices are immutable. To "update" a posted invoice, void it and issue a linked credit note or replacement invoice.
• Manual Journals are the only way to post directly to the general ledger; there is no generic journal-entry write endpoint.

NetSuite

• Custom schema drift is the biggest operational risk. Every customer's NetSuite instance can carry hundreds of custom fields, custom record types, and per-form field configurations. A static mapping will not survive contact with real enterprise instances.
• Multi-subsidiary (OneWorld) versus single-subsidiary editions require different query shapes. Detect the edition at connection time and construct SuiteQL queries accordingly.
• Tax rate detail is not fully exposed through SuiteQL. The legacy SOAP API is required for complete tax records. Surface this fallback in your matrix so security reviewers understand why a SOAP call exists in an otherwise REST-based integration.
• Recommended workaround: support per-account field mapping overrides so each customer's specific NetSuite customizations can be aligned with the unified schema without code changes.

Sage Intacct

• Authentication is session-based with short-lived sessions. Your integration must transparently refresh sessions on 401 responses.
• Permissions are enforced per user, per entity, per action. A connection authorized to list invoices may not be authorized to create them; validate write access explicitly at connection time rather than at first write.

Zoho Books

• Data is scoped per organization within a Zoho account. Customers with multiple books need an organization selector during connection setup.
• Regional editions (US, India, UAE, EU, and others) have different tax models and field sets. Detect the region at connection time and select the appropriate mapping variant.

How to Validate Coverage for Your Use Case

Publishing a matrix is only useful if buyers can validate it against their actual instance. The most effective accounting integration platforms expose a lightweight validation flow that runs against a real connected account and reports which entities and operations are actually reachable.

At minimum, a validation flow should:

1. Execute a probe request per critical entity. For an accounting connector, that typically means calling GET /unified/accounting/accounts, GET /unified/accounting/company_info, and GET /unified/accounting/contacts and confirming a 200 response. If any of these fail, flag the connection as degraded before the customer notices.
2. Detect edition and feature flags. Multi-currency, multi-subsidiary, and multi-entity toggles change query shapes and mapping behavior. Store these as context flags on the connection so runtime behavior adapts automatically.
3. Enumerate custom fields and objects. Query the provider's metadata endpoint (or introspect a sample record) and cache the custom field catalog per connection. This is what makes "full custom field support" a real claim instead of an aspirational one.
4. Expose a /meta endpoint per resource. For every unified accounting resource, publish the exact schema, required fields, and supported operations for the connected account. Buyers' architects hit this endpoint during evaluation and RFP responses.
5. Test write operations in a sandbox. For providers with sandboxes (QuickBooks Online, Xero, NetSuite), run a create-read-delete cycle on a test invoice as part of the validation harness. Write parity claims that aren't tested will fail in production the first time a customer tries to post a real journal entry.

If you sell an accounting-adjacent product - AP automation, spend management, expense reporting, revenue recognition, financial close - your buyers will run some version of this validation whether or not you provide it. Building it into your platform, and publishing the results in your coverage matrix, turns a diligence obstacle into a differentiator.

How Truto Simplifies Integration Coverage Documentation

The operational problem with maintaining a coverage matrix is that the source of truth keeps moving. HubSpot adds a property type. Salesforce deprecates an endpoint. Maintaining a connector coverage matrix manually is a nightmare if your underlying integration architecture is built on hardcoded, provider-specific logic.

If your engineering team writes custom if (provider === 'hubspot') code for every new endpoint, your documentation will always be out of date.

Truto eliminates this documentation burden entirely through its zero integration-specific code architecture. The coverage matrix becomes a thin presentation layer over the same configuration that defines runtime behavior.

Connectors as Declarative Data

In Truto, adding a new integration or supporting a new object is a data operation, not a code deploy. Integration-specific behavior is defined entirely as JSON configuration blobs and JSONata expressions stored in the database.

Because the entire unified API engine runs on generic execution pipelines, the platform knows exactly which objects, methods, and schemas are supported for every provider.

# Example of how Truto maps Salesforce fields declaratively via JSONata
response_mapping: >-
  response.{
    "id": Id,
    "first_name": FirstName,
    "last_name": LastName,
    "name": $join($removeEmptyItems([FirstName, LastName]), " "),
    "custom_fields": $sift($, function($v, $k) { $k ~> /__c$/i and $boolean($v) })
  }

Notice the custom_fields mapping. Truto dynamically sifts through the Salesforce response and extracts any field ending in __c. You do not need to manually document every single custom field your integration might encounter. You simply state: "Full dynamic support for all Salesforce custom fields via real-time passthrough."

Read more on Zero Integration-Specific Code: How to Ship API Connectors as Data-Only Operations.

Automated Tool Generation and JSON Manifests

Because Truto's integrations are strictly defined by data schemas, the platform can programmatically expose these capabilities. Truto automatically generates Model Context Protocol (MCP) tool definitions directly from the integration's config.resources and JSON Schema definitions.

This means the exact same configuration that powers the API automatically generates the documentation descriptions, query schemas, and body schemas. Your engineering team can expose these schemas via an API endpoint, allowing your marketing site to automatically render an always-up-to-date connector coverage matrix.

Normalized Pagination and Rate Limits

Truto exposes upstream rate limit info as standardized headers per the IETF spec. When the upstream returns HTTP 429, that error is passed through to your application unchanged. Documenting this behavior in your matrix gives engineering buyers a clear, accurate model of what to expect, without requiring custom documentation for every single provider's unique rate limiting quirks. For more on how this translates into per-customer flexibility, see 3-level API mapping.

Choosing a Unified API Platform for CRM and Ticketing: Truto vs. Unified.to vs. Apideck

If you are building CRM and ticketing integrations for an early-to-mid stage B2B SaaS product, three platforms surface in almost every evaluation: Truto, Unified.to, and Apideck. All three ship a unified API, cover the major CRM providers (Salesforce, HubSpot, Pipedrive) and ticketing tools (Zendesk, Jira, Freshdesk, Intercom), and expose raw provider payloads alongside normalized schemas. The differences that actually decide a purchase are narrower than the marketing pages suggest.

This section compares them on the three criteria that matter most for a growing team evaluating CRM and ticketing coverage: real-time data behavior, developer support, and unified data model flexibility.

One-Line Recommendation by Company and Buyer Stage

For the specific ask - CRM plus ticketing, real-time matters, hands-on developer support, and a flexible data model - the honest recommendation for an early-to-mid stage team is Truto. Not because the other two are broken, but because the trade-offs on custom fields and per-customer overrides show up early in production, and the support model changes how fast you get unblocked. Pricing details are on Truto's pricing page and coverage details on the integrations directory; a broader vendor breakdown lives in How to Choose a Unified API Provider and Best Unified API for Startups on a Budget.

Real-Time Behavior: Webhooks vs Polling (Tier Differences)

Every unified API platform sells "real-time." What actually matters is which specific object gets a native webhook, what happens when the provider does not emit one, and how tightly the polling interval is coupled to your pricing tier.

• Truto normalizes provider events into canonical record:created, record:updated, record:deleted, and record:meta types, delivered through a signed outbound queue with alarm-driven retries. Native webhooks are used wherever the upstream provider exposes them; virtual events generated by sync jobs flow through the same delivery pipeline. Polling cadence is not gated behind pricing tiers - the schedule you configure is the schedule you get.
• Unified.to operates a pass-through architecture where every request hits the source in real-time and end-customer data is never stored, with traffic stateless and regionalized (US/EU/AU). It supports both native webhooks (forwarded directly when available) and virtual webhooks (generated via polling), with the acknowledgment that CRM platforms differ widely: some providers emit native webhooks for certain objects, others provide none at all, and activity records typically require polling.
• Apideck exposes Virtualized Webhooks so partners can receive events by polling API endpoints as part of the Unify platform, with a proprietary polling engine that monitors changes and notifies via unified webhook events. Whether native or virtual, all webhook events are delivered in the same unified format. Buyers should confirm the default virtual polling interval per plan directly with Apideck sales.

Practical implication for CRM and ticketing: all three can deliver sub-minute latency for a HubSpot deal stage change or a Zendesk ticket update if the provider emits a native webhook for that specific object. For objects that don't - Salesforce Task creation, Jira comment edits on some plans, Freshdesk conversation events - the polling interval you can configure and whether it's tier-locked becomes the differentiator. Truto and Unified.to expose polling cadence as a configuration knob you control; Apideck's virtual polling defaults are more tightly tied to plan level.

Developer Support: Channels and Expected Response Times

None of these three vendors publish machine-readable SLAs for support response times, so verify during evaluation rather than trusting a marketing page. What you can compare are the default support channels and where each vendor draws the line between community and dedicated help.

On typical response times: Truto publicly commits to shared Slack channels with dedicated engineers as part of the default paid experience. Unified.to and Apideck both offer responsive email and community channels on lower tiers, with dedicated Slack and named engineers reserved for higher-tier plans. If the primary constraint is "I need a human on a call when a customer's Salesforce sandbox behaves differently from production," the practical difference is which tier that unlocks - and Truto unlocks it earliest.

Apideck's developer experience is worth calling out separately for teams that lean on AI coding tools: it ships plain-text documentation so AI tools get clean, parseable content, plus IDE plugins and building-with-LLMs guides. If you're building with Cursor, Claude Code, or GitHub Copilot, that matters.

Unified Data Model: Custom Fields and Escape-Hatch Capabilities

All three vendors converge on the same high-level design: normalize a fixed set of objects (contacts, deals, tickets, comments), attach the raw provider response so you never lose access to non-standard fields, and expose a proxy or custom endpoint for anything the unified schema doesn't cover. Where they diverge is in how custom fields are surfaced and how deep the escape hatch goes.

• Truto attaches remote_data on every unified response by default and exposes a Proxy API plus Custom API for arbitrary provider calls through the same authenticated connection. Custom fields on Salesforce (__c suffix) and HubSpot (non-default properties keys) are detected dynamically via JSONata expressions - no per-customer schema registration required. The three-level override hierarchy (platform default, environment override, account override) means a single customer's non-standard Salesforce instance can be handled without touching shared code.
• Unified.to exposes raw passthrough alongside the unified schema and states that it supports custom fields and read/write on custom objects (e.g., Salesforce) via unified metadata APIs. Field mapping is centralized at the platform level rather than per-account, which keeps the model simple but means enterprise customizations flow through the same mapping every tenant sees.
• Apideck normalizes responses while still exposing the raw downstream information for maximum convenience, and provides a Proxy API for provider-specific calls. Field extension is done via configured mappings in the Apideck dashboard.

For a ticketing use case, all three cover the standard objects (tickets, comments, attachments, users, contacts). The interesting cases are Jira Custom Fields, Zendesk custom ticket fields, and Freshdesk's dynamic form fields. If your product will onboard enterprises whose Jira instances have 50-100 custom fields, per-customer mapping overrides matter more than any other single feature. That's the point where an early-to-mid stage team pays for architecture that can grow with the customer.

Short FAQ: When to Pick Which Vendor

When should an early-to-mid stage B2B SaaS pick Truto over Unified.to or Apideck? When you need CRM plus ticketing coverage now, expect enterprise customers within 12 months, and want per-customer mapping overrides available on day one. Also when you'd rather debug a JSONata expression than file a ticket and wait for a mapping change.

When does Unified.to make more sense? When your compliance model requires provable zero data storage and every read must hit the source live, and when centralized (not per-tenant) field mapping is sufficient for your customer profile. Unified.to never stores end-customer data and its traffic is stateless and regionalized (US/EU/AU), reducing compliance scope and eliminating data-at-rest risk.

When does Apideck make more sense? When you are prototyping and want the broadest set of language SDKs and the easiest sandbox path. Apideck's in-browser explorer, OpenAPI specs, and SDKs in Node.js, Python, PHP, and .NET, combined with plain-text LLM-friendly docs, make the first API call easier to reach for teams evaluating quickly.

Do all three support real-time webhooks for CRM and ticketing? Yes, but with different backends. All three combine native provider webhooks with polling-based virtual webhooks. Latency and payload contents vary by provider on every platform - none of them can make a provider that only exposes polling APIs behave like a push provider. What differs is how transparent the polling interval is and whether it's plan-gated.

Do all three expose a raw escape hatch for provider-specific fields? Yes. Truto's Proxy API and always-attached remote_data field, Unified.to's raw passthrough, and Apideck's Proxy API all give you access to the underlying provider response when the unified schema doesn't cover a field you need.

Which one has the deepest custom field story for enterprise Salesforce instances? Truto, because per-account mapping overrides let one customer's Primary_Contact_Email__c field be treated as the canonical email address without changing anything for every other customer. Unified.to and Apideck both handle custom fields well at the platform level, but per-tenant divergence is where the override hierarchy pays for itself.

Next Steps: Ship the Matrix Before Your Next RFP

A connector coverage matrix is not a documentation project. It is a sales asset that compounds every time an enterprise buyer self-qualifies, every time a security reviewer finds the answer without a call, and every time an AI agent builder reads it as machine-consumable JSON.

Publishing supported objects per provider is a required go-to-market motion for any B2B SaaS company selling to mid-market or enterprise buyers. If you do nothing else this quarter:

1. Pick your top five integrations by revenue exposure in your pipeline.
2. Document every object you actually support today using the schema and taxonomy detailed above.
3. Publish each as a dedicated URL with a downloadable JSON manifest.
4. Add a last_updated timestamp and commit to refreshing quarterly.
5. Hand the URLs to your sales team and instrument page views in your CRM.

The teams that win enterprise integration deals in 2026 are not the ones with the longest logo walls. They are the ones whose /integrations/netsuite page answers the architect's question in under a minute.

Stop losing deals because buyers cannot verify your integration capabilities. Document your depth, expose your supported objects, and treat your integrations page as the revenue driver it actually is.