Heroku not passing RapidAPI secret header to dyno

I’m having trouble with my API hosted on Heroku and listed on RapidAPI. The x-rapidapi-proxy-secret header isn’t making it to my dyno after Heroku’s redirect.

Here’s what’s happening:

  1. Request comes in through RapidAPI with the secret header
  2. Heroku receives it and redirects to a dyno
  3. The dyno gets the request, but the secret header is missing
  4. My API code rejects the request due to the missing header

I’ve set up middleware to check for this header:

@app.middleware("http")
async def verify_rapidapi_secret(request: Request, call_next):
    if secret_key:
        if "X-RapidAPI-Proxy-Secret" not in request.headers or request.headers["X-RapidAPI-Proxy-Secret"] != secret_key:
            return PlainTextResponse("API access denied", status_code=403)
    return await call_next(request)

The logs show the header is present initially, but gone after the redirect. Any ideas on how to fix this? Should I change my approach to validating RapidAPI requests?

hey FlyingEagle, heroku can be tricky with headers sometimes. have u tried using the X-Forwarded- prefix for ur header? Like X-Forwarded-X-RapidAPI-Proxy-Secret. this might help preserve it thru the redirect. worth a shot!

I’ve dealt with this exact problem before, and it’s a real pain. What worked for me was using Heroku’s labs:enable http-session-affinity feature. This keeps requests from the same client going to the same dyno, which can help preserve headers.

Another trick is to encode the secret in a custom header that Heroku doesn’t strip. Something like X-Custom-RapidAPI-Secret. You’d need to update your middleware to check for this new header.

If all else fails, you might want to look into using Heroku’s Private Spaces. It’s pricier, but it gives you more control over your network stack and can solve these kinds of header issues.

Remember, Heroku’s support is pretty good. If you’re still stuck after trying these, don’t hesitate to open a ticket with them. They might have insights specific to your setup.

I’ve encountered a similar issue with Heroku and API headers. One effective solution is to configure your Heroku app to forward specific headers. You can do this by adding a custom .herokuapp.com domain and setting up SSL termination at the dyno. This approach bypasses Heroku’s routing layer, allowing headers to pass through intact.

Alternatively, consider implementing a custom authentication method that doesn’t rely on the RapidAPI header. You could use API keys or JWT tokens, which are more resistant to being stripped during redirects. This might require changes on the RapidAPI side as well, but it could provide a more robust solution in the long run.

If these options aren’t feasible, you might need to reach out to Heroku support for a more tailored solution to your specific setup.