Passing multiple JWT tokens to embedded Retool app causes 414 URL too large error

💬 App Building
, , ,
1

1. My goal:

I am embedding a Retool app inside my React application and need to securely pass multiple tokens along with other parameters (user_id, home_id, org_id) to Retool.

2. Issue:

Currently, I am passing parameters via URL like this:

https://domain.retool.com/embedded/public/APP_ID/user-details?app_base_url=http://localhost:3000
&user_id=...
&home_id=...
&hs_access_token=...
&org_id=...
&has_other_token=....

This works fine with a single token.

However, when I try to pass two tokens (both large JWTs) in the URL, I get:

414 Request-URI Too Large (nginx)

3. Steps I've taken to troubleshoot:

  • Tried passing both tokens via URL → fails with 414

  • Tried using postMessage from React → Retool listener sometimes doesn’t receive the message reliably (likely timing issue)

  • Tried reducing params → works only when token size is small

  • Confirmed Retool app is embedded (/embedded/public/...) and embedding is enabled

4. Additional info:

  • React app runs on: http://localhost:3000

  • Retool app is embedded via iframe

  • Tokens are JWT (large in size)

  • Use case requires both tokens in Retool for different APIs

:red_question_mark: Question:

What is the recommended and reliable way to pass multiple large tokens from a React app to an embedded Retool app?

  • Is there a supported pattern for passing secure data (like tokens) to embedded apps?

  • Should this be handled via backend/session exchange instead of URL/postMessage?

  • Is there any Retool-native solution for this use case?

:white_check_mark: Expected outcome:

A scalable and production-safe way to pass multiple tokens to an embedded Retool app without hitting URL limits or unreliable messaging.

4

Hi @rajappscrip-byte, and welcome to the community!

Appreciate the detailed writeup of your issue! From a security standpoint, it’s best to avoid passing JWTs as a query parameter in the URL. URLs could be logged by the server, browser history, and are generally long lived, so we’ll want to avoid storing anything potentially sensitive there. Using the browser’s postMessage API would generally be better suited for sending tokens back and forth. postMessage could also handle a larger data payload, so you shouldn’t run into those 414s anymore.

What you’re running into with postMessage only intermittently working sounds like it could be a race condition. If your parent app is sending the JWT before the iframe is fully loaded, the event listener in your Retool app never receives it. One potential fix to ensure your Retool app is fully loaded before sending the JWT would be to message to your parent app with a query that fires on page load. In your parent app, you’d set an event listener to send the JWT when it gets confirmation. You could sidestep this completely if you’re able to use the Retool embed SDK, but if your implementation requires you to use an iframe the confirmation flow should reliably work.

Hope this helps!

1 Like