These Bots are stateless and does not hold information about the user upon page refresh.
This is a very deliberate design decision. As it has a lot of advantages, the primary one being that it makes it very easy and simple for the Bot Makers to manage the user-bot interaction as a small chunk of conversation that you have in one go.
As soon as you add statefulness in the bot conversation, the complexity to manage the bots increases But so does the capability of the bot. So we need to be very careful about adding this extra complexity in the system and make sure that the tradeoff of the extra capability is truly worth it.
We do have few ideas to bring in some statefulness in the bot conversations in an easy way, which i have discussed on another thread about how to retrieve the partial conversations for a bot from the TARS DB itself, when passed a unique ID. This will be config controlled statefulness, and not going to be the default behaviour. But that’s for later.
For now, the easiest way to do what you are trying to acheive is by saving the last gambit number in your CRM and continue from there when the same user comes back. To do that, instead of making an API after every gambit, you can do the Zapier email based integration with your app, which can be triggered by the partial emails that you get.
Check this article to see how to do that: