Developer Experience

We've already made peace with the fact that an MCP server for your documentation is apparently too complex a task (we understand — connecting an API to a well-known open standard must be incredibly challenging). But hey, we've moved on. We're not holding grudges. However, since AI agents are now a very real part of how developers interact with tools like Strapi every day, there's a small, arguably minimal-effort thing you could do for your community: Please publish official Anthropic Agent Skills for Strapi. Agent Skills are structured instruction sets (basically a SKILL.md file in a folder) that teach AI agents — like Claude — how to work with a specific tool, API, or workflow. When a developer uses Claude Code or any Claude-based agent alongside Strapi, a published official Skill would give the AI the right context to: Scaffold content types correctly Generate Strapi-compatible REST/GraphQL queries Work with the Strapi plugin system Handle lifecycle hooks, middlewares, policies Navigate Strapi v5 breaking changes without hallucinating v4 patterns Right now, AI agents working with Strapi are essentially winging it. They mix up v4 and v5 APIs, generate deprecated patterns, and confidently produce code that doesn't work. An official Skill from the Strapi team — written by people who actually know the codebase — would fix this. The best part? Creating a Skill is genuinely easy. It's a markdown file. You can even use /skill-creator in Claude Code to generate one interactively. --- Resources --- Official Anthropic Skills repository: https://github.com/anthropics/skills Agent Skills overview (Claude API Docs): https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview How to create custom Skills (Claude Help Center): https://support.claude.com/en/articles/12512198-how-to-create-custom-skills Skills in Claude Code: https://code.claude.com/docs/en/skills Skill authoring best practices: https://platform.claude.com/docs/en/agents-and-tools/agent-skills/best-practices A well-structured initial Skill for Strapi could realistically be written in a day or two. Possibly a few hours if the author is already familiar with the codebase (which, ideally, someone on the team is). We're not asking for a full MCP server. We're not asking for a plugin. Just a markdown file and some goodwill. Thank you for considering this. We believe in you. Mostly. (Related GitHub issue: https://github.com/strapi/strapi/issues/25935 )

A Strapi MCP would be very useful to connect agents to Strapi. RFC: https://github.com/strapi/strapi/discussions/25398

Strapi's validation and typing setup has kind of evolved organically as the product grew, and it left traces. Right now, data structures get defined all over the place: frontend forms, backend APIs, Content API, Admin API, plus TypeScript types that often don't quite sync up with the actual runtime behavior. The result is several duplication, things drifting out of alignment, and a codebase that's trickier to work with than it needs to be. Bringing in Zod as Strapi go-to schema layer allows to have just one unified definition handling both validation and typing across the whole stack. One spot to define structure. One source of truth for what data should look like and what's valid. For contributors, this means way less time wrestling with overlapping systems and way more confidence in making changes. For devs building on Strapi, it would mean more consistency and reliability. What the Admin UI enforces actually matches what the API enforces. Plugin contracts are clear and stable. Plus, with Zod 4's built-in OpenAPI schema support, this sets us up for way better API docs and stronger guarantees for all the tools and integrations people build on Strapi.

We have an active Microsoft SSO (Azure AD / Microsoft Entra ID) subscription and would like to integrate it with the Strapi Admin panel in order to bypass the default Strapi login screen and authenticate users using Microsoft SSO instead. We are currently using Strapi v5 (Community Edition). We would like to know: Is it officially supported to replace or bypass the default Admin login in the Community Edition? Is there a recommended or supported way to integrate Microsoft OAuth2 / OpenID Connect for Admin authentication? Are custom authentication providers for Admin available in the Community Edition? Is Admin SSO functionality restricted to the Enterprise Edition?

The plugin library is painful to navigate on the strapi website. Please do something about it. For example, how do I browse to the very last plugin in the marketplace? I have to click view more after every 12 plugins till I reach the 248th plugin. Kill me now

I would like to exclude fields (I want to exclude id field) from GET responses using the REST API, including nested elements added with populate attribute.

Currently, any user with find or findOne permission on a content-type can access draft entries by using the status parameter (e.g., status: DRAFT in GraphQL or status=draft in REST). This makes it difficult to keep unpublished content private, as there's no built-in way to control draft access per role. ### Suggested Solution It would be great to have a separate permission for accessing draft content, something like "find drafts" or "findOne drafts" in the role settings. This way, admins could decide who can view unpublished content without affecting regular read permissions. ### Use Case Draft entries often contain work-in-progress content that shouldn't be visible to end users. Currently, anyone with a valid API token or public access can query draft content, which could lead to unintended exposure of sensitive or unfinished information. ### Current Workaround Currently, the only way to prevent this is by implementing a custom middleware, but this feels like something that should work out of the box. The expectation with Draft & Publish is that content becomes visible once it's published — not before.

Add native support for JSON-LD (JavaScript Object Notation for Linked Data) in Strapi content types and APIs. JSON-LD is a widely adopted format for structuring linked data and improving content discoverability across web platforms. Official support would enable developers and content teams to easily expose semantic relationships and metadata from Strapi-based sites. Example Use Case A “Blog Post” content type could automatically output structured data such as: { "@context": "https://schema.org", "@type": "BlogPosting", "headline": "Understanding Headless CMS", "author": { "@type": "Person", "name": "Jane Doe" }, "datePublished": "2025-12-18" } This would improve search visibility and simplify content syndication.

In order to make a put request in V5, you need to know the entire schema of the nested object. This is bad. Here's my use case. I have a course. The course has Modules (collection type). It also has Lessons (collection type). Each lesson has some data about the lesson overall (time to complete, thumbnail, etc.) and each lesson also has a list of "screens" (component) containing the lesson information, which have their own nesting of components and data. I have a list of 200 images, each of which corresponds to a screen, and I want to update the screens in strapi with the corresponding images. I understand that you can't just send the one key/value pair you need updated with a PUT request: frankly, this is annoying but fine. One might think, instead, you could query the API for the object, copy the response, and send it back with the updated K/V pair, but you can't do that either, because all of the other metadata (documentID, etc.) in the response will give a 400 error. You need to either know the schema of the object or know which fields are metadata and strip them out to update the item. This is really just a very bad system that makes it incredibly hard to update things with the API. Clicking through hundreds of lessons on strapi to add the images would be a complete waste of my day and probably take 8 clicks or more per lesson. I spoke with Paul and Beogie on Strapi Office Hour discord and they advised me to make a post here with this issue.

The current Data Import/Export feature is NOT USABLE. This was reported in https://github.com/strapi/strapi/issues/20270 but closed as "not planned". This is a basic and crucial feature of a CMS, how can it not be intended/planned?!