We offers toll-free, long code and short code SMS, conversational SMS, plus MMS. Toll-free numbers are commonly used for appointment reminders, account notifications and emergency alerts. Long codes can be used for both person-to-person (P2P) or application-to-person (A2P) use cases like chat applications and customer service. Short codes are commonly used for password resets and alerts.
The DS API uses API Keys to authenticate requests. Your API Keys carry many privileges, so be sure to keep them secure! Do not share your secret API Keys in publicly accessible areas such as GitHub, client-side code, and so forth. To use your API Key, assign it in your SDK as shown in this quickstart guide section. Using our RESTful API, you can also make requests by passing the API Key in the Authorization header
All endpoints will respond with JSON unless another format is specifically requested and supported. Our JSON responses use a format inspired by, but not directly based on, the JSON API specification. The outermost object in a response will contain the actual response data under a top-level key of data. High-level metadata will be included in the response along with the data object if needed. In addition, all records in a response will include a record_type field which specifies the type of data it represents.
One application can provide another application with real-time updates via a webhook (also referred to as a web callback or HTTP push API). A webhook delivers data to other applications as it happens, meaning you get data immediately. In the past, APIs would typically need to poll for data very frequently to get it promptly. This makes webhooks much more efficient for both provider and consumer. The only drawback to webhooks is the difficulty of initially setting them up
Requests to DS are rate limited DS Developers to ensure that the API remains responsive for all users. When the rate limit is exceeded responses with status code 429 will be returned indicating that you have exhausted the number of requests allowed in the current window. To avoid exceeding the limits we recommend that you proactively limit the rate of requests made by your application. limits are subject to change based on usage and may be adjusted to align with changes in capacity.
We include known causes and possible solutions so that API users can write logic to handle errors intelligently and debug quickly. When one or more errors are present, the top-level key in the response will be errors and not data. The value for errors will always be an array, and there will always be at least one error present when this is returned.
