[Request]: Proper way to override validation error messages through Graphql Plugin

[rahimlis]

Summary

I need custom validation error messages for the backend that would look like
content-type.validation.field.error-type. But I found it is very cumbersome to implement without doing a lot of additional things like overriding lifecycles, adding graphql middlewares etc.

{ "errors": [ { "message": "This attribute must be unique", "path": [ "createMarketingLead" ], "extensions": { "code": "BAD_USER_INPUT", "error": { "name": "ValidationError", "message": "This attribute must be unique", "details": { "errors": [ { "path": [ "email" ], "message": "This attribute must be unique", "name": "ValidationError", "value": "aa@aas.aa" } ] } } } } ], "data": { "createMarketingLead": null } }

Instead of "This attribute must be unique", it could be a marketing-lead.validation.email.required, which in turn allows for end users to hold the i18n strings.

Why is it needed?

The messages are currently in unorganized format. A central coding mechanism would be great addition to the framework and organize error handling structurally.

Suggested solution(s)

No response

Related issue(s)/PR(s)

No response

[github-actions]

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

Hi there! 👋

Thank you so much for taking the time to share your feedback and use case with us. We really appreciate your thoughtful suggestion and understand how important it is to have structured, customizable validation error messages—especially for internationalization and consistent frontend handling.

Current State & Workarounds

At the moment, Strapi’s error handling system does provide a standard error response format for both REST and GraphQL APIs, but it does not natively support customizing validation error messages to use keys like content-type.validation.field.error-type out of the box. The default validation errors (such as uniqueness or required field violations) are generated internally and are not easily overridden without custom logic. This means that, as you’ve noticed, implementing such a system currently requires additional work—like custom lifecycles, service overrides, or GraphQL middlewares—to intercept and reformat error messages before they reach the client [Error handling].

Example: Custom Error Handling in Services or Lifecycles

You can throw custom errors in your service or model lifecycle hooks using Strapi’s error classes. For example, in a lifecycle hook:

// ./src/api/[api-name]/content-types/[api-name]/lifecycles.js
const { errors } = require('@strapi/utils');
const { ApplicationError } = errors;

module.exports = {
  beforeCreate(event) {
    // Custom validation logic
    if (!event.params.data.email) {
      throw new ApplicationError('marketing-lead.validation.email.required');
    }
  },
};

This approach allows you to control the error message, but it does require you to manually implement validation logic for each field and error type [Services and models lifecycles].

GraphQL Middleware

Similarly, you can use GraphQL middlewares to intercept and modify error responses, but this also involves extra setup and maintenance [GraphQL plugin customization].

Feature Request & Next Steps

Your suggestion for a more centralized and configurable error message system is a great idea and would be a valuable addition to Strapi. Since this is not currently supported natively, I recommend submitting your feature request to our public feedback board at https://feedback.strapi.io. This helps our product team track demand and prioritize improvements.

Additional Resources

• Error handling documentation
• GraphQL plugin customization
• Community Forum and Discord for sharing workarounds or discussing with other community members

If you feel this is a core product limitation or bug, please let us know and we can flag it for the core team (@pwizla) to review for a potential transfer to the main Strapi repository.

Thanks again for your input and for helping make Strapi better! If you have any more questions or want to discuss possible workarounds, feel free to reach out here or on our community channels. 🚀

📚 Relevant documentation:

• Community & Support
• Error handling
• Error handling - Controllers and middlewares
• Error handling - Default error classes
• Error handling - Policies
• Error handling - Services and models lifecycles
• Examples cookbook: Custom policies - Sending custom errors through policies
• Examples cookbook: Custom policies - Using custom errors on the front end
• GraphQL plugin - Custom configuration for resolvers
• GraphQL plugin - Customization
• GraphQL plugin - Middlewares
• Locales & translations - Extending translations
• Models - Database validations and settings
• Models - Model attributes
• Models - Plugin options

---

ℹ️ 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.

[rahimlis]

@pwizla

[pwizla]

HI @rahimlis. Thanks for pinging me. The AI bot was right: Your request is actually a feature request, not a documentation request, because there's nothing missing from docs on this topic, it's just that you can't do it with the current Strapi features and APIs. Your request "A central coding mechanism would be great addition to the framework and organize error handling structurally" is indeed a great idea, I suggest you submit this on feedback.strapi.io
If you think there is a bug somewhere, please feel free to submit a new issue of type🐛 Bug Report to the main Strapi code repository here.

I will now close this documentation issue but if you have other inquiries about the topic, feel to re-open it with additional details. Thank you, have a nice day!