Skip to main content
Learn how a policy becomes active, what a replacement changes, and how to move a tested configuration to production. The same lifecycle underlies Developer Portal and CLI authoring.

​
Distinguish policy identity from a saved record

A policy’s id identifies the logical policy. Its version identifies an immutable definition. The management API also returns a recordId for the stored version; CLI lifecycle commands use that record ID. User-facing SDK reads use the logical policy ID. Changing rules or approval stages requires authoring a new policy version through Developer Portal, JSON/CLI, or Para assistance. SDK configuration methods can adjust only the settings that the existing policy declares; they do not create a replacement definition. Production policy changes require Para review and publication. A new version follows the activation lifecycle below and may require renewed consent. A version/hash change also changes the authorization context; do not treat consent or approval evidence for an earlier version as authorization for the new one.

​
Save, activate, and replace

Replacements must preserve the selector and product mode and use the next numeric version string. Use a new logical policy ID for an independent policy or a different selector. Multiple active policy IDs may apply to one request; creating another policy is not equivalent to replacing the first.
Deactivating or expiring a policy removes that policy’s contribution. It does not mean all signing is denied. Remaining policies and the wallet ownership model still determine the result.

​
Set a policy time window

The CLI accepts --effective-from and --effective-until as UTC timestamps when creating or replacing a record. These control when an active record participates. They are different from an aggregate condition’s spending window, which measures usage over time. Test requests before the start, during the active interval, and after the end. A Request that no longer grants standing access can lead back to user review; an expired Guardrail no longer supplies its restriction.

​
Handle changes to user authorization

When a new Request version applies, the user may need to consent again. Saved personal parameters can require confirmation against the new version. Read the returned status and revision instead of silently carrying old settings forward. Conditional approvals are bound to a request and its policy/authority context. A completed case is not a reusable permission for future transactions. Inspect current state and let Para re-evaluate the original operation before signing.

Consent and personal limits

Read current settings and handle reconfirmation.

Conditional approvals

Handle pending, rejected, expired, and completed cases.

​
Move from beta to production

  1. Create and activate the policy on a beta key, called Development in Developer Portal.
  2. Verify allowed, denied, and review-required requests using the wallet types and routes your app uses. Include expiry and approval outcomes where applicable.
  3. Request production review through Developer Portal when the action is available, or contact Para for an advanced configuration.
  4. Para reviews the intended behavior and manually publishes the approved production policy for the separate production key.
  5. Confirm the published production configuration before sending production traffic.
Creating a production key does not copy beta policies. The CLI does not allow production policy mutations. Subsequent production changes also require review; changing beta does not update production.