Treating timed_out as a normal response, with a 55 second cap, fits scripts and CI jobs that can't receive a webhook. Returning the message id next to the code is handy too, since the caller can open the full message if the parsed code looks wrong. Is the after timestamp the intended way to make sure an older code already sitting in the inbox isn't returned?
Yes. after defaults to five minutes before the call, so a code that landed just before you asked still counts. Pass the time you requested the code as after and anything older is ignored. On timed_out, call again with the same after.
Good, that default makes sense. Passing the request time as after and retrying with the same value is the part I'd put in a code comment, because it's easy to bump it on each retry and lose the message.
StackShortlist
Proof Over Promises.
Treating timed_out as a normal response, with a 55 second cap, fits scripts and CI jobs that can't receive a webhook. Returning the message id next to the code is handy too, since the caller can open the full message if the parsed code looks wrong. Is the after timestamp the intended way to make sure an older code already sitting in the inbox isn't returned?