How to Ensure Zero Data Retention When Processing Third-Party API Payloads

Zero Data Retention (ZDR) when processing third-party API payloads means designing an integration architecture that transforms, normalizes, and proxies data entirely in memory, immediately discarding the payload once the HTTP response completes. If you are building B2B software, adopting this architecture is not a theoretical exercise in system design. It is a binary requirement for passing enterprise security audits.

Your enterprise deal just stalled in procurement. The buyer's InfoSec team reviewed your vendor risk assessment and flagged a massive liability: your integration middleware caches their sensitive HRIS records and CRM contacts on shared infrastructure. They classified your integration layer as an unmanaged sub-processor, refused to sign the Business Associate Agreement (BAA), and the deal is effectively dead.

If you process third-party API payloads containing sensitive CRM, HRIS, or financial data, storing that data at rest is a massive liability. Enterprise procurement teams will actively block your deals if your integration architecture relies on caching their regulated data on unverified third-party infrastructure. To pass strict InfoSec reviews and ship integrations fast, you need an architecture that processes data in transit without ever writing it to a database.

This guide breaks down exactly how to architect a Zero Data Retention (ZDR) integration pipeline. We will examine why legacy sync-and-store architectures fail enterprise security audits, how to build a stateless pass-through proxy, and how to use declarative mapping languages to normalize payloads entirely in memory.

The Enterprise Procurement Wall: Why Data at Rest Kills Deals

When you sell B2B SaaS to mid-market and enterprise companies, integration velocity is your primary bottleneck. When you move upmarket, compliance becomes the binary go or no-go for revenue.

Enterprise procurement teams rely on extensive third-party risk management (TPRM) assessments. When your account executive moves a six-figure deal to the final stages, the buyer's procurement team sends over a Standardized Information Gathering (SIG) questionnaire. SIG Core is an extensive assessment with over 850 questions covering 19 to 21 risk categories. It is designed to assess third parties that store or manage highly sensitive or regulated information.

Domain 10 of the SIG questionnaire focuses heavily on Third-Party Risk Management and data at rest. Questions specifically target how sub-processors handle data storage, retention limits, and cryptographic standards for data at rest. If your integration platform stores a copy of the customer's Salesforce or Workday database, you must disclose it.

The global average cost of a data breach reached $4.88 million in 2024, according to IBM's Cost of a Data Breach Report. That same report identified third-party software vulnerabilities and vendor supply chain breaches as major cost amplifiers. Enterprise security teams read these reports. They know that every vendor who caches their data represents a new attack vector. When you introduce a third-party integration platform that syncs and stores their data indefinitely, you are expanding their attack surface and forcing them to audit an entirely new infrastructure stack.

If your architecture relies on data caching, you will spend months arguing with InfoSec teams about encryption standards, SOC 2 boundaries, and data deletion workflows. If your architecture is completely stateless, you bypass these questions entirely.

The Hidden Liability of Sync-and-Cache Architectures

To understand how to build a stateless system, we must first examine why legacy integration platforms default to stateful architectures.

Legacy platforms like Merge.dev and Nango rely heavily on a "sync-and-cache" architecture. In this model, the integration middleware continuously polls the upstream API (like HubSpot or BambooHR), downloads the records, normalizes them, and stores them in a massive multi-tenant database. When your application requests data, it queries the middleware's database, not the actual upstream provider.

Providers build systems this way because it makes certain engineering tasks easier. It allows the middleware to offer fast response times, handle cross-platform filtering, and absorb upstream API rate limits. However, this convenience comes at a catastrophic cost to compliance.

When you use a sync-and-cache platform, customer data is stored indefinitely on infrastructure you do not control. While some platforms are attempting to pivot - Merge.dev recently introduced a specific ZDR toggle for their LLM gateway product - their core unified API products still rely on database persistence. Nango automatically manages data retention in a sync cache, explicitly stating in their documentation that they prune stale payloads after 30 days and perform hard deletions after 60 days of inactivity.

Storing regulated data for 30 to 60 days violates the strict data minimization requirements of SOC 2, HIPAA, and GDPR. Under HIPAA, for example, any entity storing Protected Health Information (PHI) is considered a Business Associate. If your integration tool caches an HRIS payload containing employee medical leave data, that tool is now in scope for HIPAA. You must secure a BAA with them, and your enterprise customer must audit them.

This is why sync-and-cache architectures fail in the enterprise. You are forcing your buyer to accept the security posture of a vendor they did not choose to buy.

What is Zero Data Retention (ZDR) in API Processing?

Zero Data Retention (ZDR) in SaaS integrations means that your integration middleware processes third-party API payloads entirely in memory and never writes customer data to persistent storage.

The payload enters the proxy, gets transformed into a normalized format, gets delivered to your application, and is immediately discarded. There is no cache. There is no database replica. There is no 30-day retention window.

ZDR is becoming a mandatory contractual prerequisite for enterprise deployments processing sensitive data. Major AI providers have established this standard. Anthropic offers specific Zero Data Retention agreements for enterprise customers to guarantee prompts and completions are not stored at rest. Infrastructure providers like API Ninjas market a strict Zero Data Retention Policy where data is processed in milliseconds and discarded immediately, tracking only aggregate usage counts.

When you apply this standard to API integrations, you eliminate the concept of "data at rest" from your middleware layer. You transform your integration pipeline from a data custodian into a transient data processor. This distinction is what allows you to bypass the most difficult sections of the SIG Core questionnaire.

Architecting a Stateless Pass-Through Proxy

To achieve true zero data retention, you must build a stateless pass-through proxy. This architecture requires completely separating your configuration state (which you store) from your execution state (which you discard).

In a ZDR architecture, your database contains zero integration-specific code and zero customer payloads. It only stores the mapping configurations, OAuth tokens, and routing rules required to execute a request.

The Generic Execution Pipeline

When your application requests data from a third-party API, the proxy executes a real-time, in-memory pipeline.

1. Request Ingestion: Your application sends a standard HTTP request to the proxy layer (e.g., GET /unified/crm/contacts).
2. Token Injection: The proxy retrieves the customer's encrypted OAuth token from your secure vault, decrypts it in memory, and attaches it to the outbound request headers.
3. Upstream Execution: The proxy forwards the request directly to the upstream provider (e.g., Salesforce or Workday).
4. In-Memory Transformation: As the upstream provider returns the raw JSON payload, the proxy streams this payload into a declarative mapping engine.
5. Delivery and Destruction: The engine normalizes the data into your unified schema, streams the response back to your application, and allows the memory to be garbage collected. The payload never touches a disk.

Here is how this request flow operates in practice:

sequenceDiagram
    participant Client as Your App
    participant Proxy as Stateless Proxy
    participant Vault as Token Vault
    participant Upstream as Upstream API (Salesforce)
    
    Client->>Proxy: GET /unified/contacts
    Proxy->>Vault: Fetch credentials for connection_id
    Vault-->>Proxy: Encrypted OAuth Token
    Proxy->>Proxy: Decrypt Token (In-Memory)
    Proxy->>Upstream: GET /services/data/v60.0/query<br>Authorization: Bearer [token]
    Upstream-->>Proxy: Raw JSON Payload
    Proxy->>Proxy: Transform via JSONata (In-Memory)
    Proxy-->>Client: Normalized JSON Payload
    Proxy->>Proxy: Drop payload from memory

Declarative Mapping Languages

The technical hurdle in this architecture is transforming complex, deeply nested JSON payloads without writing them to a database for processing. If you try to write custom TypeScript or Python code to map every individual API endpoint, you will introduce memory leaks and stateful variables.

The solution is to use declarative mapping languages like JSONata. JSONata is a lightweight query and transformation language specifically designed for JSON data. By storing JSONata expressions in your database instead of executable code, your proxy can evaluate transformations strictly in memory.

Consider a scenario where you need to normalize a Salesforce Contact record into a standard unified model. You store this JSONata expression in your configuration database:

{
  "id": Id,
  "first_name": FirstName,
  "last_name": LastName,
  "email": Email,
  "phone_numbers": [
    {
      "type": "work",
      "value": Phone
    },
    {
      "type": "mobile",
      "value": MobilePhone
    }
  ],
  "updated_at": LastModifiedDate
}

When the proxy receives the raw Salesforce payload, it applies this exact template against the incoming data stream. The JSONata engine processes the schema translation dynamically. Because the mapping logic is entirely declarative, there is no risk of the proxy accidentally caching the data in a local variable or writing it to a temporary file system.

Handling Edge Cases: Rate Limits and Error Passthrough

Adopting a radical ZDR architecture requires radical honesty about system trade-offs. The most significant trade-off involves how you handle API rate limits.

In a legacy sync-and-cache platform, the middleware absorbs HTTP 429 Too Many Requests errors. If the upstream provider rate limits the connection, the middleware simply queues the request in a database, applies an exponential backoff algorithm, and tries again later.

You cannot do this in a true stateless architecture.

If you queue a request, you are storing state. If you store a payload in a retry queue (like Kafka, RabbitMQ, or a Postgres table) for 15 minutes while waiting for a rate limit window to reset, you have violated Zero Data Retention. You have written the payload to disk.

To maintain ZDR, your proxy must pass the responsibility of rate limit management down to the caller. When an upstream API returns an HTTP 429 error, a stateless proxy passes that error directly back to your application. Your application - which already holds the data and has the right to store it - must handle the retry logic.

Normalizing Rate Limit Headers

While the proxy cannot absorb the 429 error, it can make handling it significantly easier for your engineering team. Every SaaS provider returns rate limit information differently. Shopify uses a leaky bucket algorithm with X-Shopify-Shop-Api-Call-Limit. GitHub uses X-RateLimit-Remaining. Salesforce uses Sforce-Limit-Info.

A top-tier stateless proxy normalizes these disparate upstream headers into standardized IETF rate limit headers before returning the response to the client. The IETF standard defines three core headers:

• ratelimit-limit: The total request quota for the current window.
• ratelimit-remaining: The number of requests remaining in the current window.
• ratelimit-reset: The time at which the rate limit window resets (usually represented as a Unix timestamp or seconds remaining).

When your proxy processes a request, it extracts the provider-specific rate limit data in memory and injects the standardized IETF headers into the outbound response.

HTTP/1.1 429 Too Many Requests
Content-Type: application/json
ratelimit-limit: 100
ratelimit-remaining: 0
ratelimit-reset: 1715432100
 
{
  "error": "rate_limit_exceeded",
  "message": "Upstream provider rate limit exceeded."
}

This approach gives your application the exact telemetry it needs to calculate an accurate backoff delay, without requiring the proxy to store the payload in a persistent queue.

Passing InfoSec: Proving Zero Data Retention to Auditors

Building a ZDR architecture is only half the battle. The other half is proving it to enterprise procurement teams so you can unblock your deals.

When you face a SIG Core questionnaire or a custom TPRM assessment, you need to provide explicit, highly technical documentation that proves your integration middleware acts as a transient processor. You must distance your architecture from legacy sync-and-cache models.

Here is how you should document your pass-through architecture in security whitepapers and vendor questionnaires:

1. Define the Data Lifecycle Explicitly State exactly when data enters memory and when it is destroyed. Use language like: "Our integration architecture utilizes a strict pass-through proxy. Third-party API payloads are processed entirely in memory for schema normalization and are immediately discarded upon HTTP response completion. We do not utilize database caching, message queues, or persistent storage for customer payloads."

2. Clarify the Sub-Processor Boundary Enterprise InfoSec teams are hunting for unmanaged sub-processors. If you use a third-party unified API that adheres to ZDR, you must document their exact role. "Our unified API provider acts solely as a stateless routing and transformation layer. Because they do not write customer data to persistent storage, they are classified as a transient network processor, heavily reducing the compliance scope regarding data at rest."

3. Detail the Logging Policy Auditors will check your application logs. If you achieve ZDR in your database but accidentally log full JSON payloads to Datadog or CloudWatch, you have failed the audit. Explicitly state your logging policies: "Our proxy architecture strictly prohibits logging request or response body payloads. Telemetry is restricted to HTTP status codes, latency metrics, and standardized IETF rate limit headers."

4. Address Rate Limits and Queuing Pre-empt the auditor's concerns about retry mechanisms. "To ensure zero data retention, our proxy does not queue or retry failed requests. Upstream rate limit errors (HTTP 429) are passed directly to the client application, ensuring that payloads are never temporarily written to disk in a retry queue."

By providing these exact architectural guarantees, you give the InfoSec team the evidence they need to check their boxes and approve the deal. You transform integration compliance from a massive liability into a demonstrated engineering strength.

Strategic Next Steps for Engineering Leaders

Enterprise security requirements are not going to soften. As organizations become hyper-aware of third-party risk and supply chain vulnerabilities, sync-and-cache integration architectures will become increasingly impossible to sell into the enterprise.

If you are currently relying on middleware that stores customer data for 30 days, you are sitting on a compliance time bomb. Every deal you move into procurement risks being derailed by a single SIG Core questionnaire.

Transitioning to a stateless pass-through proxy architecture requires a shift in how you handle state, rate limits, and error recovery. Your application must take responsibility for backoff logic, and you must rely on declarative mapping to handle transformations in memory. The engineering effort required to make this shift is significant, but the alternative is watching six-figure enterprise deals die in procurement.

Take a hard look at your current integration pipeline. Trace the exact path a third-party payload takes from the provider to your application. If it touches a disk, a database, or a persistent queue at any point in that journey, you do not have Zero Data Retention.