Forge Invocation Token `context` claim appearing in backend function calls

Forge Forge Platform and Tools
1

The documentation on both the Forge Remote essentials page and the invoke-remote API reference states that `invokeRemote` calls from backend functions do not receive a `context` claim. However, I observed the opposite behavior.

When I called `invokeRemote` from a backend trigger function handling the `avi:forge:upgraded:app` event, the Forge Invocation Token attached to the request included a `context` claim with `cloudId`. The token was verified and contained: `app`, `context`, `aud`, `nbf`, `iss`, `iat`, `exp`, `jti`. The `context` field held exactly `{ “cloudId”: “” }`.

For comparison, a UI module token had the same structure plus a `principal` claim.

References:

Filed as Jira

2

You’re right, and our documentation is wrong here.

When a Forge backend function calls invokeRemote, the Forge Invocation Token includes a context claim that contains only cloudId. This covers trigger and lifecycle event handlers too. We don’t plan to change this.

  • cloudId is set for Jira and Confluence installations. For other products, such as Bitbucket, context is an empty object.
  • No other context fields are included. If your remote needs more, send it in the request body and treat it as untrusted input.
  • principal is only present when there’s a user behind the invocation, so it’s absent for triggers and lifecycle events like avi:forge:upgraded:app.

We’ll update the Forge Remote essentials and Invoke Remote API pages to match.

On RFC-138: “No changes will occur for triggers, lifecycle events or backends connected to endpoints” means the proposed trusted-only opt-in won’t change what those invocations receive, including this cloudId claim.