DocumentationAdobe Workfront Fusion

HTTP > Make a JWT request module

Last update: October 9, 2026

The Adobe Workfront Fusion HTTP > Make a JWT request module sends an HTTP(S) request to a URL and authorizes it with a JSON Web Token (JWT) that the module signs for you on every call. The response is then processed the same way as in the standard HTTP > Make a request module.

This module behaves like the standard Make a request module, with one main difference: it automatically signs a JWT from the claims you provide and adds it to the request, by default as Authorization: Bearer <token>.

Use this module to call any API that expects a signed JWT for authentication, such as services that require a short-lived bearer token signed with a shared secret (HMAC) or a private key (RSA/ECDSA), without creating the token in a separate step.

If the API uses OAuth 2.0, Basic authentication, an API key, or a client certificate, use the matching dedicated HTTP module instead.

NOTE
If you are connecting to an Adobe product that does not currently have a dedicated connector, we recommend using the Adobe Authenticator module.
For more information, see Adobe Authenticator module.

Access requirements

Expand to view access requirements for the functionality in this article.
table 0-row-2 1-row-2 2-row-2 3-row-2 layout-auto html-authored no-header
Adobe Workfront package

Any Adobe Workfront Workflow package and any Adobe Workfront Automation and Integration package

Workfront Ultimate

Workfront Prime and Select packages, with an additional purchase of Workfront Fusion.
Adobe Workfront licenses

Standard

Work or higher
Adobe Workfront Fusion license

Operation-based: Available to organizations with operation-based licenses

Connector-based (legacy): Workfront Fusion for Work Automation and Integration
Product If your organization has a Select or Prime Workfront package that does not include Workfront Automation and Integration, your organization must purchase Adobe Workfront Fusion.

For more detail about the information in this table, see Access requirements in documentation.

For information on Adobe Workfront Fusion licenses, see Adobe Workfront Fusion licenses.

Create a JWT connection

The module requires a JWT connection. The connection stores the signing material so the secret or private key does not have to appear in the scenario.

Create a JWT connection in Fusion

  1. Add the HTTP > Make a JWT request module to your scenario.

  2. Click Add next to the Connection field.

  3. Configure the connection fields:

    table 0-row-2 1-row-2 2-row-2 layout-auto html-authored no-header
    Connection name Enter a name for the connection.
    Algorithm

    Select the signing algorithm for the connection.

    • HS256
    • HS384
    • HS512
    • RS256
    • RS384
    • RS512
    • PS256
    • PS384
    • PS512
    • ES256
    • ES384
    • ES512
    Secret

    Enter the signing key.

    • For HS* algorithms, use the shared secret string.
    • For RS*, PS*, and ES* algorithms, use the PEM-encoded private key.

  4. Click Continue to create the connection and return to the module.

IMPORTANT
A JWT connection signs with one algorithm only. If your scenario requires more than one signing algorithm, create a separate connection for each algorithm. This matches the existing standalone JWT app behavior.

HTTP > Make a JWT request module and its fields

When you configure the HTTP > Make a JWT request module, Adobe Workfront Fusion displays the fields listed below in the same order they appear in the module UI. A bolded title in a module indicates a required field. Fields marked as advanced are hidden unless you select Show advanced settings.

Connection
Select an existing JWT connection or create a new one.
URL
The target URL for the request.
Method
HTTP method such as GET, POST, PUT, PATCH, or DELETE.
Headers
Custom request headers in key/value format.
Query String
Query-string parameters in key/value format.
Body type
How the request body is encoded. Options include Raw, application/x-www-form-urlencoded, and multipart/form-data.
Parse response
When enabled, Fusion parses the response body based on the response content type.
JWT Payload (Claims)
Key/value pairs included as claims in the JWT payload. The reserved claims exp, iat, and nbf must be a NumericDate — a number of seconds since the Unix epoch. Claim values keep their JSON type, so numbers stay numbers and booleans stay booleans.
Timeout (advanced)
Specify the request timeout in seconds (1-300). The default is 40 seconds.
Retry Count (advanced)
Specify how many times the request should retry if the request fails due to a retryable error.
Additional Retry Status Codes (advanced)
Specify additional HTTP status codes that should be treated as retryable.
Share cookies with other HTTP modules (advanced)
Enable this option to share cookies from the server with all HTTP modules in your scenario.
Self-signed certificate (advanced)
Upload your certificate if you want to use TLS using your self-signed certificate.
Reject connections that are using unverified (self-signed) certificates (advanced)
Enable this option to reject connections that are using unverified TLS certificates.
Follow redirect (advanced)
Enable this option to follow the URL redirects with 3xx responses.
Disable serialization of multiple same query string keys as arrays (advanced)
By default, Workfront Fusion handles multiple values for the same URL query string parameter key as arrays. For example, www.test.com?foo=bar&foo=baz will be converted to www.test.com?foo[0]=bar&foo[1]=baz. Activate this option to disable this feature.
Request compressed content (advanced)
Enable this option to request a compressed version of the website. Adds an Accept-Encoding header to request compressed content.
Use Mutual TLS (advanced)
Enable this option to use Mutual TLS in the HTTP request.
Sign Options (advanced)

For each sign option that you want to add to the request, click Add item and enter the parameter's name and value.

Additional options passed to the JWT signer, such as expiresIn, issuer, audience, subject, and keyid. Duration values such as expiresIn are interpreted by the jsonwebtoken library. A plain number is treated as milliseconds, so use a unit string such as "1h" or "3600s" to be explicit. The algorithm is taken from the connection and cannot be overridden here.

Header Name (advanced)
Enter or map the name of the request header that receives the signed JWT. Default: Authorization. The header name must not contain a dot (.), because dotted names are rejected and cannot be masked in request logs.
Token Type (advanced)
Enter or map the authentication scheme placed before the token, such as Bearer. Leave this blank to send the raw token without a prefix.

How the token is built

  1. The module collects the claims in the JWT Payload (Claims) field.
  2. Reserved claims such as exp, iat, and nbf are converted to NumericDate values.
  3. The module applies the Sign Options and signs the token using the algorithm from the connection.
  4. The signed token is placed in the request header defined by Header Name.
  5. If Token Type is set, the module adds the prefix before the token. For example, Bearer eyJ….
  6. The request is sent, and the response is processed the same way as the standard HTTP > Make a request module.

The signed token is automatically masked in debug and error logs so it is never exposed.

Example

Connection

  • Algorithm: HS256
  • Secret: my-shared-secret

Module settings

  • URL: https://api.example.com/v1/orders

  • Method: GET

  • JWT Payload (Claims):

    • sub = service-account-42
    • iss = make-integration

  • Sign Options:

    • expiresIn = 1h

  • Header Name: Authorization

  • Token Type: Bearer

Result

The module sends the request with a header similar to:

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

FAQ / gotchas

Why did my token expire so quickly?

You likely entered a bare number for expiresIn such as 3600. The jsonwebtoken library interprets plain numbers as milliseconds. Use a unit string such as "1h" or "3600s" instead.

When is the token created?

The module signs a fresh JWT each time the module runs, not when you create the connection. The connection stores only the signing material and algorithm, so claims such as iat and exp reflect the moment of that module run.

If the request retries within the same module execution, Fusion reuses the same signed token for those retry attempts instead of signing a new token for each attempt. Because of this, a very short expiresIn value can expire before a retry occurs and cause a retry to send an already-expired token. To avoid this, use a clear unit string such as "1h" or "3600s" and avoid overly short token lifetimes.

Can I change the algorithm per request?

No. The algorithm is fixed by the connection. If you need a different algorithm, create a different JWT connection.

Can I send the token in a custom header?

Yes. Set the Header Name field to a custom name, but it cannot contain a dot (.).

Can I send the raw token without Bearer?

Yes. Leave Token Type empty.

Is the token visible in logs?

No. The signed token is masked automatically in debug and error logs.

NOTE
Technical note: signing uses the jsonwebtoken library and mirrors the standalone JWT app’s signing behavior, so the same inputs produce the same token as the standalone JWT app.
recommendation-more-help
workfront-fusion-help-workfront-fusion