CloudDeploy Permissions: Per‑Parameter Access Control Unresolved

Answer

No. The Permissions option on CloudObject and APIFunction controls access to the whole deployed object, not to individual parameters. There is no documented syntax for parameter-level permission rules.

Confirmed facts

• CloudDeploy with Permissions applies to the entire CloudObject. Accepted forms are object-wide, e.g. "Public", "Private", or rule lists mapping Wolfram IDs or groups to levels such as "Read" or "Execute".
• The default is private to the deploying account. Changing Permissions changes who can invoke the API at all, not which arguments they may supply.
• No current Wolfram Language documentation describes per-parameter or per-argument permission syntax for APIFunction.

Likely explanation and practical pattern

Fine-grained control over who may use a specific parameter must be enforced inside the function body. The function runs in the cloud kernel after the object-level permission check passes, so identity inspection there cannot be bypassed by crafting URL query parameters.

Typical pattern:

1. Deploy the APIFunction with object-level Permissions that allows all intended callers to invoke it, e.g. Permissions -> {"Execute" -> {"Public"}} or a list of allowed Wolfram IDs.
2. Inside the function, read the caller identity and branch on it before honoring sensitive parameters.
3. Reject, ignore, or return a default for the restricted parameter when the caller is not authorized.

Alternative when strict separation is needed: deploy two CloudObjects. A public variant with only unrestricted parameters and a private/restricted variant with full parameters, each with its own Permissions rules.

Assumptions and verification

Identity symbols such as $RequesterWolframID and exact permission level names are version- and platform-sensitive. Confirm the correct symbol in your Wolfram Language version before relying on it.

Verification steps you can run:

• Deploy a minimal APIFunction that returns the caller identity and call it from two different Wolfram IDs.
• Attempt to set a parameter-level permission rule and observe it is rejected or ignored, confirming whole-object granularity.
• Test that a caller outside the allowed list receives failure or default behavior when supplying the restricted parameter.

To give a precise code snippet, which Wolfram Language / Wolfram Cloud version are you targeting? The exact identity symbol and permission names differ by version and change the recommendation.