> ## Documentation Index > Fetch the complete documentation index at: https://docs.getpara.com/llms.txt > Use this file to discover all available pages before exploring further. # Permissions types > Shared inputs, revision rules, and lifecycle results for permissions methods The signatures use the SDK's input and response type names. Not every response type is a named export from the client package. To type a result without importing an internal package, derive it from the method: ```typescript theme={null} import type ParaCore from "@getpara/core-sdk"; import type { ParaRestClient } from "@getpara/rest-sdk"; type SignatureCollection = Awaited< ReturnType >; type BackendAssignments = Awaited< ReturnType >; ``` The types below describe the data each method accepts or returns. The caller must still satisfy the method's access requirements. ## Resource context ```typescript theme={null} interface PermissionsV2WalletContext { walletId: string; } interface PermissionsV2ConsentListContext extends PermissionsV2WalletContext { pendingTransactionId?: string; } interface PermissionsV2ApprovalRequirementReference { authorizationScopeId: string; policyId: string; policyVersion: string; requirementId: string; } interface PermissionsV2UsageContext extends PermissionsV2WalletContext { chainId?: string; tokenAddress?: string; } interface PermissionsV2PartnerUsageContext extends PermissionsV2UsageContext { userId?: string; } ``` `policyVersion` identifies an immutable authored version. `expectedRevision` below identifies a mutable settings revision. Read the resource before writing and submit its current revision; use zero when no revision exists. A stale revision does not silently overwrite a newer update. ## Adjustable parameters ```typescript theme={null} type PermissionsV2UserParameterSave = { policyVersion: string; policyHash: string; expectedRevision: number; values: Record; }; type PermissionsV2UserParameterReset = { policyVersion: string; policyHash: string; expectedRevision: number; }; ``` `values` maps declared parameter IDs to their values. Amounts use the policy fact’s units, including base units where specified; do not substitute a formatted currency amount. `PermissionsV2UserAdjustablePolicyListResponse` contains `policies`, an array of parameter views. `PermissionsV2UserParameterView` identifies the user, application, policy version, and hash, and includes `parameters`, `revision`, and `provenance` (`default` or `personal`). Each parameter descriptor has `id`, `label`, `defaultValue`, `fact`, and optional `asset` and `window`. * `status: "ready"` includes current `values`; stored revisions also include `configurationHash`. * `status: "needs_confirmation"` includes `previousValues`. They are not confirmed values for the current policy version. Saving parameter values is separate from granting standing consent. Use the current consent state to determine whether Portal confirmation is needed. ## Approval configuration and authority ```typescript theme={null} type PermissionsV2AuthorizationConfigurationWrite = { expectedRevision: number; values: Record; }; type PermissionsV2AuthoritySetWrite = { expectedRevision: number; assignments: Array< | { kind: "role"; name: string } | { kind: "attribute"; name: string; value: string } >; }; type PermissionsV2AuthorizationScopeBindingWrite = { expectedRevision: number; authorizationScopeId: string; }; ``` Workflow configuration changes only the settings declared by the policy, within their value types and bounds. An authenticated user must meet the policy's manager eligibility; a trusted backend uses its server secret to administer configuration within the same declared limits. Personal spending parameters are separate settings chosen by the wallet owner. Assignment writes replace the complete set for that user and scope. They determine who qualifies under the policy's role and attribute rules, so your backend must authorize callers before changing assignments. `PermissionsV2AuthorizationConfigurationView`, `PermissionsV2AuthoritySetView`, and `PermissionsV2AuthorizationScopeBindingView` return their resource identity, `revision`, `changedAt`, and `changedBy`. Configuration views also contain `values` and `configurationHash`. `PermissionsV2EffectiveAuthorizationConfiguration` returns the authored requirement, stored configuration (or `null`), and `effectiveRequirement`. | Result | Principal fields | | --------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `PermissionsV2ConditionalRequirementView` | `policyId`, `policyVersion`, `policyHash`, `ruleId`, `requirementId`, and the authored `requirement`. | | `PermissionsV2ConditionalRequirementList` | `requirements`: an array of requirement views. | | `PermissionsV2AuthorizationScopeCapabilities` | Partner, application, scope, and user IDs plus `requirements`. Each entry identifies a policy/version/hash, rule and requirement, with `canManageConfiguration: true`. | Capabilities describe which requirements the current user can manage. They are not a list of other scope members or a signing authorization. ## Signature collection ```typescript theme={null} type PermissionsV2TransactionSignatureCollection = { requestId: string; walletId: string; transaction: | { format: "safe_eip712"; typedDataJson: string; chainId: string } | { format: "evm_typed_data"; typedDataJson: string; chainId: string } | { format: "evm_transaction"; transactionBase64: string; chainId: string } | { format: "solana_transaction"; transactionBase64: string } | { format: "cosmos_transaction"; signMode: "DIRECT" | "AMINO"; signDocBase64: string } | { format: "stellar_xdr"; transactionXdr: string; networkPassphrase: string } | { format: "sui_transaction"; transactionBase64: string }; }; type PermissionsV2ConditionalApprovalSignature = { walletId: string; signature: string; }; interface SignApprovalTransactionParams { caseId: string; walletId: string; } ``` The collection request identifies the transaction wallet. A signature submission identifies the signer’s wallet; they need not be the same wallet. The backend derives the canonical signing payload from the transaction rather than accepting caller-provided policy facts. `PermissionsV2ApprovalSignatureCollectionResult` returns `caseId`, `status`, and `expiresAt`. `PermissionsV2ApprovalSigningPayload` returns `caseId`, `transaction`, `payloadDigest`, and `signingPayloadBase64`. `PermissionsV2ApprovalSignatures` adds `signatures`, each containing `walletId`, `signature`, and `actorId`. Collected signatures are not an onchain submission. Your chain-specific integration remains responsible for assembling and broadcasting the intended transaction. ## Discovery, consent, and cases | Result | Principal fields | | ------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | | `PermissionsV2PolicyListResponse` | `policies`: policy views. | | `PermissionsV2PolicyResponse` | `policy`: one policy view. | | `PermissionsV2PolicyVersionsResponse` | `versions`: policy views. | | Policy view | `policyId`, `policyVersion`, `policyHash`, `lifecycle`, `activation`, optional consent `binding`, and authored `policy`. | | `PermissionsV2DelegationConsentDiscoveryResponse` | `requests`, each containing `policy` and `consent`. | | `PermissionsV2DelegationConsentView` | Resource IDs, policy version/hash, `status`, optional configuration hash and grant/expiry/revocation timestamps. | | `PermissionsV2ConditionalApprovalCaseView` | `caseId`, `status`, `request`, `requirementIdentity`, `currentStageIndex`, `stages`, `decisions`, `expiresAt`, and caller-specific `decision` capability. | Policy lifecycle values are `active`, `inactive`, `superseded`, and `archived`. Activation timestamps additionally govern when a policy is effective. Consent status is `pending`, `standing`, `manual_review`, `revoked`, or `expired`. Approval case status is `pending`, `completed`, `rejected`, `expired`, or `invalidated`. `completed` means the approval requirement was satisfied; it does not itself establish that a transaction was broadcast. An approval case’s `decision` says whether the current user can decide and, if not, why. Partner backend case reads omit this user-specific field. Reading an initiated case does not grant approval authority. ## Usage and history `PermissionsV2PolicyUsage` identifies the policy, wallet, user (or `null`), application, and snapshot timestamp `asOf`. It includes the applicable parameter `configuration` and `meters`. Each meter identifies the rule and condition, native or ERC20 asset, chain, window, bucket start/reset time, and string-valued `limitBaseUnits`, `committedBaseUnits`, `reservedBaseUnits`, and `usedBaseUnits`. `remainingBaseUnits` may be `null`. A usage snapshot is not a transaction evaluation result. ```typescript theme={null} interface PermissionsV2HistoryOptions { beforeRevision?: number; } interface PermissionsV2CaseListOptions { limit?: number; beforeCaseId?: string; } interface PermissionsV2AuthorizationScopeMemberListOptions { limit?: number; afterUserId?: string; } ``` Pass the response cursor into the corresponding next request. | Result | Principal fields | | ------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- | | `PermissionsV2UserParameterHistory` | `revisions`: policy version/hash, revision, provenance, values, and change time; optional `nextBeforeRevision`. | | `PermissionsV2AuthorizationScopeBindingHistory` | `revisions`: wallet-scope binding views; optional `nextBeforeRevision`. | | `PermissionsV2ConditionalApprovalCaseList` | `cases`: approval case views; optional `nextBeforeCaseId`. | | `PermissionsV2ConditionalApprovalPartnerCaseList` | `cases`: case views without caller-specific `decision`; optional `nextBeforeCaseId`. | | `PermissionsV2AuthorizationScopeMembers` | `members`: authority-set views; optional `nextAfterUserId`. | | `PermissionsV2AuthoritySetHistory` | `assignments`: authority-set revision views. | | `PermissionsV2AuthorizationConfigurationHistory` | `configurations`: configuration revision views. | `listAccessibleApprovalCases` returns `{ cases: PermissionsV2ConditionalApprovalCaseView[] }` without a pagination cursor. Portal URL methods return a `string` to open through your application's browser integration. Start with policy discovery. Manage partner-authorized resources from your backend.