[Request]: Validation rules could be exported

[pellyadolfo]

Summary

We have a client application that inserts very large JSON files with many content types and relations in Strapi. We would like to be able to validate in our client application these JSON files, with the same rules that we have defined in Strapi, before trying the insertion.

Is there a way we can mimic the Strapi validation on insertion on our custom typescript client app?

Why is it needed?

Inserting a very large file can be a pain on trial and error fixing errors on Strapi insertion so we would like verify insertion rules outside Strapi before trying Strapi insertion.

Suggested solution(s)

Somehow externalize validation rules to a file we can use, the same you create a generated file with content types, another file could either contain validation rules, validation logic or a validation configuration. We could take this file an embed in our custom logic.

Related issue(s)/PR(s)

We know you run a validation with Zod in export / import. I do not know if there is a file or files we can take from this process and use in our logic.

[github-actions]

🤖 I've analyzed your question and here's what I found:

Thanks a lot for taking the time to explain your use case and for thinking about data quality before sending large payloads to Strapi — that’s a very valid concern and a great idea for improving reliability in your workflow.

---

1. Current state: validation in Strapi vs. external clients

Right now, Strapi’s validation is primarily:

• Defined in the content-type schemas (e.g. required, minLength, maxLength, min, max, unique, etc.) [Model attributes]
• Enforced on the server side when:
  • Controllers sanitize and validate queries and input [Controller sanitization; Custom controller validation]
  • Services and lifecycle hooks run and can throw errors (e.g. using ApplicationError) [Services & lifecycles]

There is no officially documented mechanism today to:

• Export all validation rules as a ready‑to‑use schema (e.g. Zod/JSON Schema) for use in an external TypeScript client, or
• Reuse the same internal Zod schemas that are used for data import/export validation in a supported way.

So your request is effectively a feature request rather than something that can be done via a documented, stable API.

---

2. What you can leverage today

Even though there isn’t a one‑shot “export validation rules” feature, there are a few building blocks you can use:

a. Use content-type schemas as the source of truth

Each content-type schema already contains the basic validation rules:

{
  "attributes": {
    "title": {
      "type": "string",
      "minLength": 3,
      "maxLength": 99,
      "unique": true
    },
    "description": {
      "type": "text",
      "required": true
    }
  }
}

These attributes and their validation properties (required, minLength, maxLength, min, max, etc.) are documented and stable. [Model attributes]

Possible approach for your client app:

1. Treat the Strapi content-type schemas as the canonical definition.
2. Write a small script (inside your Strapi project or as a separate tool) that:
   • Reads the JSON schema files from ./src/api/**/content-types/**/schema.json
   • Transforms the attributes + validation properties into:
     • A JSON configuration your client can consume, or
     • Generated Zod/JSON Schema/TypeScript validators on your side.
3. Commit or bundle the generated validators into your client app and run them before sending the big JSON payload to Strapi.

This is not an official feature, but it’s a safe pattern because it relies on documented schema fields.

b. TypeScript typings for content types (structure, not full validation)

Strapi 5 can generate TypeScript typings for your content-type schemas via:

yarn strapi ts:generate-types --debug
# or
npm run strapi ts:generate-types -- --debug

This creates a types folder at the project root with typings for your schemas. [Generate typings]

These typings:

• Help you ensure shape/structure correctness in TypeScript (e.g. required fields at type level),
• But they do not currently expose all runtime validation rules (like minLength, max, etc.) as a ready‑to‑use validation schema.

You could still:

• Use these types in your client to ensure structural correctness, and
• Combine them with the schema‑parsing approach above to enforce more detailed rules.

---

3. About Zod and import/export

You’re right that Strapi uses validation (including Zod) internally for the data import/export feature (strapi export / strapi import). [Data export; Data import]

However:

• The knowledge sources do not document any public, supported way to:
  • Extract those Zod schemas, or
  • Reuse them directly in an external client.
• So we can’t recommend relying on internal Zod definitions as a stable integration point.

If you need a robust, long‑term solution, basing your client‑side validation on the documented content-type schemas is the safest path.

---

4. Suggested next steps / feature request

Your idea of:

“another file could either contain validation rules, validation logic or a validation configuration”

is very much aligned with what many teams would find useful (especially for bulk imports and complex clients).

Given that there is no official feature for this today, the best next step is to:

• Submit (or upvote, if already present) a feature request on the public roadmap:
  👉 https://feedback.strapi.io

In that request, you might reference:

• Your need to validate large JSON payloads client‑side,
• Desire for:
  • Exportable validation schemas (e.g. JSON Schema/Zod),
  • Or a CLI command similar to ts:generate-types but for validation rules.

This helps the core team gauge demand and design something stable and documented.

---

5. Where to discuss further

If you’d like to brainstorm implementation patterns or see how others handle similar bulk‑import validation, you can also reach out to the community:

• Strapi Forum: https://forum.strapi.io
• Discord: https://discord.strapi.io

Both are great places to share your approach (e.g. schema‑to‑Zod generator) and get feedback.

---

To summarize:

• There is no built‑in, documented way to export Strapi’s validation rules as reusable Zod/JSON schemas for a client app.
• You can:
  • Use content-type schemas (and their validation properties) as the source of truth,
  • Optionally combine them with generated TypeScript types,
  • Build your own generator that turns those schemas into client‑side validators.
• For a first‑class, supported solution, this should be tracked as a feature request on https://feedback.strapi.io.

Thanks again for raising this — it’s a very reasonable need, and your feedback is valuable for shaping how Strapi can better support large‑scale data ingestion workflows in the future.

📚 Relevant documentation:

• Command Line Interface (CLI) - strapi export
• Community & Support
• Controllers - Sanitization and Validation in controllers
• Controllers - Sanitization and validation when building custom controllers
• Data export
• Data import
• Error handling - Services and models lifecycles
• How to access to configuration values from the code
• Models - Database validations and settings
• Models - Model attributes
• Server API for plugins - Configuration
• Strapi Client
• Strapi Support Policy - Community resources
• TypeScript development with Strapi - Generate typings for content-types schemas

---

ℹ️ This response was generated automatically. If this doesn't fully answer your question or if you need further assistance, please mention @pwizla in a comment and a human maintainer will help you.

You can also try our interactive AI chat for more detailed assistance.

💡 For feature requests or product feedback, visit feedback.strapi.io.

[pellyadolfo]

@pwizla

A second approach I forgot to mention would be generating the OpenAPI schema and using some of the existing OpenAPI validation tools to perform this validation. How reliable is your OpenAPI generation at the moment and what differences should I expect between this OpenAPI validation and the validation performed by Strapi with Zod?

NOTE: Maybe the types generated by the bot are OpenAPI types as well.

[pwizla]

Thanks for your question and suggestion, @pellyadolfo!
I'll pass this to the core Strapi engineering team and get back to you as soon as possible.

[pwizla]

Thank you for your patience, @pellyadolfo.

I checked with the core engineering team: the validation logic used internally (e.g. for import/export) is considered internal API and is not currently exposed as a stable/public integration surface. It would require additional work before being safely exportable.

Regarding the OpenAPI approach: it can help with structural/type-level validation, but it won’t fully match Strapi’s runtime validation (which may include additional server-side logic).

You may find additional technical context in the contributors documentation.