These commands require a workspace ID, either from your profile or via the
-w flag. A tenant only accepts Deployment Requests if it has Require Deployment Request enabled (required_reviewers > 0) — see xano tenant create/edit.List Deployment Requests
Each request shows its ID, title, status, target tenant, release, author, and current approval count against the required minimum. Use-o json for the full JSON response.
Get Request Details
Returns the request’s full detail: title, description, status, tenant, release, base release (the tenant’s live release when the request was created), author, approval/comment activity, and resolution details once closed or deployed.Create a Request
Creating a request doesn’t deploy anything. The release only reaches the tenant once the request is approved (see
set_status) and, if Allow Approve & Deploy isn’t enabled on the tenant, manually deployed.Edit a Request
Only the request’s author can edit it, and only while it’s in an editable status (draft, pending, or changes_requested).
Link a New Release
If the release you want to deploy changes after a request is opened — for example, you need to fix something a reviewer flagged — link the new release as a revision rather than opening a new request: Linking a new revision keeps the request’s discussion and history intact, but marks any existing approvals as outdated — reviewers need to approve the new revision before it can deploy.Approve, Request Changes, or Close a Request
You can’t approve or request changes on a request you authored yourself. Once a request has enough distinct approvals to meet the tenant’s required minimum, it becomes eligible to deploy — automatically if the tenant has Allow Approve & Deploy enabled, otherwise via
xano tenant deploy_release or a manual deploy in the console. Approvals are single-use: once a request’s approval has been used to deploy a release, redeploying it needs a fresh approval.