Version 7.21.0 shipped in Q3 2025 with AI-assisted schema generation, support for FerretDB as a database backend, an inline filter in the content list and the X-Fields header on all content endpoints. Here is what each of those changes means when you build or operate a Squidex installation.
Q3 2025 brought one release, 7.21.0, on 23 July 2025. It touches three areas that are easy to feel in daily work: how you create schemas, which database you can run Squidex on, and how much data your content queries move over the wire.
The sections below go through the changes that matter most, and then group the smaller fixes at the end.
The management UI can now generate schemas with AI support. Instead of adding a schema and then clicking through every single field definition, you describe what you need and get a schema as a starting point.
This is most useful in two situations. The first is prototyping, when you know roughly what a content type should look like but do not want to spend ten minutes on field types, names and settings before you can put the first entry in. The second is onboarding, when someone new to Squidex needs to see a realistic schema before they understand the difference between a reference field, a component and an array.
What you get is still a normal Squidex schema. You can rename fields, change types, add validation and adjust the UI settings afterwards, and you can export it as JSON like any other schema. Treat the generated result as a draft that you review, not as a final model.
The backend now supports FerretDB. FerretDB implements a MongoDB-compatible interface, and because of that compatibility layer this change probably also opens the door to CosmosDB and DocumentDB, though those two are not confirmed.
This matters if your infrastructure rules constrain which databases you are allowed to operate. Squidex has always stored its content and events in MongoDB, and for some teams that is a fixed dependency they cannot take. With FerretDB you have another option for the storage layer without changing anything about how you use the API or the UI.
If you are evaluating this, plan for a test installation first. Compatibility layers rarely cover a database feature for feature, so run your own workload against it, check the queries your application depends on and verify backup and restore before you move production data.
The X-Fields header is now supported for all content endpoints. Previously it worked only on some of them, so you had to know which endpoint would honour it and which would return the full payload.
X-Fields lets the client decide which fields come back in the response. If a list view in your frontend needs a title, a slug and a publication date, you do not have to download the long text body and every localized variant of every other field to render it.
curl "https://cloud.squidex.io/api/content/my-app/articles" \
-H "Authorization: Bearer $TOKEN" \
-H "X-Fields: id,data/title,data/slug"
The practical effect is smaller responses and less parsing work in the client. It is also a good habit for mobile clients and for edge functions where payload size shows up directly in latency and cost. Because the header now works everywhere, you can apply the same rule in every part of your integration code instead of making exceptions.
The content section has a new inline filter. Filtering content is not new in Squidex, but having it inline means you stay in the content list while you narrow it down, instead of moving your attention to a separate query surface.
This is aimed at editors as much as at developers. Anyone who works in an app with thousands of entries spends real time looking for the right one, and the faster path to a filtered list is a change they will notice every day. For developers it is also a convenient way to build up a filter interactively before you copy the equivalent query into your application code.
The release also has a new dialog to create apps, which replaces the previous flow when you start a new app in the UI, plus a handful of smaller UI improvements. Angular was updated to its current version, which keeps the frontend on a supported dependency line and is the kind of maintenance that pays off later.
On the rules side, three fixes landed. The prepare step and the error handling for scripts were corrected, the URL properties of steps changed to strings, and the status of cancelled events is now shown properly, so the rule event list reflects what actually happened. If you build rules with scripts, or if you have been confused by how a cancelled event was displayed, this release is worth the upgrade on its own.
7.21.0 is available as a Docker image and on Squidex Cloud. As always, read the release notes before you upgrade a self-hosted installation, take a backup of your database first, and check the rules that use scripts after the update, since that is the area with the most behaviour changes in this release.
The full changelog for every release lives in the GitHub repository, and questions about a specific change are best raised in the support forum or as a GitHub issue.