Forum Discussion
Race Condition Issue between API-trigger and mail execution during Registration
Hello people,
I have this interesting case which looking for a proper solution that wont affect the UX during onboarding.
When user completes the registration process, we send a service mail with a verification link that users can verify their email addresses.
Service mail is set as API-triggered campaign and we have this race problem that sometimes the API call is prior to mail execution which gives an error: "User can't found"
Our campaign flow for user creation process on Braze contains 2 steps:
1- API call to create a ghost user (using alias and email address attribute only) to create user profile
2- API call to find the user profile and trigger the email send
3- when user clicks and verify mail --> actual user profile is created with all attributes.
4- API call to merge these user profiles.
Between step 1 and 2, API call to find user data for executing email fails.
Any user case or solution with this issue above? Support suggesting to add more delay between API calls to not face race condition, however registering a service and wait 3-4 minutes of 1st email for verification is not match with our UX flow.
Thanks in advance
5 Replies
Hey guys, it's been a while since I first had this issue. happy to see some replies :))
Thanks for your suggestions. The issue was resolved by the change to the user registration event config.
This is a 2 year old post. Selman_Balci might have moved on haha. But yes I agree with LiorPeleg approach of creating registration event and later using that event to trigger the email.
Just want to make sure I understand correctly, you first create the user via the API, and then make a separate call to send the email through the API, right?
Why not use the initial call to create the user together with a “registration” event, and then use that event as the trigger for sending the email?
This is an incredibly common race condition issue in systems dealing with rapid, sequential API calls during onboarding! While Braze Support's suggestion of adding a delay technically works, it completely degrades the UX, as you noted.
The challenge is the time lag between the database commit (User Create) and the query service update (User Look-Up/Trigger).
The Solution: Direct, Single-Call Triggering for Physical Mail
When integrating triggered direct mail, a platform like PostGrid allows you to bypass the multi-step user creation/trigger process that is causing the race condition.- Single API Call for Mail: Instead of making two separate API calls (one to create the user in Braze and a second to trigger the mail execution), your system only needs to make one direct API call to the PostGrid API at the moment the user registers. This call contains all the necessary recipient data (name, address, and the personalized verification details).
- Decoupling from Braze: By sending the mail execution command directly to PostGrid, you decouple the immediate verification process from the Braze profile creation and look-up latency. The user receives their physical verification mail without having to wait for the internal Braze profile status to stabilize.
- Braze Update: Your system can then update or create the Braze profile independently, knowing the verification mail is already in the production queue.
Direct Mail as a Verification Channel
This is also an effective way to verify user identity and address outside of email:- PURLs and QR Codes: The physical mail piece, a postcard or letter, contains a unique, trackable Personalized URL (PURL) or QR Code.
- Verification Landing Page: The PURL/QR code redirects the user to a secure landing page. Once the user clicks through and verifies, your system confirms the identity and updates the user attributes (verified status) in Braze, just as the original email link would.
This approach resolves the race condition by making the verification process independent of the internal profile synchronization delay, ensuring a fast, reliable verification experience for the user.
