Feature Requests

PUT requests are too difficult
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.
0
Monorepo support: limit auto-deploys to base directory changes or/and enable CI-controlled deployment
Strapi Cloud already allows configuring a Base directory for a branch (e.g. strapi/ inside a monorepo). This correctly defines where the Strapi application is located for the build, but auto-deploys are still triggered on every commit to the branch, even if no files inside the base directory were changed. In monorepo setups (Nx, Turborepo, Yarn/pnpm workspaces), this leads to: – Unnecessary Strapi Cloud deployments when changes only affect other apps or libraries in the repository. – Difficulty integrating Strapi Cloud into a unified release process where CI decides which apps need to be deployed. – The need to choose between auto-deploying on every commit, or disabling auto-deploy and having no supported way to trigger strapi deploy from CI (because the CLI requires interactive login). Requested enhancements: 1) Path-aware auto-deploy: When a Base directory is configured, only trigger auto-deploys if commits modify files under that directory. 2) CI-friendly, non-interactive deployment: Provide a CI/service token or similar mechanism (e.g. STRAPI_CLOUD_TOKEN) so that strapi deploy can be executed from CI/CD pipelines without a browser-based login flow (like Vercel, Netlify, Amplify). These changes would make Strapi Cloud behave predictably in monorepos, reduce redundant deployments, and allow modern CI/CD pipelines (Nx/Turborepo/other monorepo tools) to control when Strapi is actually deployed.
0
Load More