Frequently Asked Questions

The APIs allow you to perform many of the actions that are done via the UI. Some examples include the following actions:

• Create a message envelope, with or without list targeting and scheduling information
• Retrieve a message
• Upload assets to a message
• Load a named list
• Retrieve, create and update a subscriber
• Send a triggered message to a user, including users table personalization

• Automatically subscribe/update users
• Develop your own message management UI to create/retrieve/update/target/schedule message Ids
• Trigger Welcome/Order Confirmation/Shipment Confirmation/Purchase Confirmation campaigns to your customers
• Manage content and upload it to the Enterprise platform
• Integrate with a RESTful host, submit XML or JSON payloads
• Integrate with an API to handle errors and retries
• Host your own unsubscribe page but synchronize the events with Infogroup Interactive's database in real time
• Host your own preference center but have Yesmail store the user's profile information

1. You initiate a connection to Yesmail’s systems by performing an HTTP POST, PUT, or DELETE operation for an available service.
2. The load balancer routes the request.
3. The service system takes the request’s credentials and passes them to the AAA service, which is responsible for doing authentication and authorization.
4. If the credentials are not valid, the service system will return a HTTP 401; otherwise the system will begin validating the payload based on the request schema.
5. If the payload fails schema validation, the service system will return a HTTP 400; otherwise the request is written to the JMS queue, a status resource is created with a status of SUBMITTED, and the status resource URI is returned with an HTTP 202 response code.
6. Yesmail's systems poll the JMS server for requests to process. When one is found, the service system will update the request status resource to INPROGRESS and attempt to process the request.
7. If the request is successfully fulfilled, the status resource is set to a status of COMPLETED. Otherwise, the status resource is set to a status of ERROR.

There are two basic types of requests:

• Synchronous: These are for simple, lightweight read requests such as displaying a summary of a master. Most o the HTTP GET based requests fall into this category. The request is a blocking call and the response will be returned to the client when the information has been retrieve. If the system is unavailable for some reason the HTTP status code 500 will be returned.
• Asynchronous: These requests involve either long running tasks or writing to data and are handled in a non-blocking manner. Upon receiving a request the system will queue the request, provide a Status token in the response, and return the HTTP code 202. For more information see the Status API and workflow description found in the Dev Center. Once a message has been accepted the request will be handled as soon as resources become available.

The messaging queues store requests that have been submitted to and accepted by the services system. A request will remain in the queue until the system reads it from the queue and processes it. The queues are backed by a highly available, persistent datastore which ensures that requests are tracked irregardless of server outages.

Automatic recovery has been employed for the triggered message API. If a submission of a triggered message request has encountered an error when attempting to pass the request to Infogroup Interactive’s systems, this request will be enqueued and resubmitted. If the error occurs after the request reaches the system, but before the actual work is performed, then the status of the service call gets set to an ERROR state.