Why hasn't StreamPark standardized a built-in SMS alert channel?

StreamPark's built-in alert channels — Email, DingTalk, WeChat Work, and Lark — all have one thing in common: each has a single, widely used API that the whole community can integrate against once. SMS doesn't share that property.

SMS delivery is fragmented by provider and by country: which SMS gateway a company uses, its authentication scheme, its message format, and even its pricing model differ enough that there's no one integration that would work for most StreamPark users the way a DingTalk robot integration does. Building and maintaining first-class support for every regional SMS provider isn't a good use of a shared open-source project's limited maintenance effort relative to the number of users each individual provider would actually serve.

The practical workaround, used by teams that need SMS in production, is StreamPark's generic webhook-style extensibility: implement the SMS send as a small service that StreamPark's alert mechanism calls (via webhook, or a lightweight custom listener on job state), and let that internal service talk to whichever SMS gateway the company already has a contract with. This keeps the SMS provider choice — and its maintenance burden — local to the company that needs it, rather than baked into the shared project.