Integrate consent and adjustable limits

Permissions Requests let a user grant your application standing permission to perform specific transactions with a user-owned wallet. A transaction matching an active, granted Request can sign without another prompt unless another applicable rule denies it or requires approval. A transaction without standing permission requires review, subject to the remaining policy decision.

Permissions supports EVM, Solana, Cosmos, Stellar, and Sui wallets. The Developer Portal forms cover a subset of policy shapes; use JSON authoring or work with Para for other supported configurations. Each policy selects one wallet type and can narrow it to specific networks, and each rule names the actions it governs. Check the policy reference for the facts supported by each request.

Requests are for user-owned wallets used through the SDK. For app-owned wallets used through the REST API, configure Guardrails instead.

Configure the Request

Create, review, and activate the Request against your beta API key using Developer Portal or JSON authoring. Developer Portal calls this a Development key. The Request should include only the networks, actions, and conditions your application needs. Follow the Developer Portal walkthrough for form-based setup and the policy lifecycle guide for activation and production review. To start from a common Request, see Request templates. When consent has not already been granted through a standalone flow, the first transaction that could use an active Request opens the transaction-review flow if the user has not chosen how the app may use that Request. Para shows the description you entered in the Portal and asks whether the user wants to grant standing access or keep manual review. The user still reviews the current transaction. Standing access begins only after that transaction is approved and applies to future matching transactions. The user can choose one of two paths:

User choice	Signing behavior
Approve the Request	After the current transaction is approved, future matching transactions can use standing access while the grant and policy remain active, subject to other applicable rules.
Manually approve each transaction	The current transaction and future transactions continue through manual review.

When a new active version replaces a Request, Para asks the user to review that version the next time a transaction could use it. The public key can discover published, non-targeted policies. An authenticated user can separately read policies applicable to their wallet and their consent state:

const published = await para.listPolicies();
const applicable = await para.listApplicablePolicies({ walletId });
const consent = await para.getUserPolicyConsent(policyId, { walletId });

import {
  listPolicies,
  listApplicablePolicies,
  getUserPolicyConsent,
} from "@getpara/react-sdk";

const published = await listPolicies(para);
const applicable = await listApplicablePolicies(para, { walletId });
const consent = await getUserPolicyConsent(para, policyId, { walletId });

import {
  usePolicies,
  useApplicablePolicies,
  useUserPolicyConsent,
} from "@getpara/react-sdk";

// Call inside a React component under your Para provider.
const published = usePolicies();
const applicable = useApplicablePolicies({ walletId });
const consent = useUserPolicyConsent(policyId, { walletId });

// Each query exposes data, isPending, and error.

listPolicies does not silently become user-specific after login. Targeted definitions and private user settings are not exposed by public discovery. Use the applicable-policy methods for the signed-in user’s wallet.

Permissions method reference

Read the authority and result contracts for discovery and consent methods.

Use the standalone Portal consent URL when your application wants a “Grant access” action before submitting a transaction:

const url = await para.getPolicyConsentUrl({ walletId, policyId });
window.open(url, "para-consent", "popup,width=480,height=720");

This method returns a URL; it does not open a window or grant access. Open it from a user-triggered interaction using your application’s popup or browser handling. Para authenticates the user in Portal and shows the policy, any adjustable parameters, and the consent choices. No transaction follows a standalone consent flow. Read getUserPolicyConsent(policyId, { walletId }) again when the user returns. Closing a window is not proof that consent succeeded. The returned status distinguishes standing access, manual review, revocation, expiry, and pending consent. Use the same Portal flow to let the user revisit their choice or revoke an existing permission.

Adjust personal limits

A policy can declare one or more adjustable amount parameters. Portal shows an input for each declared parameter inside the policy card. The user’s selected values and consent are submitted together in that flow. For a custom settings UI, the authenticated user can also read and update personal values directly:

const current = await para.getUserPolicyParameters(policyId);

const updated = await para.updateUserPolicyParameters(policyId, {
  policyVersion: current.policyVersion,
  policyHash: current.policyHash,
  expectedRevision: current.revision,
  values: { "transfer-limit": "5000000" },
});

This example targets the single transfer-limit parameter in the JSON example. Submit the full set of declared values when a policy has multiple parameters. Values are base-unit integer strings; do not send floating-point token amounts. The declaration provides a default, not a maximum allowed choice. Saving values does not mutate the partner’s policy, grant consent, or complete transaction review. A settings change can invalidate authorization tied to the previous configuration, so re-read consent and complete Portal authorization when required. To restore the policy defaults, first read the current revision and then reset:

const current = await para.getUserPolicyParameters(policyId);
const reset = await para.resetUserPolicyParameters(policyId, {
  policyVersion: current.policyVersion,
  policyHash: current.policyHash,
  expectedRevision: current.revision,
});

If the view reports needs_confirmation, present the previous values alongside the current policy defaults and require a deliberate update or reset. On a revision conflict, refresh the current view before asking the user to submit again. A failed read must not be treated as an empty/default configuration.

Use React hooks

Read settings and submit changes through the corresponding query and mutation hooks.

Use actions

Call permissions actions with your Para client.

Transaction behavior

When your React application sends a transaction, Para evaluates it against the active Request for that wallet and API key.

Your app submits the transaction

Use the normal Para transaction hooks or signer integration. Permissions do not require a different transaction method.

Para checks the granted Request

A matching transaction can sign without another prompt when the user has granted that Request version and no other applicable rule denies it or requires approval.

The SDK handles manual review when needed

If the transaction does not have standing permission, the web SDK opens Para’s transaction review experience. An applicable Request appears first when the user has not chosen standing access or manual review. The user can then approve or deny the individual transaction.

Test both paths before production: one transaction that should match the Request and one that should require manual review. This confirms that the selector, action, and condition express the intended boundary.

Denial and timeout handling

Treat manual denial and an unanswered review as normal application states. The signing call throws TransactionReviewDenied when the user denies the request and TransactionReviewTimeout when the review is not completed within its configured window. On timeout, the error includes transactionReviewUrl and pendingTransactionId so your interface can offer the user a way to resume or retry the review. Do not treat an unmatched Request as automatic authorization. When a rule denies the transaction outright, the signing call throws without opening review. The error has code: 'POLICY_DENIED' and status: 403, and data.deniedBy can identify the policy and rule.

import { TransactionReviewDenied, TransactionReviewTimeout } from "@getpara/react-sdk";

function getSigningErrorMessage(error: Error) {
  if (error instanceof TransactionReviewDenied) return "You denied this transaction.";
  if (error instanceof TransactionReviewTimeout) return "The review expired. Try again.";
  if ("code" in error && error.code === "POLICY_DENIED") return "A policy blocks this transaction.";
  return error.message;
}

Replacing or deactivating the policy that required an approval invalidates the approval if it has not completed. An invalidated approval cannot complete; submit the request again under the current policy.

Development and Production

Requests are scoped to an API key. Activating a Development Request does not change the Production key. After Development testing, Para reviews and independently publishes the approved production policy. The Production Permissions page is read-only.

Permissions setup

Choose an authoring tool and connect the required application flows.

Permissions reference

Review selectors, actions, conditions, versions, and generated JSON.

Execute transactions

Send transactions with the Para React SDK and supported libraries.

Integrate conditional approvals

Add decisions from other people or collect signatures when the policy requires them.

Get Started

Set Up Project

Add Authentication

Build Wallet UI

Sign with Para

Transact on Chains

Manage Permissions

Manage Sessions

Add Advanced Features

Debug and Launch

Integrate consent and adjustable limits

Configure the Request

Permissions method reference

Adjust personal limits

Use React hooks

Use actions

Transaction behavior

Denial and timeout handling

Development and Production

Permissions setup

Permissions reference

Execute transactions

Integrate conditional approvals

​Configure the Request

​User consent

​Read policies and consent

Permissions method reference

​Request consent before a transaction

​Adjust personal limits

Use React hooks

Use actions

​Transaction behavior

​Denial and timeout handling

​Development and Production

Permissions setup

Permissions reference

Execute transactions

Integrate conditional approvals

Configure the Request

User consent

Read policies and consent

Request consent before a transaction

Adjust personal limits

Transaction behavior

Denial and timeout handling

Development and Production