Zero Data Retention on Runware, now available

We're pleased to now offer Zero Data Retention (ZDR) on the Runware API, for enterprise organizations with strict data privacy, confidentiality, or compliance requirements. ZDR is available on a case-by-case basis: once enabled for an account, Runware processes API requests without retaining the content of those requests afterward, while still keeping what's needed to bill and operate the service reliably. It builds on enterprise credentials Runware already holds, including ISO 27001 certification, GDPR compliance, and SSO/SAML support for enterprise authentication.

What Zero Data Retention covers

Only the data needed to bill and operate the service is kept. Everything you send is discarded, and everything a model generates is deleted once its TTL expires.

With ZDR enabled on an account:

• Prompts and text generations are processed in memory only, then discarded.
• Input media, including images, masks, video frames, and audio, is not retained.
• Generated outputs expire based on their TTL (60 seconds by default) rather than being stored long-term.

What does persist is the technical metadata required for billing, debugging, reliability monitoring, and security auditing, along with billing records and account authentication data that Runware is required to retain for legal reasons.

Model coverage visible on every model card

At time of writing, ZDR covers:

• Runware-hosted models marked Runware Optimized in the model catalog
• Community and user-uploaded models, which run on the same infrastructure
• All Black Forest Labs models, both self-hosted FLUX and those served through their API
• Third-party provider models: for models hosted by upstream providers, Runware forwards your requests to that provider. We have ZDR agreements with some of these providers. For the full list, and for details on how each provider handles your data, contact our team.
• The following language models:
  • DeepSeek-V4-Flash-0731
  • DeepSeek-V4-Pro-0423
  • DeepSeek-V4.1-Flash
  • Gemma 4 31B
  • GLM-5.2
  • GLM-5.3
  • GLM-5.3-Flash
  • gpt-oss-120b
  • gpt-oss-safeguard-20b
  • Kimi K3
  • Shieldstral 1.0 3B

Any other model is not covered by ZDR, even when your organization has it enabled.

To make this easy to check programmatically, eligible models now carry a zdr: true field directly on their model card, so your own tooling, or an AI agent working on your behalf, can confirm ZDR coverage for a given model before sending it any request.

This list isn't fixed: if there's a particular model you need ZDR coverage on, get in touch with our team to discuss it.

Here's what that looks like on the Gemma 4 31B model card:

Practical considerations

Because generated outputs expire on their TTL rather than being kept in your usage history, download results before the TTL passes, or request base64Data or dataURI output types to receive files directly in the response instead of via an expiring URL. The dashboard's usage log will continue to show request metadata, but not the request or response payloads themselves.

Full details

For the complete breakdown of what's retained, what isn't, and how ZDR is scoped across model types, see the Zero Data Retention documentation.

FAQ