Hands Callback and TournamentsResults API timing (7+)
Posted: Thu Apr 30, 2026 5:01 pm
I've built a sophisticated interface that uses callbacks and api calls to allow our site to automatically generate and provide tournament bubble tickets, to facilitate an API that automatically keeps our web-hosted website up to date on tournament results and facilitates a "high-hand" jackpot of the tournament (automatically) as well as numerous other bells and whisltes. I've been asked to see about extending the jackpot logic to facilitate a "bad-beat" progressive jackpot. I wrote the initial code which uses the Hands callback to trigger an inspection of only showdown hands, analyzes the best hands using both hole cards and, if that tournament hand qualifies as a "jackpot", pauses the tournament at the completion of the hand, all tables, sends sms message to both admins, verify and ultimately unpause the tournament. Here's the issue:
The system setting for Showdown extends the time between the cards being exposed and the start of the next hand, but the callback fires at the END of the delay and the next hand begins virtually immediately, which doesn't leave time to pause the table that just had the "bad beat". I also note that the API call for that hand of the tournament returns errors until the END of the timeout.
Suggestion: If you placed that timer AFTER the conclusion of the hand and before the next hand begins, we would have ample time to process things and do what we need. If you wanted to preserve the existing behavior (extending the time before the hand completes) you could do that by having the number be positive (Showdown seconds: 5) and if you want to insert a delay AFTER the completed hand, before the next hand begins, you could use a negative (Showdown seconds: -5). But that suggestion is only if you wanted to preserve the present timing as well.
I'm sure that this isn't something that is a major concern for most users, but without the ability to treat the delay as AFTER the hand ends, it is impossible to do the bad-beat logic using callback, and the only way that works becomes very API intensive (like setting it to 5 seconds and then polling every 2-3 seconds with API calls to tail the hands log. And that approach seems really clumsy.
The existing callback and api structure has allowed me to automate so many of the tasks involved with running sophisticated tournament formats that I applaud how you implemented Mavens. This is the first such timing issue I've run in to.
The system setting for Showdown extends the time between the cards being exposed and the start of the next hand, but the callback fires at the END of the delay and the next hand begins virtually immediately, which doesn't leave time to pause the table that just had the "bad beat". I also note that the API call for that hand of the tournament returns errors until the END of the timeout.
Suggestion: If you placed that timer AFTER the conclusion of the hand and before the next hand begins, we would have ample time to process things and do what we need. If you wanted to preserve the existing behavior (extending the time before the hand completes) you could do that by having the number be positive (Showdown seconds: 5) and if you want to insert a delay AFTER the completed hand, before the next hand begins, you could use a negative (Showdown seconds: -5). But that suggestion is only if you wanted to preserve the present timing as well.
I'm sure that this isn't something that is a major concern for most users, but without the ability to treat the delay as AFTER the hand ends, it is impossible to do the bad-beat logic using callback, and the only way that works becomes very API intensive (like setting it to 5 seconds and then polling every 2-3 seconds with API calls to tail the hands log. And that approach seems really clumsy.
The existing callback and api structure has allowed me to automate so many of the tasks involved with running sophisticated tournament formats that I applaud how you implemented Mavens. This is the first such timing issue I've run in to.