How to Create a SaaS Integration Deployment Datasheet (Cloud vs VPC vs On-Premise)

If your enterprise sales cycles stall in InfoSec review every time a buyer asks, "Where does our integration data actually live?" the fix is not another sales deck. When a Chief Information Security Officer (CISO) evaluates your B2B SaaS product, a marketing page with a grid of fifty provider logos means nothing. They need a definitive, self-serve SaaS integration deployment options datasheet that explicitly details where third-party data lives, how it is processed, what network boundaries it crosses, and what sub-processors are involved.

The stakes for getting this right are massive. The data integration market is projected to reach $47.60 billion by 2034, driven almost entirely by enterprise software sprawl. According to a 2024 B2B Tech Buyer Behavior report, 90% of B2B buyers consider integration capabilities a major factor when shortlisting vendors. Having the integration gets you on the shortlist. Proving your integration architecture is secure gets you the signed contract.

This guide breaks down exactly how senior product managers and product marketing managers should structure a public-facing deployment options datasheet. We will cover the architectural realities of Cloud, VPC, and On-Premise deployments, how to document your connector coverage matrix, the brutal honesty required around rate limits, and why a zero-data-retention architecture is mandatory for modern enterprise sales.

Why Enterprise Buyers Demand a Deployment Options Datasheet

Security reviews are not about checking boxes. They are about mapping risk. When your SaaS application connects to a customer's NetSuite, Workday, or Salesforce instance, you are asking for the keys to their most sensitive financial and employee data.

If you use a traditional unified API or an embedded iPaaS (Integration Platform as a Service) to power those connections, you introduce a third-party sub-processor into the data flow. Enterprise InfoSec, legal, and procurement teams will immediately ask:

1. Where is customer data processed and stored? Does this third-party integration tool store our payload data?
2. What sub-processors touch the data in transit? Are the integrations executed in a shared, multi-tenant environment?
3. Can we deploy this integration engine inside our own VPC to maintain a strict perimeter?

If your answer to the first question is "yes," or your answer to the third question is "no," you will face months of painful Data Protection Impact Assessments (DPIAs) and custom legal addendums.

Integrations are not a feature footnote on the enterprise buying committee's checklist; they are a shortlist gate. And the data reality is more nuanced than the "everything goes cloud" narrative suggests. Gartner reports $723.4B in worldwide public-cloud end-user spending in 2025, yet IDC finds 49% of production workloads still run on-premises today, with more than two-thirds expected to shift over the next 3-5 years. That mid-state is exactly where most of your enterprise pipeline lives.

The pressure is not theoretical. According to IDC's European Cloud Survey, 14% of companies are moving workloads back on-premise, mainly due to costs (42%) and compliance (38%). This matters even more when residency laws compound the problem. Residency integrity restricts all replication, including scheduled, on-demand, failover, or snapshot, to jurisdiction-aligned zones. It prohibits cross-border duplication, even between performance-matched regions, unless explicitly allowed by legal frameworks. A vague "hosted on AWS us-east-1" statement is no longer enough for German, Canadian, or UAE buyers.

To bypass this friction, you must publish a deployment options datasheet. This document proves that your product architecture aligns with their compliance frameworks (SOC 2, HIPAA, GDPR) and clearly outlines the shared responsibility model for API connectivity.

Cloud vs VPC vs On-Premise: Defining the Integration Architectures

Your datasheet must explicitly define the deployment models you support. Most vendors blur these terms in marketing copy. Your datasheet should not. Buyers need to understand the trade-offs between speed of implementation and control over the network perimeter. Here are the working definitions InfoSec reviewers expect to see.

1. Multi-Tenant Cloud Deployment

In a multi-tenant cloud deployment model, the integration platform runs in your own cloud account (or your unified API provider's infrastructure).

How it works: Your application makes a request to the integration layer. The integration layer authenticates with the third-party SaaS provider, executes the request, normalizes the response, and returns it to your application over the public internet.

Enterprise InfoSec concerns: This is the cheapest to operate and fastest to deploy, but the riskiest from an InfoSec standpoint because customer data transits and frequently rests inside your perimeter. If the integration layer uses a sync-and-cache architecture—meaning it stores the third-party data in its own database before passing it to you—it becomes a massive security liability.

The modern variant is zero-data-retention cloud, where the platform acts as a pass-through proxy. It normalizes API responses in-memory without persisting payloads. Cloud deployments are only acceptable to strict enterprise buyers if you can prove this pass-through architecture.

2. Virtual Private Cloud (VPC) Deployment

A VPC deployment isolates the integration engine within a dedicated, logically separated network segment. The data plane is fully isolated.

How it works: Instead of routing third-party API traffic through a shared multi-tenant cloud, the integration engine is deployed directly into the customer's AWS, GCP, or Azure environment via container images. The control plane (configuration, observability) may stay in the vendor cloud, but data never crosses out of the customer's perimeter.

Enterprise InfoSec benefits: This model is highly attractive to enterprise buyers in regulated industries. All data transformation, webhook ingestion, and API proxying happen within their own network perimeter. The customer retains total control over egress rules, IP allowlisting, and network security groups.

Consider a retail bank: card transactions stay encrypted in a Frankfurt VPC, but nightly analytics jobs are scheduled from a control plane running in Dublin. The bank meets strict EU residency requirements without building duplicate orchestration stacks for every country.

Many legacy embedded iPaaS vendors struggle with this model. Their heavy, visual-workflow orchestration engines require massive infrastructure footprints (message brokers, state databases, worker nodes) that are too complex to deploy in a customer's VPC. Modern integration architectures rely on lightweight, stateless execution pipelines that can easily be shipped as Docker containers.

3. On-Premise Deployment

On-premise deployment takes isolation a step further, running the integration engine on bare-metal servers or private data centers completely disconnected from the public cloud.

How it works: Similar to the VPC model, the integration logic is containerized. However, it operates behind strict corporate firewalls, fully air-gapped if needed, often requiring reverse proxies or secure tunnels to communicate with external SaaS APIs. There is no vendor-side dependency.

Enterprise InfoSec benefits: Absolute data sovereignty. For banks, defense contractors, or highly regulated federal institutions, this is often a hard requirement. It is operationally expensive for you to support and for them to run, but it closes deals that no other model can.

flowchart LR
    subgraph Cloud["Multi-Tenant Cloud (Zero-Retention)"]
        A1[Customer App] --> A2[Vendor Cloud Proxy<br>In-Memory Normalization]
        A2 --> A3[Third-Party SaaS API]
    end
    subgraph VPC["Customer VPC"]
        B1[Customer App] --> B2[Containerized Integration Engine<br>in Customer VPC]
        B2 --> B3[Third-Party SaaS API]
        B4[Vendor Control Plane] -.config only.-> B2
    end
    subgraph OnPrem["On-Premise"]
        C1[Customer App] --> C2[Integration Engine<br>in Air-Gapped Datacenter]
        C2 --> C3[Third-Party SaaS API]
    end

For a deeper look at how these models map to compliance frameworks, see Which Integration Tools Are Best for Enterprise Compliance.

Control Plane vs Data Plane: What Actually Runs Where

The single most useful thing you can add to a deployment datasheet is a component-by-component breakdown of which parts of the integration platform run in the vendor's environment versus the customer's environment. InfoSec reviewers do not want prose; they want a table.

The control plane is the coordination layer: configuration UI, connector definitions, mapping expressions, deployment orchestration, and observability. The data plane is the execution layer: OAuth flows, credential storage, API request and response handling, webhook ingestion, and rate-limit tracking. Enterprise buyers care most about the data plane. Anything that touches payloads or customer credentials belongs there.

In VPC and On-Premise deployments, only configuration metadata and connector definitions cross the vendor boundary. Payload data, credentials, and tokens never leave the customer perimeter. This is the boundary an InfoSec architect needs to see drawn explicitly before they will sign off.

White-Label OAuth Flows in VPC and On-Premise Deployments

If your enterprise buyers are asking for an integration partner that can white-label OAuth flows and deploy on-prem for compliance, the OAuth handling is often the decisive detail. It is also the component most integration vendors get wrong.

An embedded integration platform is not the same as a general-purpose identity provider like Okta or Auth0. It does not issue your customers' end-user SSO tokens. What it does is orchestrate the OAuth 2.0 authorization code flow (plus OAuth 1.0a, client credentials, and API key auth) against third-party SaaS providers on behalf of your customers - Salesforce, HubSpot, NetSuite, Workday, Google Workspace, and so on. This distinction matters when procurement is evaluating on-prem identity vendors and enterprise OAuth gateways alongside integration partners.

For enterprise on-prem compliance, a white-label OAuth integration partner must handle these details:

1. Custom redirect URI on customer-owned domain. The OAuth callback must resolve to integrations.customer.com, not oauth.vendor.com. This keeps the consent screen and redirect chain within the customer's brand and network perimeter.
2. Provider app credentials owned by the customer. Some third-party providers (Salesforce, HubSpot, Google) let you register your own OAuth application. On-prem deployments should allow the customer to bring their own client ID and secret, with the vendor's shared app available only as a fallback.
3. Token storage inside the customer perimeter. Refresh tokens and access tokens must be encrypted at rest inside the customer's VPC or datacenter, ideally using the customer's KMS or HSM. No copy of the token should live in the vendor cloud.
4. Token refresh executed locally. The platform must refresh OAuth tokens shortly before they expire without round-tripping to a vendor-side service. All refresh traffic goes directly from the customer environment to the provider API.
5. OIDC support where providers offer it. For providers that publish OIDC discovery documents, the integration engine should honor .well-known/openid-configuration and use standard JWKS rotation.
6. Revocation and rotation webhooks. When a token is revoked or a refresh fails, the platform must emit a signed event to the customer's application so they can prompt re-consent without polling.

This is what buyers mean when they ask for a white-label OAuth provider on-prem, a white-label identity platform on premises, or an on-prem OAuth/OIDC server for enterprise integrations. It is not a replacement for Okta or Auth0 on the workforce SSO side. It is a purpose-built OAuth client and token orchestrator for third-party API access, deployable inside the customer's compliance perimeter.

sequenceDiagram
    participant EndUser as "End User (Customer's employee)"
    participant CustApp as Customer App
    participant IntEngine as "Integration Engine (in Customer VPC)"
    participant Provider as "Third-Party SaaS (e.g., Salesforce)"
    participant KMS as Customer KMS

    EndUser->>CustApp: Click "Connect Salesforce"
    CustApp->>IntEngine: Initiate OAuth (state, PKCE)
    IntEngine->>EndUser: Redirect to Salesforce consent (whitelabel domain)
    EndUser->>Provider: Approve consent
    Provider->>IntEngine: Redirect to integrations.customer.com/callback with code
    IntEngine->>Provider: Exchange code for tokens (client_id owned by customer)
    Provider->>IntEngine: access_token + refresh_token
    IntEngine->>KMS: Encrypt and store tokens
    IntEngine->>CustApp: Signed event: connection established

Network, DNS, Certificate, and Firewall Requirements

VPC and on-premise deployments live or die by the pre-install network conversation. Document these explicitly so the customer's network and security teams can review before installation kickoff.

Outbound egress

The integration engine needs outbound HTTPS (443) to the third-party provider APIs the customer plans to use. Document exact destinations per connector:

• *.salesforce.com, *.force.com for Salesforce
• *.suitetalk.api.netsuite.com for NetSuite
• api.hubapi.com for HubSpot
• wd*.myworkday.com for Workday tenants
• oauth2.googleapis.com, *.googleapis.com for Google Workspace

Do not tell customers "allow all outbound." Give them the actual FQDN list per connector, or a script that generates the allowlist from their enabled providers.

Inbound ingress

For providers that push webhooks (Salesforce Platform Events, HubSpot, Stripe), the integration engine needs an inbound HTTPS endpoint reachable from the provider's IP ranges. Document each provider's published IP ranges and note which providers do not publish stable ranges (in which case the customer will need to allow broader inbound and rely on signature verification).

DNS

• OAuth callback domain: customer-owned, TLS-terminated at the customer's ingress. Example: integrations.customer.com/oauth/callback.
• Webhook receiver domain: customer-owned. Example: webhooks.customer.com.
• Optional control-plane hostname: only if a vendor control plane exists and the customer's ops team accesses the UI directly.

TLS certificates

• Bring-your-own certificate for all customer-facing endpoints (OAuth callback, webhook receiver, admin UI). PEM format, standard chain.
• Support for internal CA-signed certificates in air-gapped environments. The engine should accept a custom CA bundle for validating outbound TLS through an internal proxy.
• Mutual TLS optional for the control-plane-to-data-plane channel in VPC deployments where a vendor control plane exists.
• Automated renewal via cert-manager or the customer's existing ACME workflow.

Firewall and proxy

• Support for outbound HTTP proxy with authentication (for datacenter egress through a forward proxy).
• Configurable connect and read timeouts per connector.
• No hard-coded IP dependencies. Everything DNS-resolvable so customers can front the engine with their own perimeter proxy.

Air-gapped and offline options

For fully air-gapped datacenters, the platform should support:

• Offline installation from a signed container bundle (no docker pull at install time).
• Offline connector-definition updates via signed archive with detached signature verification.
• No mandatory outbound telemetry or license-check calls for runtime operation. Telemetry, if any, must be optional and export to a customer-controlled sink.

Installation and Validation Checklist

Give the customer's platform team a checklist they can run through in a single afternoon. This is what turns a two-quarter deployment into a two-week one.

Preflight

• Kubernetes cluster (or Docker host) meets minimum version requirements
• Namespace or project created with appropriate RBAC
• Persistent volume provisioned for configuration and token storage
• Secrets backend configured (customer KMS, HashiCorp Vault, or Kubernetes secrets with envelope encryption)
• Outbound egress rules applied for planned connectors
• Inbound firewall rules applied for webhook receivers
• DNS records created for OAuth callback and webhook receiver
• TLS certificates issued and available as secrets
• Customer-owned OAuth apps registered with each third-party provider that requires it

Install

• Container images pulled from customer registry (or loaded from offline bundle)
• Helm chart or manifest applied with customer-specific values
• Database or state store initialized (schema migrations complete)
• Health-check endpoint returns 200 on all pods
• Metrics endpoint scraped successfully by the customer's monitoring stack

Validation

• End-to-end OAuth flow completes for one representative provider (e.g., Salesforce sandbox)
• Access token stored in customer KMS, retrievable by the runtime
• Token refresh succeeds ahead of expiry (verify with a short-TTL test token)
• Webhook ingestion accepts a signed test payload from the provider
• Outbound delivery to a test endpoint verifies signature
• Rate-limit headers surface correctly on a 429-triggering test
• Audit-log entries appear for auth, config change, and API-call events
• Disaster recovery restore rehearsed on a non-prod namespace

Support, SLAs, and Maintenance Responsibilities

Deployment models change the shared responsibility split. A crisp table prevents the "who owns this incident" argument at 3 a.m.

SLA structure enterprise buyers expect

• Severity 1 (production down): 15-minute response, 4-hour restoration target for cloud; response times align to installed footprint for VPC and on-prem.
• Severity 2 (major feature degraded): 1-hour response, next-business-day restoration.
• Severity 3 (minor issue): Next business day.
• Severity 4 (question, config help): 3 business days.

Publish uptime targets for cloud (99.9% or 99.95% depending on tier). For VPC and on-prem, publish the availability the platform is engineered for on reference hardware, and note that measured uptime depends on the customer's infrastructure.

Runbooks to hand off with every VPC or on-prem install

1. Token refresh failure - how to inspect the token vault and force a re-auth.
2. Webhook backlog - how to drain the queue and replay from claim-check storage.
3. Upstream 429 storm - how to inspect rate-limit headers and adjust connector concurrency.
4. Certificate rotation - how to rotate TLS certs without downtime.
5. Connector definition rollback - how to pin to a prior signed bundle if a new version misbehaves.
6. Disaster recovery - snapshot cadence, restore procedure, RTO and RPO targets.
7. Provider outage response - how to route around a degraded provider and replay once it recovers.

Typical Timelines and Customer Prerequisites

Setting timeline expectations up front is the fastest way to build trust with an InfoSec team. Vague "we can deploy in weeks" answers get flagged; specific timelines with prerequisites do not.

What lengthens the timeline

• Custom OAuth app registration with each third-party provider (Salesforce and NetSuite in particular can take days to get approved).
• Certificate procurement from a slow internal CA.
• Change-advisory-board approvals for new firewall rules.
• Security architecture review boards that meet biweekly.

What compresses the timeline

• Pre-provisioned Kubernetes cluster with a standard ingress controller.
• Existing wildcard TLS certificate for the target subdomain.
• A single security contact with authority to approve DPA and sub-processor list without committee escalation.
• Pre-approved container registry with the vendor's images already mirrored.
• OAuth apps pre-registered with the top three providers before install day.

How to Structure Your Connector Coverage Matrix

A deployment datasheet without a matching connector matrix is half a document. Listing deployment models is not enough; enterprise buyers need to know the depth of your integrations. They do not just want to know if you connect to HubSpot. They need to know: "Does it work for OUR stack, in OUR deployment model?"

Your datasheet must include a connector coverage matrix that explicitly lists supported objects, operations, and deployment availability per provider. It should answer these core questions per connector:

1. Which deployment models support this connector? (Cloud / VPC / On-Prem)
2. What exact objects are supported? (e.g., Accounts, Contacts, Invoices, Custom Objects)
3. What operations are available? (Read, Write, Update, Delete / CRUD)
4. What authentication methods are available? (OAuth 2.0, API key, mTLS, SAML)
5. What is the data freshness mechanism? (Polling, webhooks, both)

Handling Custom Fields and Objects

Enterprise SaaS instances are heavily customized. A standard NetSuite deployment might have hundreds of custom fields specific to the customer's internal accounting practices. If your integration architecture relies on rigid, hardcoded data models, it will break when it encounters these customizations.

Your datasheet should explain how you handle schema drift and custom data. Modern platforms use JSONata-based configuration for provider-specific event normalization. This declarative approach allows you to map custom upstream fields to your application's schema on the fly, without writing integration-specific code or requiring engineering deployments for every new customer request.

Here is a minimal table structure that works well for public pages:

Addressing the Zero Data Retention Mandate in the Cloud

Here is the brutal honesty most integration vendors avoid: a traditional unified API that caches normalized data in its own database will lose enterprise deals to vendors that don't, even when the cached architecture is technically faster.

If a customer opts for your Cloud deployment model instead of a VPC, you must address their primary fear: data retention. InfoSec teams treat "vendor stores our customer data" as a separate category of risk requiring DPAs, sub-processor audits, and quarterly reviews. This is a massive compliance violation for companies dealing with Protected Health Information (HIPAA) or strict European data residency laws (GDPR). That friction kills momentum.

To pass strict InfoSec reviews, your datasheet must highlight a pass-through, zero data retention architecture. This sidesteps the problem entirely.

The Mechanics of Pass-Through Architecture

In a pass-through model, the integration layer acts as a stateless proxy. When your application requests a list of contacts from Salesforce:

1. The request hits the integration proxy.
2. The proxy injects the correct, encrypted OAuth credentials and translates the request into the provider's format.
3. The provider returns the data to the proxy in real-time.
4. The proxy normalizes the data in memory (using JSONata expressions) and streams it directly back to your application.
5. The proxy immediately discards the payload. Nothing is written to disk or a database. The only persistent state is configuration, OAuth tokens, and operational metadata.

This guarantees that customer payload data is never persisted at rest outside of their own systems. It is the difference between a 14-day security review and a 90-day one.

Trade-offs to Be Honest About

• Latency: Pass-through inherits the upstream provider's latency. There is no local cache to hide a slow Workday API behind. Document this.
• Replay and audit: Without stored payloads, replay-from-cache is impossible. Customers needing audit trails must log responses themselves.
• Rate limits: With no cache, every customer request hits the upstream. Rate limit handling becomes a first-class concern.

Rate Limit Behavior - Document It Explicitly

Savvy InfoSec reviewers will point out a technical challenge: if you do not cache data, how do you handle API rate limits?

One of the most overlooked sections of an enterprise datasheet is how the integration layer handles upstream rate limits. The answer should be specific, not aspirational. State clearly that your integration layer does not absorb or mask rate limits by queuing requests in a black box.

Instead, document that your platform normalizes upstream rate limit information into standardized headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset) per the IETF specification. When an upstream API returns an HTTP 429 Too Many Requests error, that error is passed directly to the caller. This gives the customer's engineering team full visibility and control over their own exponential backoff and retry logic. "Magic" retry layers that absorb 429s often cause silent data drift and missed webhooks at enterprise scale.

Data Residency Compliance in Unified APIs: Architecture Decision Framework

Data residency is no longer just a legal checkbox - it is an architectural constraint that shapes every integration decision. Cumulative GDPR fines now exceed €7.1 billion, with €1.2 billion issued in 2025 alone. TikTok absorbed €530 million for unlawful EU-China data transfers. And the trend is accelerating: Gartner predicts that by 2030, more than 75% of European and Middle Eastern enterprises will geopatriate their workloads into sovereignty-aligned environments, up from less than 5% in 2025.

For unified API buyers, the core question is: how does your integration layer handle data residency when it sits between your application and dozens of third-party SaaS providers? The answer depends entirely on which architecture your vendor uses.

Three Data-Residency Architectures for Unified APIs

Every unified API falls into one of three residency models. Each has different compliance implications, and your datasheet must be explicit about which one applies.

1. Pass-Through / Zero-Retention Cloud

The integration layer proxies API calls in real-time without storing payloads. Data is normalized in memory and discarded after delivery. From a residency standpoint, customer data never "resides" in the integration layer - it transits through it. The only persistent data is configuration metadata, OAuth tokens, and operational logs (none of which contain customer payload data).

2. Cached / Regional SaaS

The integration layer syncs and stores third-party data in its own database before serving it to your application. Some vendors offer regional instances (EU, APAC, US) to satisfy residency constraints. This model introduces the integration vendor as a data processor and sub-processor under GDPR, HIPAA, and similar frameworks. Every cached record is subject to the residency laws of the region where the vendor's database runs.

3. VPC / On-Premise

The integration engine runs entirely inside the customer's cloud account or physical datacenter. Data never leaves the customer's network perimeter. This is the strongest residency guarantee because the customer controls the jurisdiction, the infrastructure, and the access policies.

Side-by-Side Residency Comparison

PII Exposure and Field-Level Controls

When a unified API normalizes responses from third-party providers, it handles personally identifiable information (PII) - employee names, email addresses, compensation data, Social Security numbers. How your integration layer treats that PII is a make-or-break question for enterprise security teams.

There are three levels of PII protection to document in your datasheet:

1. Architectural PII protection (zero retention). If the integration layer never persists payloads, PII is never at rest in the vendor's environment. This is the strongest default posture because there is nothing to breach, nothing to subpoena, and nothing to include in a sub-processor audit.

2. Field-level response filtering. The integration layer should let customers exclude sensitive fields from API responses before they reach the calling application. For example, a unified API that supports excluding raw upstream data (the original third-party response attached to each normalized record) gives customers control over what PII surfaces in their systems. If you do not need Social Security numbers from the HRIS provider, your application should never receive them.

3. Mapping-layer redaction. With declarative response mappings (like JSONata expressions), teams can transform or omit specific PII fields during normalization. A compensation field can be dropped entirely, a phone number can be truncated, or an email can be hashed - all in the mapping configuration, without writing custom code. This is not the same as enterprise-grade PII masking tools (Delphix, Informatica) that handle static data masking across databases. But for API-layer protection in transit, it is often sufficient and far simpler to implement.

The honest caveat: integration-layer field filtering is a complement to, not a replacement for, proper data classification and access controls in your own application. If your downstream data warehouse ingests everything, filtering at the API layer only delays the exposure.

Decision Checklist: When Each Residency Model Applies

Use this checklist to determine which deployment model your customers actually need. Do not default to VPC for everyone - it adds operational overhead that many buyers do not want.

Pass-through cloud is sufficient when:

• The customer has no regulatory mandate for data localization (no GDPR localization effect, no China PIPL, no Russia data localization)
• The customer's compliance framework accepts zero-retention attestations (SOC 2 Type II report confirms no payload persistence)
• Integration data is transactional and does not require replay or historical queries
• The customer's InfoSec team accepts TLS 1.3 in-transit encryption without requiring perimeter control
• Speed of deployment matters more than network-level isolation

VPC deployment is required when:

• The customer operates in a regulated industry (financial services, healthcare, insurance) with data perimeter requirements
• Compliance frameworks mandate that customer data must not transit vendor infrastructure (even transiently)
• The customer requires IP allowlisting, private endpoints, or network security group control over integration traffic
• Data residency laws require processing within a specific jurisdiction and the vendor's cloud region does not match
• The customer's procurement process flags any third-party sub-processor as requiring a full DPIA

On-premise deployment is required when:

• The environment is air-gapped or disconnected from the public internet
• Government or defense contracts mandate on-site data processing (FedRAMP High, IL4/IL5, ITAR)
• The customer's security policy prohibits any cloud dependency for integration workloads
• Data sovereignty requirements go beyond residency into full jurisdictional control with no foreign vendor access

Security Questionnaire: Questions Your Vendor Must Answer

Enterprise procurement and InfoSec teams should include these specific questions when evaluating any unified API or integration platform. Vague answers to any of these are a red flag.

Data residency and retention:

1. Does your integration layer persist, cache, or replicate any customer payload data at rest? If yes, for how long and in which regions?
2. What is the exact retention window for API request/response data? Is it zero, 24 hours, 30 days, or configurable?
3. Which geographic regions host your integration infrastructure? Can we restrict processing to a specific region (EU, APAC, US)?
4. Does any data - including logs, metadata, or error payloads - replicate across regions or availability zones outside our specified jurisdiction?

Sub-processors and data flow: 5. Provide a complete list of sub-processors that handle, transit, or store customer data. Include the data center region for each. 6. Does the integration layer use any third-party services for queuing, caching, or temporary storage of API payloads? 7. If we choose your cloud deployment, can you contractually guarantee that our payload data never persists beyond in-memory processing?

PII and sensitive data handling: 8. Can we exclude specific fields (PII, compensation, health records) from API responses at the integration layer before they reach our application? 9. Does your response normalization support field-level redaction or transformation for sensitive data? 10. How are OAuth tokens and API credentials encrypted at rest? What key management approach is used?

Deployment flexibility: 11. Do you support deployment inside our VPC or on-premise datacenter? What is the minimum infrastructure footprint? 12. In a VPC deployment, what data flows between our environment and your control plane? Is it limited to configuration and observability, or does customer data transit as well? 13. What is your patch and update cadence for VPC/on-premise deployments? Can we control the upgrade schedule?

Template: Building Your Deployment & Connector Datasheet

Do not overcomplicate the design. Enterprise buyers want dense, highly structured technical information. Treat each section as a self-contained answer to a specific InfoSec or procurement question. Use the following markdown template to build your public-facing datasheet.

Section 1: Architecture & Security Executive Summary

Start with a definitive statement about data processing.

Data Processing Guarantee: Our integration infrastructure utilizes a strict zero-data-retention pass-through architecture. Third-party payload data is fetched in real-time, processed in memory, and never persisted to our databases. We hold SOC 2 Type II and HIPAA compliance certifications. We support Multi-Tenant Cloud, VPC, and On-Premise deployment models.

Section 2: Data Flow Diagrams

Provide one diagram per deployment model (Cloud, VPC, On-Prem). Show exactly where authentication credentials are stored, where token refresh happens, and whether payloads are persisted.

Section 3: Authentication Methods Supported

List every auth mechanism with examples. Readers need to confirm you support what their target systems require. Workday and NetSuite alone push most vendors into ugly auth corners.

• OAuth 2.0 Authorization Code (with PKCE)
• OAuth 2.0 Client Credentials
• OAuth 1.0a (for NetSuite TBA)
• API Key (header or query)
• Basic Auth
• mTLS / Certificate-based

Token Management: We manage the full OAuth lifecycle, including authorization code exchange and automated token refreshes. Refresh tokens are stored using AES-256 encryption at rest. If a token refresh fails or is revoked, we emit a standardized webhook event to alert your application immediately.

Section 4: Connector Coverage Matrix

Provide the searchable table of supported integrations (from the section above), with one row per provider. Link each row to a dedicated connector page that lists supported objects, rate limits, and known limitations.

Section 5: Webhook & Event Ingestion Architecture

Explain how you handle asynchronous data and delivery guarantees.

Webhook Processing: We support two inbound webhook ingestion patterns: account-specific endpoints and environment-integration fan-out. Outbound delivery to your systems uses a queue and object-storage claim-check pattern with cryptographically signed payloads (X-Signature headers) to guarantee authenticity and prevent replay attacks.

Section 6: Rate Limit and Error Handling

Document exactly how transient errors (502, 503, 504) are surfaced, and how HTTP 429 errors are passed through to the caller alongside standardized IETF rate limit headers.

Section 7: Deployment Specifications (VPC / On-Prem)

For VPC and On-Premise models, explicitly list:

• Container runtime requirements (Docker, Kubernetes versions)
• Minimum hardware specs
• Network egress requirements (which outbound IPs and ports)
• Update and patch cadence (Container Image Pulls)
• Air-gap support availability

Section 8: Compliance and Sub-Processors

Provide a public sub-processor list with the data center region for each. Vendors rarely document every subprocess, leaving customers without complete lineage when regulators ask exactly where specific records went. Be the exception.

How Truto Simplifies Enterprise Integration Deployment

Building an integration architecture that satisfies both early-stage startups and Fortune 500 InfoSec teams is incredibly difficult. If you hardcode API integrations, you cannot scale. If you use an embedded iPaaS, you cannot deploy on-premise easily. If you use a legacy unified API, you fail data residency requirements.

Truto solves this by completely decoupling the integration configuration from the execution environment. Because Truto handles 100+ third-party integrations without a single line of integration-specific code in its runtime logic, the entire execution pipeline is lightweight and stateless. This enables true deployment flexibility:

• For Cloud Customers: Truto's cloud deployment utilizes a zero-data-retention, pass-through architecture. API responses are normalized in memory and returned to the caller; no customer payload data is ever persisted. This makes it fundamentally safer than traditional sync-and-cache unified APIs and lets compliance-strict SaaS companies use the cloud option without forcing a VPC build.
• For Enterprise Customers: Truto supports deployment directly inside a customer's VPC or on-premise data center via container images. This keeps all execution logic, token management, and data transformation entirely within the customer's perimeter.
• For White-Label OAuth on-prem: Truto is a purpose-built integration partner for teams that need white-label OAuth flows with the callback, consent redirect, and token vault all inside the customer's environment. Refresh tokens are encrypted with the customer's KMS, refresh calls run locally, and OIDC discovery is honored where providers publish it. It complements (does not replace) workforce identity platforms like Okta or Auth0.
• For Engineering Teams: Truto normalizes upstream rate limit info into standardized IETF headers, passing HTTP 429 errors directly to the caller for full control over retry logic. It uses JSONata-based configuration for provider-specific event normalization, allowing teams to maintain a vast connector coverage matrix without writing custom code.

The honest trade-off: a pass-through cloud architecture means your application code must handle rate limits, retries, and pagination as first-class concerns. If you want a black box that caches everything and "just works" at the cost of vendor data retention, this is not it. If you want a model that survives enterprise InfoSec without requiring a VPC for every customer, it is.

Next Steps for Your Deployment Datasheet

A strong deployment datasheet is the single highest-leverage piece of content your product marketing function can ship for enterprise pipeline. It compresses three weeks of security questionnaire back-and-forth into a single link. It lets Account Executives send one URL instead of scheduling a "deep technical" call.

Concrete next actions:

1. Audit your current integrations page. If it only shows logos, you have a gap. Add a deployment column to your connector list this quarter.
2. Draft the data flow diagrams first. They force architectural honesty. If you cannot draw the diagram cleanly, the architecture is not ready to sell to enterprise.
3. Publish the matrix as HTML, not PDF. AI search engines and procurement copilots cannot index gated PDFs well. The whole point is discoverability.
4. Version the document. Date-stamp it and commit to a quarterly refresh. Buyers will check.
5. Tie each connector row to a dedicated technical page. Use the connector coverage matrix playbook for structure.

If you are choosing between building the underlying multi-deployment infrastructure in-house and adopting a platform that supports cloud, VPC, and on-prem out of the box, the build cost compounds far past the first deal. The vendors winning enterprise pipeline are the ones whose datasheets read like internal architecture documents, not marketing brochures.