How do I set a JWT expiration date out past 1 week?

When I use the JWT token provided by the Zoom App Credentials page, cURL commands work as expected.

When I modify the “exp” date using, I get an “invalid HmacSHA256” error msg.

When I paste the JWT token created in the Zoom App Credentials page into’s “Encoded” window and modify the payload by updating the “exp” value in the “Decoded” window, I get the following error using the new encoded JWT token string:

{"code":124,"message":"The Token's Signature resulted invalid when verified using the Algorithm: HmacSHA256"}

Which App Type (OAuth / Chatbot / JWT / Webhook)?

Which Endpoint/s?
All of them.

How To Reproduce (If applicable)
Steps to reproduce the behavior:

  1. Copy JWT token from Zoom App Credentials page
  2. Paste inito “Encoded” window
  3. Modify payload “exp” value, e.g. from "exp": 1637500704, to "exp": 1637524740,
  4. Copy updated JWT token from “Encoded” window
  5. Paste updated JWT token into cURL command line --header 'authorization: Bearer { updated_jwt_token }

Screenshots (If applicable)
Same behavior with or without the “secret base64 encoded” option

Additional context
The cURL command works just fine using the JWT token provided by the Zoom App Configuration page. If I cannot customize the JWT token expiration value with, why should I expect their libraries to work?

The cURL PATCH command:

curl --request PATCH \
  --url '' \
  --header 'authorization: Bearer { auth_token } \
  --header 'content-type: application/json' \
  --data-raw '{
    "settings": {
      "alternative_hosts": ";;"

The settings:

lol… I figured out the problem I was having with the Zoom App Credentials “Other” option. It wasn’t working in Safari …works fine in Chrome :sweat_smile:

The token updates in Chrome after entering the “Other” date (hh:mm MM/DD/YYYY format).

Still not sure what I’m doing wrong with though :thinking:

Hi @mixelpix ,

Happy to help! You can use something like to convert the time you want to IAT format and paste that value in the payload or the bearer token on

It’ll update the encoded bearer token with the new time value.


1 Like

@gianni.zoom thanks. Isn’t it just epoch time? E.g. to set a valid future date, just make the exp date a larger integer than the iat date? I.e. do I need another service to create a valid date? I don’t think do, especially since the has a human readable interpretation of the epoch time value entered for the exp time (just hover the cursor over it).

I’m pretty sure a valid exp value is not the problem here, e.g. you could just advance the left-most integer by one to create a valid future date value.

The problem is that the resulting JWT isn’t valid (even though the components encoded are).

Sorry @mixelpix – I misread and misunderstood what you said with the respect to the issue you’re having!

One possible source of trouble I see is that the payload format for your inputs on do not match the structure on our documentation.

Per our documentation, try the following payload syntax:

  "iss": "API_KEY",
  "exp": 1496091964000

iss , the issuer of the token, is your API Key.

exp is the expiration timestamp of the token in seconds since Epoch (unix epoch time).

You can add and test with the “iat” value as well.

Let me know if this yields a working token for you.


@gianni.zoom thanks for the suggestions - turns out I wasn’t adding the API secret in the decoded gui for generating a valid encoded JWT :sweat_smile:

1 Like

Super happy you have it all worked out! Thanks for the update!

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.