Important Information about Requirements and Security

API Support and Updates

ExactTarget is continually improving the product and the technologies that support the product. The API access to the product is regularly updated as well. We will make every effort to provide backward compatibility for a reasonable duration for API calls that are phased out. 

Note that the API uses HTTPS and other internet technologies. Use the XML API for calls involving 500 subscribers or less with a total amount of data of 5MB or less per call (please review the best practices below for more information). For larger results, such as large lists and large bulk export data, please contact your ExactTarget representative for information on our batch export process.

Serial Calls and Retries

ExactTarget recommends that calls to the API be made in a serial fashion. For example, if you are importing a list and sending the email to that list, the first step is to FTP the file and then issue the import command. The second step is to receive confirmation of the import and then issue the email send command.

Please do not run more than five async events at any one time. If you have initiated five async events, wait until one of those events is completed before initiating another event. (If you need to exceed this limit, contact Global Support for assistance.)

Likewise, if you need to retry a call, do not retry the call more than three times. If your program loops with unlimited attempts, ExactTarget will be forced to disable your API access in order to ensure system performance for all clients.

Security

Security is always critical. It becomes even more important when supporting clients in a seamless and highly integrated model. ExactTarget takes security very seriously and provides a variety of mechanisms to ensure that individuals without the appropriate system privileges cannot access client information.

Best Practices

The following list contains best practices to follow when using any third-party programming tool or object, including the ExactTarget API:

• Calls to the XML API should involve 500 or fewer subscriber per call, with a total amount of data of 5MB or less. Larger calls should use the batch XML API. Otherwise, you should alter your calls to follow the best practice guidelines.
• The ExactTarget API will time out only if the call exceeds 1800 seconds (30 minutes). With such an extensive setting, any timeout that occurs typically occurs within the client web server or the client script. If you're requesting large volumes of data, program your timeout settings accordingly.
• Communication errors and outages are always a potential factor when communicating via the Internet. Program accordingly.
• Logging is always an excellent best practice. As you begin using the ExactTarget API, we recommend that you use success and failure logs to monitor all calls that your system has made. Later, be sure to maintain at least a failure log for troubleshooting purposes. Log the following data: date, time, error, XML posted, and XML received.
• Queuing is an additional recommendation. To avoid downtime in your application, queue any calls that result in Error=0 or a communication error and re-attempt the call after a period of time (such as 15 minutes). Clear your queue once the calls have gone through.
• Follow standard XML best practices. For example, eliminate spaces between nodes and trim the values within nodes. Do not attempt to pass illegal characters (<, >, &, "). If your data contains an illegal character, use CDATA as follows:

<node><![ CDATA[insert illegal character here]]></node>

• Use POST rather than GET. GET uses a querystring and concatenates your XML to the URL. GET has some programmatic limitations for length and can result in an XML error indicating that your code is bad or is missing a closing node. Use POST to avoid these issues.
• Be sure to URL-encode all input.
• Client-side integration with the use of Flash/ActionScript and Ajax (Asynchronous JavaScript and XML) is becoming more common to build robust applications. If you're using these technologies, do not embed your user authorization in code that resides in the client-side script. As a security best practice, maintain your authorization (username and password) in your server-side proxy page that's used to post your data to the API and return the response.