Create a new one cause the old thread it appears this question is not being answered. I've added a Generic HTTP connector (POST) step to my sign-up-or-in flow. The step is configured with async=true, a custom header, and a JSON payload using flow context variables (user.userId, user.tenantIds, sourceIP). The step is wired between the "Is new user?" condition (existing user path) and the "End" (logged-in) step. The flow completes successfully and the user gets a session, but the HTTP connector never fires — our server receives no request. When I tried placing the step on the magic link polling path, I got nonce validation errors: [E108201] Error validating flow nonce: Request sequence validation failed Questions: 1. Where in the flow can an HTTP connector step be placed without breaking nonce validation? 2. Is there a flow execution log that shows whether the connector step was attempted and what error occurred? 3. Does async=true on a connector step actually execute the request, or does it skip it?

@Rahul Rijhwani can you assist in following up here?

Hi @Anand Sheth let me walk through each of your questions. 1. Where to place an HTTP connector without breaking nonce validation The nonce/sequence error on the magic link polling path is expected and by design. The

[E108201] Request sequence validation failed

error is triggered when additional round-trips are injected into a path that Descope's flow execution engine validates as a fixed sequence — specifically the polling path, where a pending token is resolved. Any extra step added there breaks Descope's internal sequencing checksum for that execution context. Safe placement rules, per the docs: Connector steps should be placed after authentication has completed — i.e., after the magic link has been verified and the user identity is resolved. The documented pattern is to connect the connector step "after successful authentication of the user." Your current placement (between "Is new user?" and "End" on the existing user path) is architecturally correct. The fact that the user gets a session suggests the flow itself succeeds — the connector is the problem, not the placement position per se. • The magic link polling path is specifically off-limits for connector steps. That path is the "waiting" branch where the browser polls for the token to be clicked; it has strict sequence validation and must not have side-effecting steps injected into it. What you should avoid: • Any step placed between the magic link send action and the token verification/polling resolution. • Any step placed after a screen that involves active token state (the click-to-verify moment). 2. Flow execution logs There are three places to look, and they serve different purposes: Flow Runner (best for active debugging): The Flow Runner writes error messages and debugging statements for connectors to its Runner messages. When running a flow, Descope logs the request sent to the connector and the response received. Navigate to your flow in the Descope Console and click the blue Run button at the top right. If your connector step is being reached and failing, or being silently skipped, this is where you'll see it. Troubleshooting Logs (best for end-user issues): Descope allows you to view flow logging within the Troubleshooting Logs section of the console, which is helpful for troubleshooting issues reported by end users since it shows the history of errors that occurred within a flow. These logs include failures in Descope flow actions, including connector actions. When it comes to connectors, the complete error response from the connector is logged to enable troubleshooting. Audit trail: Note that flow webhooks using a Generic HTTP connector step do not, by themselves, create audit events in Descope's audit trail or in audit streaming. If you want the connector invocation recorded in the audit log, add a "Generate Audit Event" action next to or right after the webhook step — those events show up on the Audit page and are streamed to configured Audit Connectors. 3. Does

async=true

actually fire the request? Yes, it does fire — but there's a critical caveat. When you add a connector step to a flow, you can configure it to run asynchronously. This option is for cases where the flow doesn't need to wait for the step's result to continue (like sending analytics data). When running asynchronously, the connector response will not be available in the flow context. So

async=true

is not "skip this step" — it means "fire and forget." The HTTP request should still be dispatched. However, there are a few reasons your server might see nothing: • The step is being silently skipped due to a silent error before it — if a previous step in the path caused an issue that the flow swallowed (check Flow Runner logs). • The connector is being reached but the request is failing outbound — network/firewall issue, or the Descope egress IP isn't allow-listed on your server. Descope offers static IPs via the "Use Static IPs" option in connector settings if you need to allow-list. •

async=true

means errors are swallowed silently — since the flow doesn't wait for the result, a failing async connector won't surface an error in the flow UI. The Troubleshooting Logs are the only way to see it. Recommended debugging steps: Temporarily set

async=false

so any error surfaces synchronously in the flow. Run the flow in the Flow Runner and check the runner messages panel for the connector request/response. Check Troubleshooting Logs at

<http://app.descope.com/audits/tlogs|app.descope.com/audits/tlogs>

for the complete connector error response. 1. Test the connector directly via the Test button on the connector configuration page to confirm basic connectivity. If your server still sees nothing after setting

async=false

and the Flow Runner shows the step being reached, the issue is likely network-level (outbound IP filtering). Enable "Use Static IPs" in the connector configuration and allow-list those IPs on your server.