Short answer: for B2B SaaS app alerts, choose an SMS API by whether webhook delivery events and polling results can feed one idempotent status ledger, then suppress a recipient only after a documented terminal failure; don't let either transport write directly to the suppression list.
That separation matters more than the shape of a send call. A callback can be delayed, duplicated, or delivered out of order, while a poller can observe a newer state before an older callback arrives. If both paths mutate customer eligibility, a routine ordering race can silence a valid recipient or repeatedly target an invalid one. The safe design is smaller: ingest observations, resolve them under one state policy, and make suppression a separate, auditable decision.
This is also where an apparently simple comparison gets uncomfortable. Twilio, Vonage, and AWS End User Messaging SMS should face the same contract test; a feature grid can't prove which event stream fits a particular application's retention window, compliance controls, and recovery targets. The winner is the integration whose documented states can be normalized without guessing.
How should a simple SMS API compare webhook and polling delivery status?
