<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[Topics tagged with webhook]]></title><description><![CDATA[A list of topics that have been tagged with webhook]]></description><link>https://fusionauth.io/community/forum/tags/webhook</link><generator>RSS for Node</generator><lastBuildDate>Fri, 07 Aug 2026 21:51:33 GMT</lastBuildDate><atom:link href="https://fusionauth.io/community/forum/tags/webhook.rss" rel="self" type="application/rss+xml"/><pubDate>Invalid Date</pubDate><ttl>60</ttl><item><title><![CDATA[Calling AWS API Gateway with SigV4 from FusionAuth Lambdas: Limitations and Recommended Architecture]]></title><description><![CDATA[<p dir="auto">You’re correct: FusionAuth’s Lambda environment does not provide access to external libraries (including AWS SDKs or SigV4 helpers), and there is no secure secrets store available to Lambdas. That means if you need AWS SigV4 signing from inside a Lambda, you would have to implement the signing logic yourself and embed any required credentials directly in the Lambda code—this is generally not considered secure.</p>
<p dir="auto">Also, if you are using FusionAuth Cloud, you cannot place Lambdas into your private network (for example, the same VPC/network as your API Gateway), so that option isn’t available in hosted deployments.</p>
<p dir="auto">If you need this capability, the recommended approach is typically to move the signing and secret handling into a system you control (for example, a backend service that FusionAuth calls), rather than performing SigV4 signing directly in a FusionAuth Lambda.</p>
<p dir="auto"><strong>Related issue tracking:</strong><br />
<a href="https://github.com/fusionauth/fusionauth-issues/issues/1629" rel="nofollow ugc">https://github.com/fusionauth/fusionauth-issues/issues/1629</a></p>
]]></description><link>https://fusionauth.io/community/forum/topic/3085/calling-aws-api-gateway-with-sigv4-from-fusionauth-lambdas-limitations-and-recommended-architecture</link><guid isPermaLink="true">https://fusionauth.io/community/forum/topic/3085/calling-aws-api-gateway-with-sigv4-from-fusionauth-lambdas-limitations-and-recommended-architecture</guid><dc:creator><![CDATA[wesley]]></dc:creator><pubDate>Invalid Date</pubDate></item><item><title><![CDATA[Why Webhook Transaction Settings Are Greyed Out in FusionAuth Cloud for User and Registration Events]]></title><description><![CDATA[<p dir="auto">This is a known bug, and it looks like the underlying issue has already been identified and fixed. The fix will be included in the next FusionAuth release.</p>
]]></description><link>https://fusionauth.io/community/forum/topic/3084/why-webhook-transaction-settings-are-greyed-out-in-fusionauth-cloud-for-user-and-registration-events</link><guid isPermaLink="true">https://fusionauth.io/community/forum/topic/3084/why-webhook-transaction-settings-are-greyed-out-in-fusionauth-cloud-for-user-and-registration-events</guid><dc:creator><![CDATA[wesley]]></dc:creator><pubDate>Invalid Date</pubDate></item><item><title><![CDATA[How to Track Entity Changes in FusionAuth Using the Audit Log API]]></title><description><![CDATA[<p dir="auto">Yes, you would need something on your end to poll the Audit Log to fetch changes made to the Entities. Currently. there's no way to enter a log into the system logs (fusionauth-app.log) or otherwise control what goes in there. We do have a similar example for Cloudwatch on exporting Login Records to Cloudwatch which should be helpful.</p>
<p dir="auto"><a href="https://fusionauth.io/docs/operate/monitor/cloudwatch" rel="nofollow ugc">https://fusionauth.io/docs/operate/monitor/cloudwatch</a></p>
]]></description><link>https://fusionauth.io/community/forum/topic/3030/how-to-track-entity-changes-in-fusionauth-using-the-audit-log-api</link><guid isPermaLink="true">https://fusionauth.io/community/forum/topic/3030/how-to-track-entity-changes-in-fusionauth-using-the-audit-log-api</guid><dc:creator><![CDATA[wesley]]></dc:creator><pubDate>Invalid Date</pubDate></item><item><title><![CDATA[Assigning Roles in FusionAuth Based on Identity Provider Login Source]]></title><description><![CDATA[<p dir="auto">This is a little tricky since a user could log in from either provider at any given time. The JWT populate lambda only has access to the user object and the registration object so you would need something on either of those to reference in the lambda. Each time a user logs in from a Identity Provider, the user in FusionAuth gets updated with the user data from the IdP. So for the JWT populate to work, you would need both providers to have a custom data field that maps to the same user.data field in FusionAuth. Then have the JWT populate Lambda map this user.data to either a custom claim or to the roles claim in the JWT, whatever works to determine the internal role on your side. Essentially this field would get updated or overwritten every time the user logs in and which would means the JWT from that login should have the correct "role".</p>
<p dir="auto"><a href="https://fusionauth.io/docs/extend/code/lambdas/jwt-populate" rel="nofollow ugc">https://fusionauth.io/docs/extend/code/lambdas/jwt-populate</a></p>
<p dir="auto">A JWT populate lambda runs whenever a JWT is minted and the reconcile lambda runs whenever a user logs in from an IdP. Which means there is a scenario if a user is logged in on both networks at the same time, it would not be accurate since the JWT from both sessions would be reading from user.data which got updated by the last IdP login. Something like the following feature would also likely be enough to solve this problem for you, we have a similar field on Webhooks but not in JWTs or Lambdas which would detail which IdP used to login.</p>
<p dir="auto"><a href="https://github.com/FusionAuth/fusionauth-issues/issues/1483" rel="nofollow ugc">https://github.com/FusionAuth/fusionauth-issues/issues/1483</a></p>
]]></description><link>https://fusionauth.io/community/forum/topic/3028/assigning-roles-in-fusionauth-based-on-identity-provider-login-source</link><guid isPermaLink="true">https://fusionauth.io/community/forum/topic/3028/assigning-roles-in-fusionauth-based-on-identity-provider-login-source</guid><dc:creator><![CDATA[wesley]]></dc:creator><pubDate>Invalid Date</pubDate></item><item><title><![CDATA[How to Block Logins Based on IdP Links in FusionAuth Without Storing API Keys in Lambdas]]></title><description><![CDATA[<blockquote>
<p dir="auto">Since we can’t store API keys in code,</p>
</blockquote>
<p dir="auto">FYI, with the release of 1.64.0, you now can store secrets elsewhere and have lambdas retrieve them.</p>
<p dir="auto">See <a href="https://fusionauth.io/docs/extend/code/lambdas/#secrets" rel="nofollow ugc">the documentation for more details</a>.</p>
]]></description><link>https://fusionauth.io/community/forum/topic/3023/how-to-block-logins-based-on-idp-links-in-fusionauth-without-storing-api-keys-in-lambdas</link><guid isPermaLink="true">https://fusionauth.io/community/forum/topic/3023/how-to-block-logins-based-on-idp-links-in-fusionauth-without-storing-api-keys-in-lambdas</guid><dc:creator><![CDATA[dan]]></dc:creator><pubDate>Invalid Date</pubDate></item><item><title><![CDATA[Why FusionAuth Webhooks Show ONE_TIME_PASSWORD Authentication Type for Logins]]></title><description><![CDATA[<p dir="auto">Great question—this often causes confusion.</p>
<p dir="auto">In FusionAuth, logging in after a <strong>Forgot Password</strong> flow is tracked as <strong>ONE_TIME_PASSWORD</strong>. That’s because, technically, FusionAuth uses a one-time password during that process. For example, if you look at the <a href="https://fusionauth.io/docs/apis/users#change-a-users-password" rel="nofollow ugc">Change a User’s Password API</a>, it returns a one-time password token. On the hosted pages, FusionAuth automatically consumes this token to sign the user in immediately after they reset their password via the forgot password link in their email.</p>
<p dir="auto">So even without traditional OTP or MFA configured, these login events can appear as <strong>ONE_TIME_PASSWORD</strong> due to password reset flows.</p>
]]></description><link>https://fusionauth.io/community/forum/topic/3004/why-fusionauth-webhooks-show-one_time_password-authentication-type-for-logins</link><guid isPermaLink="true">https://fusionauth.io/community/forum/topic/3004/why-fusionauth-webhooks-show-one_time_password-authentication-type-for-logins</guid><dc:creator><![CDATA[wesley]]></dc:creator><pubDate>Invalid Date</pubDate></item><item><title><![CDATA[How to Retrieve and Replay Failed Webhook Events in FusionAuth]]></title><description><![CDATA[<p dir="auto">FusionAuth provides an API to <strong>search for webhook event logs</strong>, including failed events. For example, you can use this endpoint:</p>
<p dir="auto"><strong>/api/system/webhook-event-log/search?start=&lt;timestamp&gt;&amp;end=&lt;timestamp&gt;&amp;eventResult=Failed</strong></p>
<p dir="auto">This will return all webhook events in the specified time frame that failed. More details are here:<br />
<a href="https://fusionauth.io/docs/apis/webhook-event-logs#search-webhook-event-logs" rel="nofollow ugc">Search Webhook Event Logs</a></p>
<p dir="auto">In the API response, the <strong>event</strong> section contains the original payload that was sent. While FusionAuth <strong>doesn’t currently have a built-in replay feature</strong>, you can extract this event data and <strong>manually re-send</strong> it to the webhook URL using your own REST calls.</p>
<p dir="auto">A native replay feature is on the roadmap, but there’s no confirmed timeline for its release yet.</p>
]]></description><link>https://fusionauth.io/community/forum/topic/2991/how-to-retrieve-and-replay-failed-webhook-events-in-fusionauth</link><guid isPermaLink="true">https://fusionauth.io/community/forum/topic/2991/how-to-retrieve-and-replay-failed-webhook-events-in-fusionauth</guid><dc:creator><![CDATA[wesley]]></dc:creator><pubDate>Invalid Date</pubDate></item><item><title><![CDATA[Determining User Authentication Method in FusionAuth]]></title><description><![CDATA[<p dir="auto">Yes, FusionAuth provides this information via the <strong>authenticationType</strong> claim in the JWT. This claim indicates the authentication method used, such as <strong>PASSWORD</strong>, <strong>GOOGLE</strong>, <strong>SAML</strong>, etc.</p>
<p dir="auto"><strong>How to Access Authentication Type</strong>:</p>

<strong>From the JWT</strong>:

The <strong>authenticationType</strong> claim is included in the <strong>JWT access token</strong>.
Documentation: <a href="https://fusionauth.io/docs/lifecycle/authenticate-users/oauth/tokens#access-token-claims" rel="nofollow ugc">JWT Access Token Claims</a>


<strong>From a Webhook Event (Alternative Approach)</strong>:

The same <strong>authenticationType</strong> value is included in the <strong>user.login.success</strong> webhook event.
This may be useful if your system processes authentication events via webhooks instead of decoding JWTs.
Documentation: <a href="https://fusionauth.io/docs/extend/events-and-webhooks/events/user-login-success" rel="nofollow ugc">User Login Success Webhook</a>



<p dir="auto">For additional details on JWT structure and claims, refer to: <a href="https://fusionauth.io/articles/tokens/jwt-components-explained#the-jwt-token-body" rel="nofollow ugc">JWT Components Explained</a></p>
]]></description><link>https://fusionauth.io/community/forum/topic/2933/determining-user-authentication-method-in-fusionauth</link><guid isPermaLink="true">https://fusionauth.io/community/forum/topic/2933/determining-user-authentication-method-in-fusionauth</guid><dc:creator><![CDATA[wesley]]></dc:creator><pubDate>Invalid Date</pubDate></item><item><title><![CDATA[Determining User Authentication Method in FusionAuth]]></title><description><![CDATA[<p dir="auto">Yes, FusionAuth provides this information via the <strong>authenticationType</strong> claim in the JWT. This claim indicates the authentication method used, such as <strong>PASSWORD</strong>, <strong>GOOGLE</strong>, <strong>SAML</strong>, etc.</p>
<p dir="auto"><strong>How to Access Authentication Type</strong>:</p>

<strong>From the JWT</strong>:

The <strong>authenticationType</strong> claim is included in the <strong>JWT access token</strong>.
Documentation: <a href="https://fusionauth.io/docs/lifecycle/authenticate-users/oauth/tokens#access-token-claims" rel="nofollow ugc">JWT Access Token Claims</a>


<strong>From a Webhook Event (Alternative Approach)</strong>:

The same <strong>authenticationType</strong> value is included in the <strong>user.login.success</strong> webhook event.
This may be useful if your system processes authentication events via webhooks instead of decoding JWTs.
Documentation: <a href="https://fusionauth.io/docs/extend/events-and-webhooks/events/user-login-success" rel="nofollow ugc">User Login Success Webhook</a>



<p dir="auto">For additional details on JWT structure and claims, refer to: <a href="https://fusionauth.io/articles/tokens/jwt-components-explained#the-jwt-token-body" rel="nofollow ugc">JWT Components Explained</a></p>
]]></description><link>https://fusionauth.io/community/forum/topic/2881/determining-user-authentication-method-in-fusionauth</link><guid isPermaLink="true">https://fusionauth.io/community/forum/topic/2881/determining-user-authentication-method-in-fusionauth</guid><dc:creator><![CDATA[wesley]]></dc:creator><pubDate>Invalid Date</pubDate></item><item><title><![CDATA[How should I be using the kickstart.success webhook?]]></title><description><![CDATA[<p dir="auto"><a class="mention plugin-mentions-user plugin-mentions-a" href="https://fusionauth.io/community/forum/uid/689">@pyroseza</a></p>
<p dir="auto">So it sounds like you're trying to figure out a way to know when FusionAuth has completed startup.</p>
<p dir="auto">The webhook is one way to do that. As you said, you can set up a kickstart event webhook within a kickstart file.</p>
<p dir="auto">Another way is to poll for a known value, such as a non-default tenant that you know your setup has added. That may be a simpler solution for you.</p>
<p dir="auto">Either way, you'll have to write some code to kick off the testing once you receive a signal that FusionAuth is ready.</p>
<blockquote>
<p dir="auto">I personally would have preferred if there was an API endpoint I could query is to whether or not the kickstart has completed successfully, but instead we were given a webhook and I'm not quite sure how I should be using it.</p>
</blockquote>
<p dir="auto">You'll need to write a webhook receiver that will kick off your tests (or whatever the next step of your testing setup is). I'm not quite sure how do that in one github action, but it should be pretty easy to split up a github action into two actions, a setup one (where you set everything up, including FusionAuth) and a test action (which you kick off in response to the FusionAuth webhook firing).</p>
<p dir="auto">I think you'd want the workflow_call event: <a href="https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_call" rel="nofollow ugc">https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_call</a></p>
]]></description><link>https://fusionauth.io/community/forum/topic/1525/how-should-i-be-using-the-kickstart-success-webhook</link><guid isPermaLink="true">https://fusionauth.io/community/forum/topic/1525/how-should-i-be-using-the-kickstart-success-webhook</guid><dc:creator><![CDATA[dan]]></dc:creator><pubDate>Invalid Date</pubDate></item><item><title><![CDATA[How to get populated user.data after user registraion.]]></title><description><![CDATA[<p dir="auto"><a class="mention plugin-mentions-user plugin-mentions-a" href="https://fusionauth.io/community/forum/uid/1292">@muravyov-alexey</a> Thank you!</p>
]]></description><link>https://fusionauth.io/community/forum/topic/1443/how-to-get-populated-user-data-after-user-registraion</link><guid isPermaLink="true">https://fusionauth.io/community/forum/topic/1443/how-to-get-populated-user-data-after-user-registraion</guid><dc:creator><![CDATA[dan]]></dc:creator><pubDate>Invalid Date</pubDate></item><item><title><![CDATA[Webhook question]]></title><description><![CDATA[<p dir="auto">That is correct. Each time a user is updated, a user.update event is fired, or a user.registration.update (if a registration is updated).</p>
]]></description><link>https://fusionauth.io/community/forum/topic/1154/webhook-question</link><guid isPermaLink="true">https://fusionauth.io/community/forum/topic/1154/webhook-question</guid><dc:creator><![CDATA[dan]]></dc:creator><pubDate>Invalid Date</pubDate></item><item><title><![CDATA[Deserializing webhook events in java]]></title><description><![CDATA[<p dir="auto"><a class="mention plugin-mentions-user plugin-mentions-a" href="https://fusionauth.io/community/forum/uid/766">@brian_ls</a></p>
<p dir="auto">Thanks for the contribution!  I am sure that it will be useful to others along the way!</p>
<p dir="auto">Thanks,<br />
Josh</p>
]]></description><link>https://fusionauth.io/community/forum/topic/1054/deserializing-webhook-events-in-java</link><guid isPermaLink="true">https://fusionauth.io/community/forum/topic/1054/deserializing-webhook-events-in-java</guid><dc:creator><![CDATA[joshua]]></dc:creator><pubDate>Invalid Date</pubDate></item><item><title><![CDATA[Looking for docs on configuring webhook for kafka]]></title><description><![CDATA[<p dir="auto">An FYI for anyone reading this in the future. The kafka integration does have been revised and include a docker based example.</p>
]]></description><link>https://fusionauth.io/community/forum/topic/1003/looking-for-docs-on-configuring-webhook-for-kafka</link><guid isPermaLink="true">https://fusionauth.io/community/forum/topic/1003/looking-for-docs-on-configuring-webhook-for-kafka</guid><dc:creator><![CDATA[dan]]></dc:creator><pubDate>Invalid Date</pubDate></item></channel></rss>