Automatic Failover for Transactional Messaging (AFTM) resources
Automatic Failover for Transactional Messaging (AFTM) only provides high-availability for API-triggered transactional email, Push, and SMS messages during service disruptions. As a result, only a limited set of API functions are available at an account-specific end-point URL for AFTM API calls.
AFTM is supported for both SOAP and REST protocols, as described in this document:
- SOAP AFTM Protocols are described in the topic “SOAP-based code changes required by AFTM”.
- REST AFTM Protocols are described in the topic “REST-based AFTM WS API”.
Learn more about Responsys APIs in this video and download the Responsys API Brochure.
General Usage Guidelines
The following list provides important general guidelines for AFTM software developers. Specific programming requirements are covered in the following sections.
API User management
- It’s recommended that only one user ID per account be used for AFTM API login.
- The primary administrator of the account must create the user ID. This is the first Account Admin created in Responsys when it is configured, and this user ID is usually noted in the account user section as admin@accountname. User names are not synced from primary to secondary unless the user ID is created by the primary account administrator. If another account administrator creates the user ID, the authentication request on the failover account will fail.
- Because the Interact account user IDs must be distinct within each POD (that is, interact2 and interact5), you may be asked to create a new user ID if your primary account’s existing user ID has already been assigned in the failover POD.
- Responsys user IDs assigned as account administrator should not be used for making AFTM API requests.
- See the article “Creating API users in Responsys” for more information about creating a user ID with the correct roles for an API user.
Code guidelines
- You must never cache the IP address to which you submit your WS API requests.
- Ensure that your client systems use a Transport Layer Security (TLS) version 1.2.
- You must always recompile your software if you have made any changes or reference new URL end points.
- Same throttling policies apply to the AFTM WS API requests. Therefore, you are responsible for queuing the AFTM API requests that were not successfully processed and resubmitting them again.
- You must ensure that there are no programming errors and that the software is fully tested, such that correct data is always passed to the API functions. This will help avoid any potential problems with automatically switching to the failover account.
- You should pass as much personalization data as possible through the WS API requests.
- When the system switches between the primary and failover accounts, you may receive “INVALID_SESSION_ID” (SOAP) or “INVALID_TOKEN” (REST) errors. Ensure that your code contains logic for making multiple re-authentication attempts when an API session becomes invalid (SOAP) or the token becomes invalid (REST).