These methods work with policies that already exist. You create, test and publish policies on a beta key in the Developer Portal or with the CLI. Your production key gets them after a production review by Para. See Go to production.
What the server secret can do
The server secret acts for your app, not for a user. It can read every active policy, including policies that target specific users or wallets. It can read a user’s consent status and parameter values, set roles and attributes, bind wallets to authorization scopes, change approval settings, read spend usage, read or cancel approval cases, and approve or reject reviews opened by its own signing requests. It cannot act for a user: it cannot grant consent, approve or reject an approval case, or change a user’s own parameter values. Users do those through the client SDKs or Portal. It also cannot create or publish policies. An authorization scope is an ID your backend chooses, such as a team or organization ID. You bind wallets to a scope, assign roles and attributes inside it, and store approval settings per scope.Para enables conditional approvals and adjustable parameters separately for each API key, so your beta and production keys are set up independently. Until a key has conditional approvals,
replaceUserApprovalAssignments, setWalletAuthorizationScope, updateApprovalConfiguration and resetApprovalConfiguration fail with 403 PERMISSIONS_V2_EXTENSION_UNAVAILABLE. Until it has adjustable parameters, listUserAdjustablePolicies and getUserPolicyParameters fail the same way. Contact Para to enable them.Errors at a glance
A non-success response throwsParaRestError. Every Permissions route returns JSON, so code is always set. Read status and code to branch, message for the detail and requestId when you contact Para. An empty path argument throws ParaRestValidationError before the request is sent.
Each method page lists its own errors. Permissions errors lists every code.
Every method takes an optional last
options argument of type ParaRestCallOptions. Use its signal to cancel a request. Input and response shapes are in Permissions types.
Methods
All routes below are relative tohttps://api.beta.getpara.com/v1/permissions-v2 on beta and https://api.getpara.com/v1/permissions-v2 in production.
Policy discovery
Read active definitions or inspect the published versions of one policy.Consent
These reads pair a user’s wallet with its Request consent state. The wallet owner grants consent through Portal.Parameters
Inspect a user’s personal values and earlier revisions. Your backend has read access; users save their own values.Approval configuration
These routes start with/authorization-scopes/{authorizationScopeId}. Routes that take a reference continue with /policies/{policyId}/versions/{policyVersion}/requirements/{requirementId}.
Roles and scopes
Assign users inside a scope and bind wallets to it, or read the current assignments, bindings and their histories.Approval cases
Follow cases your app opened and cancel one while it is pending. Approvers decide through their signed-in client or Portal.Reviews
Approve or reject an ordinary review that one of your app’s signing requests opened. Your backend decides these reviews with your secret key.Usage
Read the spend already recorded or reserved for a wallet under a policy, with optional token and Safe selection.Policy reviews
A Guardrail rule withrequire_approval and no approvalRequirement opens a review on your app’s own REST signing request. The signing call fails with 403 POLICY_REVIEW_REQUIRED, and the body carries a reviewId. Your backend approves that review with approveReview or rejects it with rejectReview:
Idempotency-Key, as Ordinary review describes. After expiry, send the request with a new Idempotency-Key to open a new review. Pending transaction review lists the errors.