How to Build ERP Integrations Without Storing Customer Data

B2B SaaS teams face a brutal reality when moving upmarket. You build a financial workflow tool, an AI agent, or an analytics platform that needs to read and write data to enterprise ERPs like NetSuite, SAP, or Microsoft Dynamics 365. The engineering team ships the integration. The product looks great in demos. Then, the deal dies in procurement.

If you are trying to integrate your B2B SaaS product with enterprise ERPs, and your integration middleware writes any customer financial data to a database, you are building a compliance liability. Your InfoSec review will fail, your deal will stall, and your competitor who figured out pass-through architecture will close the contract instead. If you want to know how to build ERP integrations securely, the answer requires abandoning the traditional sync-and-cache model entirely in favor of a pass-through, zero data retention architecture.

This guide breaks down exactly why caching ERP data is an architectural mistake that kills enterprise deals, the technical realities of integrating with complex systems like NetSuite and SAP, and how to build a stateless integration layer that normalizes data on the fly and passes enterprise procurement without drama.

The Enterprise Procurement Wall: Why Caching ERP Data Kills Deals

Enterprise deals die in procurement, not in product demos. The number one thing that kills them is your data storage architecture.

When your sales team pushes a six-figure contract to the final stage, the buyer's InfoSec team sends over a security questionnaire. Enterprise procurement teams use data residency and security questionnaires as a primary filter for software vendors. One of the first questions you will encounter is: "Does the vendor store, cache, or persist any customer data? If so, describe the data types, retention periods, and storage locations."

If your integration layer syncs NetSuite general ledger entries, SAP purchase orders, or Dynamics 365 payroll data into a centralized database just to transform it before sending it to your application, you have to answer "Yes."

That single "Yes" triggers a massive compliance cascade. You are now legally responsible for securing a duplicate copy of your customer's most sensitive financial data. According to IBM's 2024 Cost of a Data Breach Report, the global average cost of a data breach reached a record $4.88 million - a 10% increase from the previous year. Enterprise buyers know this. They do not want their financial data sitting in your middleware provider's AWS account.

Traditional integration platforms force you into this liability. They pull data from the upstream ERP, store it in an intermediate database, apply transformation logic, and then push it to your application. This expands the attack surface. It complicates SOC 2 audits. It forces you to sign complex Data Processing Agreements (DPAs) that delay contracts by months.

To bypass this procurement wall, you must prove to the buyer that their data never rests on your integration infrastructure.

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

Zero Data Retention (ZDR) is an architectural design pattern where an integration layer processes third-party API payloads entirely in memory, never writing them to persistent storage. The middleware acts as a stateless proxy. It authenticates the request, transforms the payload, forwards it between your application and the upstream ERP, and discards the payload the moment the response is delivered.

In a strict ZDR architecture, there are:

• No database writes: Payload bodies are never inserted into a relational or NoSQL database.
• No message queue persistence: Event streams and webhooks are processed ephemerally without being dumped into long-term storage queues.
• No payload logging: Application logs record the transaction status (e.g., HTTP 200 OK) but strip the actual request and response bodies.

This approach is becoming a strict requirement for enterprise compliance. As noted by CData Software, ZDR ensures that sensitive data is processed in-memory and never written to persistent storage, which is critical for meeting GDPR data minimization principles and HIPAA compliance.

If you want to understand the foundational concepts behind this, read our guide on what zero data retention means for SaaS integrations. The core takeaway is that by eliminating the cache, you eliminate the compliance liability. You shrink your attack surface to zero at rest.

The Hidden Risks of Traditional iPaaS and ETL Workflows

For the last decade, connecting to enterprise systems meant relying on traditional Integration Platform as a Service (iPaaS) or Extract, Transform, Load (ETL) workflows. Platforms like MuleSoft popularized an API-led connectivity model that often relies on a three-tier architecture (System, Process, Experience APIs). While powerful for internal enterprise orchestration, this model frequently depends on stateful orchestration, caching, and data synchronization.

When B2B SaaS vendors use these legacy platforms to build customer-facing integrations, they inherit hidden risks.

Legacy platforms pull data into centralized systems for processing. As IntelliStack points out, creating copies of sensitive data expands the risk surface and complicates compliance with strict regulations. If a vulnerability is discovered in the iPaaS provider's centralized database, your customer's ERP data is exposed.

Beyond security, there is a performance penalty. Caching architectures introduce latency because data must be written to disk, indexed, and retrieved. Cloud-native integrations built on stateless, pass-through architectures offer lower latency and error rates. A recent study on ERP integrations published on ResearchGate showed cloud-native solutions are 33% faster in latency and have a lower error rate compared to on-premise ESB/ETL queues.

When your enterprise customer announces they are migrating legacy on-premise ERPs to cloud APIs, a sync-and-cache architecture becomes a massive bottleneck. The synchronization jobs fail during cutover, state consistency breaks, and your engineering team spends weeks manually reconciling duplicate records.

How to Architect a Pass-Through ERP Integration

Building a pass-through ERP integration requires a fundamental shift in how you handle data mapping, authentication, and request execution. You cannot rely on hardcoded integration scripts that pull data into a local database.

Instead, you need a generic execution pipeline driven by declarative configuration. Here is how you architect it.

1. The Generic Execution Pipeline

To achieve true zero data retention, your middleware must execute API calls without relying on integration-specific code. Truto achieves this by handling 100+ third-party integrations without a single line of integration-specific code in its database or runtime logic.

Instead of writing custom Python or Node.js scripts for NetSuite and SAP, you define a Unified Model. This model maps your application's standard data structure (e.g., a generic Invoice object) to the provider's specific schema using a transformation language like JSONata.

When your application requests an invoice, the middleware:

1. Receives the request.
2. Looks up the declarative mapping configuration for the specific ERP.
3. Translates the request into the upstream provider's exact format (e.g., constructing a NetSuite SuiteQL query) entirely in memory.
4. Dispatches the HTTP request to the ERP.
5. Receives the response.
6. Transforms the response back into your Unified Model.
7. Returns the response to your application and clears the memory buffer.

sequenceDiagram
    participant App as Your B2B SaaS
    participant Proxy as Stateless Proxy Layer
    participant ERP as Upstream ERP (SAP/NetSuite)

    App->>Proxy: GET /unified/invoices
    Note over Proxy: Load JSONata Mapping<br>Transform to SuiteQL (In-Memory)
    Proxy->>ERP: POST /query (SuiteQL)
    ERP-->>Proxy: Raw ERP JSON Response
    Note over Proxy: Transform to Unified Model<br>Discard Raw Payload
    Proxy-->>App: Standardized Invoice JSON

This architecture is particularly vital for modern AI workflows. If you are building AI features, refer to our deep dive on zero data retention AI agent architecture to see how this pipeline secures LLM tool calling.

2. Handling Complex API Surfaces via Proxy

Enterprise ERPs rarely offer clean RESTful endpoints. NetSuite requires complex SuiteQL queries or SuiteScript deployments. SAP relies on heavy OData protocols. Some modern tools use GraphQL.

To maintain a stateless architecture, your integration layer must act as a Proxy API. For example, Truto's Proxy API allows developers to expose complex GraphQL-backed integrations as RESTful CRUD resources on the fly. It uses placeholder-driven request building to construct dynamic queries based on the incoming request context, execute them against the upstream provider, and extract the relevant nodes from the response - all without caching the underlying data.

If you need to map custom fields, you do it declaratively. You can learn exactly how to create ERP-specific mapping guides to handle these edge cases without writing stateful code.

Handling Rate Limits and Pagination Statelessly

The most common objection to pass-through architecture is handling API limits. Engineers often assume they need a database to queue requests, track rate limits, and manage pagination state. This is false. You can handle all of this statelessly.

Normalizing Rate Limits

When an upstream API like NetSuite or SAP returns an HTTP 429 Too Many Requests error, traditional middleware absorbs the error, places the request in a retry queue, and waits. This requires persistent state.

A zero data retention architecture takes a different approach: it normalizes the rate limit information and passes the responsibility to the caller.

Truto does not retry, throttle, or apply backoff on rate limit errors. When an upstream API returns an HTTP 429, Truto passes that error directly to the caller. However, because every ERP returns rate limit data differently (some in headers, some in the body, some not at all), Truto normalizes upstream rate limit info into standardized headers per the IETF specification:

• ratelimit-limit: The total request quota.
• ratelimit-remaining: The remaining quota.
• ratelimit-reset: The time window reset point.

Your application receives the 429 and the standardized headers. Your application - which already maintains state for its own background jobs - applies exponential backoff and retries the request. The middleware remains perfectly stateless.

// Example: Client-side handling of normalized 429 errors
async function fetchInvoicesWithRetry(url, maxRetries = 3) {
  for (let attempt = 0; attempt < maxRetries; attempt++) {
    const response = await fetch(url);
    
    if (response.status === 429) {
      const resetTime = response.headers.get('ratelimit-reset');
      const waitMs = (resetTime * 1000) - Date.now();
      
      console.warn(`Rate limited. Waiting ${waitMs}ms before retry.`);
      await new Promise(resolve => setTimeout(resolve, waitMs));
      continue;
    }
    
    if (!response.ok) throw new Error('API Request Failed');
    return await response.json();
  }
  throw new Error('Max retries exceeded');
}

Stateless Pagination

Pagination follows the same principle. Instead of the middleware downloading all 10,000 records, caching them, and serving them to you in chunks, the middleware normalizes the pagination cursor.

When you request page one, the middleware translates your generic cursor parameter into the ERP's specific pagination format (e.g., an OData $skip token). The ERP returns the data and a next-page token. The middleware translates that token back into a generic cursor and passes it to your application. Your application stores the cursor and passes it back on the next request. The state lives with the client, not the middleware.

Securing the Connection: OAuth, Webhooks, and Ephemeral Processing

Maintaining a zero data retention posture requires strict control over how authentication tokens and asynchronous webhooks are handled.

Ephemeral Webhook Processing

ERPs frequently send webhooks when a purchase order is approved or a journal entry is posted. Traditional platforms ingest these webhooks into a Kafka or RabbitMQ queue, writing the payload to disk before processing it. If that queue is breached, the financial data is compromised.

In a ZDR architecture, webhooks are processed ephemerally. The middleware receives the HTTP ingestion, verifies the cryptographic signature in memory, maps the vendor-specific event (e.g., netsuite.transaction.created) to a unified event format, and immediately attempts outbound delivery to your application.

If the delivery fails, the middleware does not store the payload indefinitely. It relies on the upstream provider's retry mechanics or drops the event after a short, memory-bound retry window. The payload is never written to a database schema.

Secure OAuth Token Management

Authentication state is the only data the integration layer should persist. You must store OAuth access tokens and refresh tokens to maintain the connection. However, these tokens must be strictly isolated from the data plane.

The platform schedules work ahead of token expiry. Truto refreshes OAuth tokens shortly before they expire, ensuring that when an API call is made, a valid token is already available in memory. This prevents the middleware from having to pause a request, execute a database write to update a token, and then resume the request. The token lifecycle operates completely independent of the data payload lifecycle.

Strategic Next Steps

Building ERP integrations does not have to mean taking on massive compliance liabilities. By adopting a pass-through, zero data retention architecture, you can give your product read and write access to NetSuite, SAP, and Dynamics 365 without ever caching a single financial record.

Stop letting procurement teams kill your enterprise deals because of your integration middleware. Architect for statelessness. Process data in memory. Pass rate limits to the caller. Use declarative mapping instead of hardcoded integration scripts.

When you eliminate the cache, you eliminate the risk. Your InfoSec review will pass, your engineering team will spend less time managing stateful queues, and your sales team will close the enterprise contracts they fought for.