Kinde Webhooks not being sent
Hi,
I'm currently facing an issue where Kinde is not sending any webhook event to my endpoint in the prod environment. The endpoint is deployed as a Cloudflare worker and I do not see any logs and I also do not see values being populated in my DB.
To debug the issue, I did the following:
1. Change the Webhook URL in Prod to a local webhook running with Ngrok with the development environment JWKS URI and create a role to trigger the event.
2. The call fails (which is expected) due to the kid mismatch between the prod event header kid and dev JWKS URI kid in the keys.
3. I intentionally did the above step so that Kinde can keep retrying the request during my debugging process.
4. Grab the Kinde JWT event from the local console.log
5. Use this event as the payload to my actual CF worker endpoint that was linked to prod webhook using Postman. This request succeeds. I can see the logs and I can see my DB being populated. This confirmed that my CF worker endpoint is configured properly with the prod env JWKS URI and that it can be invoked.
6. Switch over the Webhook URL in prod from the local Ngrok endpoint to the CF worker endpoint so that the retrying of the failed events can hit the CF worker endpoint. I do not see any invocations.
Note:
1. The configurations of both the webhooks are the same, i.e. they listen to the same events.
2. The endpoint works as I can successfully make requests using Postman.
3. I'm aware of the exponential backoff and retry of the event...The first 4 events of the retry until the "After 2 minutes" were pointing to the local Ngrok endpoint which were supposed to fail (described in point 2 above) and I switched it over to the CF worker endpoint after testing with Postman before it hit the "After 10 minutes" retry mark. I have even waited until over an hour to see if I get any logs on my CF worker (success or failure)...No logs.
The conclusion that I'm at is the Kinde is sending Webhook event but it does not work with CloudFlare Workers ?
37 Replies
Hey there.
Thanks for reaching out, and sorry you're running into issues. Here are a few things to check based on our docs: 1. Go to Settings → Environment → Webhooks and make sure your production webhook is active and subscribed to the right events (like
Thanks for reaching out, and sorry you're running into issues. Here are a few things to check based on our docs: 1. Go to Settings → Environment → Webhooks and make sure your production webhook is active and subscribed to the right events (like
role.created).
2. Scroll down to Request Attempts — if you don’t see anything here (not even failures), Kinde hasn’t tried sending anything yet.
3. If a webhook fails, we retry on a backoff schedule (5s, 30s, 2m, 10m, 1h, etc.). If you changed the URL mid-retry, earlier retries still go to the old URL. You’ll need to wait for the next one.
4. Make sure your Cloudflare Worker is publicly accessible over HTTPS and not blocking external IPs (no allowlist or firewall rules).
5. Double-check that the JWKS URI in your prod webhook settings matches the one your Worker is using to validate JWTs. A mismatch will cause the request to fail and retry.
Quick questions to help us debug:
- Do you see any request attempts in the Dashboard (even failed ones)?
- Is the JWKS URI correct in the webhook config?
- Any IP/firewall rules that might block Kinde?
Let us know what you find! We're here to helpHi Ages,
1. Yes, it is active and subscribed to all the org/user/role/permission events
2. Where do I see "Request Attempsts" ? I can't seem to find that section in my Kinde console
3. I have tried creating new events after switching the URL...still no luck
4. Yes, the worker is publically accessible over HTTPS. No rules blocking anything
5. Yes, they are correct as I was able to successfully test it when I made requests from Postman. The issues is I'm not seeing any events in my Worker logs...failed/success. This point is can be looked at when the request reaches my endpoint. But at the moment the worker endpoint is not even invoked for the request to succeed or fail
* I do not know where to look in the Dashboard. I cannot seem to find any section related to that. Can you please help me point to the right place because I have looked at every page in the Kinde dashboard. I do not see any section for "Request Attempts"
* Yes, the JWKS URI is correct. But this will matter only if the endpoint atleast receives an event. Which is not the case at the moment
* No IP/Firewall rules
Both requests are from Postman... The first failed request is when hitting the API without any payload which threw a invalid JWT token which was expected.
The second one is the successful one where I sent the captured Kinde JWT payload (as described in my original post) with Postman....The endpoint is reachable and all the JWKS config is setup properly hence the request was successful
But I do not see any other events in my logs though I have done many actions that would trigger many events
Log from the successful request from Postman
Log from failed request from Postman when I try to invoke it without a payload to check if it was publically accessible
The current issue is that Kinde events are not even reaching the endpoint. Whether they succeed/fail would only matter if the event reaches the endpoint in the first place.
Here is a programmatic test to the endpoint
And this is the Event JWT that I used during my debugging process if it is of any help. I do not seen any sensitive information in the decoded JSON but feel free to redact this if you want to:
eyJhbGciOiJSUzI1NiIsImtpZCI6ImRlOmU4OjhkOmQ5OjY4OmE4OjZiOmI1OmVhOmY0OjQ0OmRjOjc0OjI2OjkyOmZmIiwidHlwIjoiSldUIn0.eyJkYXRhIjp7InJvbGUiOnsiZGVzY3JpcHRpb24iOm51bGwsImlkIjoiMDE5Njk2NzAtZDQ5My0zZTVmLTI2N2MtNWRjODIzNmVhZjA3IiwiaXNfZGVmYXVsdF9yb2xlIjpmYWxzZSwia2V5IjoiZGVmYXVsdF90ZXN0IiwibmFtZSI6IlRlc3QifX0sImV2ZW50X2lkIjoiZXZlbnRfMDE5Njk2NzBkNDlhNjE0OWE2MDVmYThkMjFhOTAwZmYiLCJldmVudF90aW1lc3RhbXAiOiIyMDI1LTA1LTAzVDEzOjU4OjE4LjkyNDg5NyswMDowMCIsInNvdXJjZSI6ImFwaSIsInRpbWVzdGFtcCI6IjIwMjUtMDUtMDNUMTQ6MDc6MzUuOTEwNjc5MTc2WiIsInR5cGUiOiJyb2xlLmNyZWF0ZWQifQ.pa8YGbiv4jAp-IIiVHCAf7KTSfaPubDoLCTDNeRi5WGXJ-EgJJQEKTGluSy7gn0sJA0KjOUQ2dci1uEtBUBeum3hR7onikOYhw668UiygEhYOC_dWyGdZeh_1m-T7Up4oCkzVr0tsSPqMYO9Mo791af3lJbIp-n1qeOVd6Xhda1OJmrlE81qXwDRYCi0gY-ilPdCUA3Ll7CargiXCdiNWxMekfS9OJHS2EqsGfGof5si7yfQJQsTF5gfFGUK2Bfit7oDYIc_rXzzWr4o6nMeFEDY0a3BWYuxBFDwrmxo8KKQGh-AhxCgOpppuqIC74kSH2OI9kBfNzIvEZ4yvdovtA
Successful tests to the endpoint with the above event JWT from Postman and Python code shared above
Proof that the JWKS URI is configured properly on the endpoint. Log from the test request from the python code above
Hi Maxom,
Thank you for taking the time to run those extensive tests.
Per our documentation, Kinde does implement an exponential backoff retry mechanism (up to 36 hours in total) https://docs.kinde.com/integrate/webhooks/about-webhooks. As for the issue you're facing — webhooks not reaching your Cloudflare Worker — here’s what we’ve confirmed so far:
- The webhook is active and subscribed to the correct events.
- Your Cloudflare Worker is publicly accessible and responds correctly when triggered manually.
- The JWKS URI is correctly configured and validated via both Postman and code-based tests.
- You’ve waited beyond the expected retry intervals (including after the 10-minute mark).
- You switched the webhook URL from the local (Ngrok) endpoint to the Cloudflare Worker before the next retry window.
Given all of this, it does appear that Kinde may not be retrying the previously failed event after the URL change — or retries are still being sent to the original endpoint. I can confirm that there currently isn’t a “Request Attempts” section in the UI, which is understandably making this harder to debug on your end.
I’ve escalated this to our engineering team so they can investigate further internally. I’ll circle back with any updates as soon as I hear back from them.
In the meantime, if you've generated any new events after switching to the Cloudflare Worker, please let me know — those should immediately target the updated URL.
We’ll get to the bottom of this
I have switched back to the Cloudflare worker and have also tried generating many events...but they are not invoking the worker as I do not see any logs for the events and my DB is also not being populated. My DB will be populated if the endpoint is invoked, which is not happening
Hi Ages,
Some additional update. I have an API monitoring system in place both for dev and prod, where I get real time failure notifications if my API encounters any system errors.
To your point:
"Given all of this, it does appear that Kinde may not be retrying the previously failed event after the URL change — or retries are still being sent to the original endpoint."
Based on the logs and notifications in my monitoring system, my observation is that Kinde retries still target the original URL against which it encountered the error. i.e switching endpoint URL's on Kinde webhook does not update the target for the Kinde error retries.
After updating my webhook endpoint URL to the CF Worker and making calls like creating roles which should trigger events, I do not see any invocations to my CF worker. If there was a way for me to look at webhook event delivery logs that would have been super helpful for debugging but I'm sort of lost at the moment
Hi Maxom,
We've escalated the issue internally and will be looking into it further. As this may require input from our UK-based team, it could take a couple of days to fully investigate.
In the meantime, if possible, could you please share any relevant logs, screenshots of errors, or other supporting details? This will help us provide the necessary context for our team to troubleshoot effectively.
We'll keep you updated as we make progress.
Hi Ages,
Thanks for the response. I have shared all the logs, screenshots when the endpoint is manually invoked showing that it is publicly accessible and is configured properly with Kinde (JWKS etc.)
I have no other information because my endpoint is not being invoked by Kinde for the webhook events and Kinde does not provide any visibility into the Webhook delivery in the dashboard
Hi Maxom,
As mentioned earlier, we've escalated this internally and are looking into it. It may take a couple of days, especially since we may need to involve our UK-based team for further troubleshooting. In the meantime, we’re continuing to work on gathering more information, and your logs have been very helpful for context.
I understand the difficulty of not having visibility into webhook delivery through the dashboard. Rest assured, we're taking this into account as we investigate the issue.
If you have any further updates, questions, or if there's anything else you'd like us to look into, please feel free to share it. We’ll keep you informed as we make progress.
Thanks again for your cooperation.
Hi Maxom,
Just to clarify, when the url is initially set to your prod endpoint it doesn't work at all, and when you're trying to trigger a failed webhook event and change the endpoint for the retries it also doesn't work? I think the issue with the debugging part is that once a webhook has been triggered the retry attempts will all be on the original url, you can't change this in between attempts.
As for the main prod issue it sounds like the requests are being blocked by cloudflare, are there any logs you can use to debug this? If you provide me with your kinde domain, region if you know it and the endpoint you're trying to use I can take a look at the webhook request logs to see what the returned status code is from the attempts.
Just to clarify, when the url is initially set to your prod endpoint it doesn't work at all, and when you're trying to trigger a failed webhook event and change the endpoint for the retries it also doesn't work? I think the issue with the debugging part is that once a webhook has been triggered the retry attempts will all be on the original url, you can't change this in between attempts.
As for the main prod issue it sounds like the requests are being blocked by cloudflare, are there any logs you can use to debug this? If you provide me with your kinde domain, region if you know it and the endpoint you're trying to use I can take a look at the webhook request logs to see what the returned status code is from the attempts.
Hi David,
Yes, from my API monitoring system logs, I figured out that retry attempts are going to the original url.
It feels like there is some issue going on between Kinde - Cloudflare interactions as directly invoking the endpoint works. For the Kinde webhook events to Cloudflare, there are no invocation logs that I can see.
Is there a way to DM the details to you ?
Hi Maxom,
Sure if you join our slack community you can DM me there: https://join.slack.com/t/thekindecommunity/shared_invite/zt-25gshkj52-AAn0R3V86WWsWkd8IH\~\~0g
Alternatively you can email me directly on [email protected]
Just an FYI I'm out of office tomorrow.
Sure if you join our slack community you can DM me there: https://join.slack.com/t/thekindecommunity/shared_invite/zt-25gshkj52-AAn0R3V86WWsWkd8IH\~\~0g
Alternatively you can email me directly on [email protected]
Just an FYI I'm out of office tomorrow.
Hi David, no worries.
The Slack link does not seem to work for some reason so I have emailed you directly. Thanks
Hello, @maxom
You can also try to join the community by going to the link that appears on the main page: https://docs.kinde.com/
I have added a screenshot. The link may change each time, so this is one effective way to join:
Hi Maxom,
Thanks for sending over the details, I can confirm I can see in the logs the outbound requests failing after 6 attempts on error 'Endpoint returned invalid status code'. The code being returned is a 403 representing forbidden so it sounds like this is being blocked by an earlier service before it hits your app. Your domain is in Sydney, if possible could you try whitelisting these IPS 13.237.242.51, 13.54.159.217
Thanks for sending over the details, I can confirm I can see in the logs the outbound requests failing after 6 attempts on error 'Endpoint returned invalid status code'. The code being returned is a 403 representing forbidden so it sounds like this is being blocked by an earlier service before it hits your app. Your domain is in Sydney, if possible could you try whitelisting these IPS 13.237.242.51, 13.54.159.217
Thanks David, I’ll try this out.…As my endpoint is a Cloudflare worker where the requests are always proxied by Cloudflare could it be that Cloudflare is blocking your IP’s before it hits my endpoint?
Hi David, the issue still persists...you should see 2 requests in your logs....one for Create Permission. This request was made without whitelisting the IP's to confirm the current behaviour again. The second request should be a Delete Permission request where both the IP addresses were whitelisted and all the setting for cloudflare rate limiting and security was turned off for the 2 IP's...but still have the same issue. Normal requests go through without any problems. The webhook requests are not being received as I see no logs for webhook requests.
Hi Maxom,
Thanks for your update and for testing the whitelisting and security settings.
Since you’re still not seeing the webhook requests even after whitelisting the IPs and disabling Cloudflare security settings, it does seem like something else might be blocking these requests upstream, possibly before they reach Cloudflare.
I’ll discuss this with David to see if there are any additional details, headers, or configurations we should review, or if he has further suggestions.
In the meantime, if you have any other details or logs that could be useful for debugging, please feel free to share them.
Hi Ages, I have disabled any mutative actions on the webhook endpoint. All it currently does is console logs the event which it receives. David has the information around the endpoint URL. Feel free to hit it directly if you want (from Postman or code etc) if that helps a bit with troubleshooting. As discussed earlier, the JWKS URI implementation is done properly, so you can try hitting it with a random valid JWT that you can create internally or you can hit it directly without any payload and you should see a 500 ISE with the response:
This at least indicates the endpoint is reachable over the internet
Hi Maxom,
I'm not personally familiar with Cloudflare, but doing a bit of research the following suggestions might be worth a try to narrow down this issue:
Security → WAF → Custom Rules and Managed Rulesets in the Cloudflare dashboard. Temporarily disable or modify any that might be blocking you.
Security → Settings → Security Level and consider setting it to “Essentially Off” temporarily for testing.
Security → Settings → Browser Integrity Check and disable it for testing.
Check for any country-level blocks under Firewall Rules.
Check Security → Bots → Bot Fight Mode. Disable it if enabled.
Review Security → WAF → Rate Limiting Rules. (frequency of webhook requests may look suspicious with the retries)
The IP whitelisting I believe should be done at Tools → IP Access Rules, i.e .at Cloudflare level, not just the server or hosting panel.
If none of the above works you can try creating a Page Rule to disable security features for your specific URL or the IP range.
I'll forward this issue to one of our team members more familiar with Cloudflare and infra who might be able to offer some more suggestions.
I'm not personally familiar with Cloudflare, but doing a bit of research the following suggestions might be worth a try to narrow down this issue:
Security → WAF → Custom Rules and Managed Rulesets in the Cloudflare dashboard. Temporarily disable or modify any that might be blocking you.
Security → Settings → Security Level and consider setting it to “Essentially Off” temporarily for testing.
Security → Settings → Browser Integrity Check and disable it for testing.
Check for any country-level blocks under Firewall Rules.
Check Security → Bots → Bot Fight Mode. Disable it if enabled.
Review Security → WAF → Rate Limiting Rules. (frequency of webhook requests may look suspicious with the retries)
The IP whitelisting I believe should be done at Tools → IP Access Rules, i.e .at Cloudflare level, not just the server or hosting panel.
If none of the above works you can try creating a Page Rule to disable security features for your specific URL or the IP range.
I'll forward this issue to one of our team members more familiar with Cloudflare and infra who might be able to offer some more suggestions.
Hi David, None of the above suggestions work
Hi @maxom, just following up here — I’ve sent you a detailed message via our earlier chat a couple of hours ago with a complete working approach using Cloudflare Pages Functions, including a ready-made repo and full payload examples. Let me know if you didn’t see it or need help setting it up — happy to assist further.
Hi,
I’ll take a detailed look tonight. But on a quick glance our code is similar to yours. Need to look at cloudflare config. Also I’m using workers and not pages function. Though pages functions are built on top of workers, I need to see what difference exist
As I’m not seeing any logs or invocation metrics on my end, it has been really hard to debug because from my POV requests are not being sent because I do not see any logs/metric showing that an invocation hit my endpoint
I can see all other invocations to the endpoint except the Kinde webhooks
Hi @maxom, could you please share the webhook URL?
Feel free to post it via chat or email it to [email protected] if you prefer.
Sent it to you in the chat
Thanks, I'll check it out now
Hi @maxom, just wanted to follow up with something that may help move things forward.
I’ve tested setting up a Kinde webhook using a Cloudflare Worker (not Pages Functions this time), and I was able to receive the user.authenticated event successfully — so this confirms that the webhook mechanism does work end-to-end in a Cloudflare Worker environment.
This makes me think there might be something subtle in your setup that’s blocking or filtering Kinde’s requests before they hit the Worker. I’m happy to share the exact code and deployment I used (it’s very similar to what I shared previously for Pages Functions) in case that’s useful for comparison.
If it helps, we can also try setting your environment’s webhook URL to the one I’ve deployed — just temporarily — and see if it receives events successfully. That way, we can isolate whether the issue lies in the Worker runtime or the network/security layer.
I’ve attached a screenshot here showing the webhook log that was successfully received in my Worker (including the decoded payload)
Let me know if you’d like to go ahead with this test, or if you’d prefer I send over the working Worker code to try out on your end.
Happy to help however I can!
Thanks for the information Zaki, I agree with you on the part that there might be some setup from Cloudflare.
See, from my POV, I’m not seeing any metrics/logs indicating that I’m receiving Kinde webhooks. David confirmed that the requests were being generated but getting a 403 error, which is a Forbidden error, which essentially means “I can see you but I’m not going to allow you” kinda block.
I have whitelisted the IP’s but still facing the same issue. I have been actively trying to troubleshoot and figure out what is happening.
As discussed with you over the chat, I’m going to keep digging into why I’m not receiving the events.
But for me to move forward, is there an approach you can suggest where I do not have to rely on the webhooks ?
In order to populate the rows in my table
Hi @maxom, thanks for confirming — and completely understood about wanting to move away from webhooks for now.
If you're looking for a webhook-like experience without using Kinde's webhook feature, here are a few reliable alternatives you can implement:
1. Frontend-triggered Sync using Tokens (Recommended Short-Term Fix)
After a user logs in or signs up, your frontend can send a request to your backend, passing the ID token.
Your backend then verifies the token and creates or updates the user record in your DB.
2. Scheduled Sync via Kinde Management API
You can run a cron job (every few minutes or hourly) that fetches all users from the Kinde Management API and ensures your database stays up to date.
This is ideal for reconciling data over time and works well alongside method 1.
3. Workflows for External Sync
You can also explore Kinde Workflows for more advanced automation — for example, syncing new user data to external systems like HubSpot or other services.
Let me know if you’d like help setting any of these up or verifying the token handling logic — happy to jump in and assist.
I have already implemented 2, I’ve made some progress on 1 by creating a middleware but I’m trying to figure out how to reduce the number of calls to my DB. How do you identify the login/signup event from the frontend. Is it with the callbacks as discussed in the chat where the event is on the onError callback ?
And can I identify only the signup event similar to the webhook event but from the React SDK ?
Hi @maxom,
If your goal is to identify only signup events, I’d recommend going with option 3 (Workflows).
We’ve actually put together an example in our docs that shows how to trigger a workflow for new user signups and sync that data to external systems — Workflow example – Sync new user data
Let me know if you’d like a hand setting that up or customizing it for your use case — happy to help!
Kinde docs
Workflow examples
Our developer tools provide everything you need to get started with Kinde.