Updates: Check the release notes for new features and product updates.

Best practices

Stay organized with collections Save and categorize content based on your preferences.

When you interact with Verified SMS, keep the following best practices in mind.

Wait for message storage confirmation before sending SMS messages

When you store messages with the Verified SMS API, the API returns 200 OK when the Verified SMS platform stores and acknowledges the message hashes. To make sure that users' devices can properly verify your messages, wait until you receive the 200 OK response to send messages via SMS. Otherwise, users might receive your SMS messages before the Verified SMS platform has stored them, which would lead to the Messages app marking your messages as unverified.

Similarly, if you plan to send multiple messages to a user one after another, wait for a 200 OK response for each message before you send it. You can choose to store all messages before sending any SMS messages or choose to store each message in the sequence before you send it, whichever makes more sense with your business logic. By waiting for each message's 200 OK response, whether up-front or in sequence, before sending the message to the user via SMS, you ensure that all of your messages appear as verified on the user's device.

Only send SMS messages

When you communicate with users, communicate only with verified SMS messages. The Verified SMS Platform doesn't support MMS or RCS:

  • If a conversation includes MMS messages, those messages appear as unverified.
  • If a conversation includes one or more RCS messages, the conversation doesn't display brand or verification information, even if the conversation or messages previously displayed that information.

Hash and store all SMS messages you send from your sender ID

Hash and store all SMS messages you send, including responses to user-originated messages like "STOP" and "HELP". If the user has received one or more Verified SMS messages from your sender ID but then receives a message that hasn't been hashed and stored with Verified SMS, that message appears as unverified, even if the message was legitimate.

Hash possible segments of SMS messages you send

Not all carriers support SMS concatenation, so if you send message content that can't fit in a single SMS message, users might receive your content across multiple message segments. In this case, the Messages app identifies each segment as a message and attempts to verify each segment individually. If each message segment isn't individually hashed and stored with Verified SMS, the Messages app displays the segments as unverified.

Hash all expected message segments of SMS messages you send based on the SMS concatenation and splitting behaviors of the operators you sent messages through. Reach out to operators to understand their SMS concatenation and splitting logic.

Maintain open connections with Verified SMS

For optimal hash storage throughput, maintain and reuse connections with Verified SMS when storing multiple batches of hashes rather than opening and closing connections with each storage request. For example, when asynchronously storing hashes with the Java SDK, reuse the VerifiedSmsServiceClient object until you finish storing all hashes.

Consistently contact users with a single sender ID

When you communicate with users through a single sender ID, the Messages app displays all of your messages in a single conversation. If you send messages to a user from multiple sender IDs, messages appear in conversations dependent on their sender ID. When users have to switch between conversations to communicate with your brand, it degrades the user's conversational experience.

If you choose to send messages from multiple sender IDs, use each ID for a specific purpose. If users can anticipate particular experiences from specific conversations, this presents an overall better, if not ideal, user experience compared to mixing messages between sender IDs and conversations.

Implement retries with exponential backoff

When calling any API, it's possible for a call to fail because of infrastructure issues, service overload, QPS limits, and myriad other errors. To recover from failed API calls gracefully, implement retries with exponential backoff.

Using retries with exponential backoff, your infrastructure automatically

  1. Identifies a failed API call
  2. Sets the initial wait duration and the maximum number of retries
  3. Pauses for the wait duration
  4. Retries the API call
  5. Assesses the API call response:

    • If a success, proceeds with next step in the workflow
    • If a failure, increases the wait duration and returns to step 3
    • If a failure after the maximum number of retries, enters a fail state

Ideal wait durations and the ideal maximum number of retries vary by use case. Determine these numbers based on the latency requirements of your infrastructure and workflows.

Track message verifications with verification receipts

If you register a webhook, Verified SMS sends a verification receipt for each message users' devices successfully verify. Use verification receipts, and the included postback data, to track the verification status of individual messages.

Contact us before you stop storing messages

If you decide to stop storing messages with Verified SMS, continue storing messages until you contact us and we confirm that your sender ID is no longer associated with Verified SMS.

If your sender ID is still associated with Verified SMS and you send messages without storing them, the Messages app marks your messages as unverified.

When your sender ID is no longer associated with Verified SMS, the Messages app won't attempt to verify any SMS you send from your sender ID.

Next steps

Before you begin storing message hashes with Verified SMS,

Once you've done that, you're ready to send a verified message.