My app uses Twilio to send SMS messages. Each night, it queues notifications to Twilio (using their new “Schedule Messages” functionality) that get released the following day based upon the customer’s desired send time and the recipient’s timezone. To enable statusing of the SMS, each call includes a callback to a webhook in my app that updates the message status accordingly (fires each time the status changes - which is several times per message).
The good news is that the connections work fine and I am receiving the message status as designed. The bad news is that the callback is exceeding the Bubble API rate limit (returning a 429 to Twilio, causing an HTTP retrieval warning on their end). My app continues along, however, I miss some status updates.
I understand that one option is to increase capacity. However, as I scale the app, I remain concerned that the number of status changes x the number of messages will continue to exceed the threshold.
I am looking at the following options:
Place a conditional on the webhook API that only fires on “delivered”, “undelivered” and “failed” (I don’t believe this will have an effect given that the webhook still needs to fire)
Experiment with the Twilio Callback connection overrides (fragments that allow configuration of elements such as connection timeout, retries, etc.)
Has anyone else in the community run into this problem and come up with a creative solution?