Sending strategy

After obtaining your resources, creating applications and/or entities, and associating your resources with an application and/or entity (also known as resources associations), you are ready to define how your resources will be used when sending messages. This process is called defining a sending strategy.

Previously, defining a sending strategy required contacting Infobip for each case, often necessitating the creation of multiple accounts or subaccounts to support different use cases. Now, you can define your strategy for each application or application/entity combination using the Sending strategy API (opens in a new tab).

Sending strategy possibilities

With the sending strategy, you can perform the following actions:

Application-level sending strategy

This strategy is the default sending strategy and it distributes sending across the pool of senders that are automatically fetched based on the definition you specified in resources associations. It can be created on an application level, eliminating the need to create a sending strategy for each entity. We retrieve the entity provided in the API request and identify senders associated with both that entity and application. The default sending strategy can be restricted to specific countries for message termination. It can also be limited to a specific channel, with support currently available only for SMS and MMS.

Use case:

• You have 500 clients and they are sending from different resources that have different capabilities and are registered for different countries. Instead of creating sending strategies per entity and additionally per each country, you plan to send to with defined senders, Infobip will take care of this. Once your resource is registered, we know for which channels it can be used, and to which countries it can send.

Entity/application-level sending strategy

This strategy is used for client-specific setup. You can define different rules, features, and limitations for each client.

Use cases:

• You want a clear definition of what and where each entity will be sending, rather than relying on platform-defined message routing.
• You need to restrict a client from sending to countries outside a defined scope.
• You want to apply a specific set of features to select clients only.

Additional features

Geolocated sender

• When enabled, traffic is sent from one of the defined senders with the same local area code as the recipient. This approach increases the likelihood of a positive response from customers as messages appear from a local number.

  Note

  Geolocated sender can be used for terminating messages only in North America.

Sticky sender

• When enabled, the first sender used for communication with a customer will continue to be used for all future messages sent to that customer. This consistency helps build recognition and trust.

  Note

  Geolocated sender and a sticky sender can be combined.

Using additional features with sending strategies:

• If you need a specific setup for a country (for example, using a geolocated sender for the United States but not for Canada), create an additional strategy at the country level with the geolocated sender option enabled.
• To use the sticky sender feature for SMS only, and both sticky and geolocated senders for MMS across all entities under one application, create two application-level strategies. The first strategy should include both sticky and geolocated senders for the MMS channel. The second strategy should include only the sticky sender for the SMS channel.

Coming soon

• Sender type priority: Define the priority of senders when multiple senders exist for a destination country.
• Default sender: Define a fallback sender if a message cannot be sent with entity-specific senders. This can be set per entity or as a default sender at the application level.

For more information, refer to the Sending strategy management APIs (opens in a new tab).