The EAPI is based on simple HTTP requests. The design philosophy is to enable as much functionality as possible without having to involve, for example, XML parsers, so data is by default returned to you in a simple pipe-delimited (|) format, and you can perform most actions by simply using query parameters.
In general, it is not intended that you ever submit an HTML form to any URLs in this API, or that you link to the URLs from web pages. You should be using an HTTP client library, e.g. Curl (PHP/command line), LWP(Perl), or HTTPClient(Java). This applies to all calls which use authentication. In other words, do not put up a web page on the Internet with your username/password as hidden fields in a form.
Please remember to URL-encode all parameters passed! Don’t reinvent the wheel - rather use one of the many libraries available. GET requests are allowed, but we strongly recommend using POST requests, especially if submitting a message to a large number of recipients (there can be limits on the size of GET requests).
Authentication, when required, is performed by providing username and password request parameters.
All EAPI methods expect requests to supply a Content-Type header with the value application/x-www-form-urlencoded. All responses will have the Content-Type header set to text/plain.
Any HTTP response code other than 200 OK should be considered a transient error, and the request retried after a suitable interval.
EAPI calls generally include a version number, e.g.: /eapi/submission/send_sms/2/2.0
This is not a version in the sense that it is a incremented each time changes are made. Rather, it is incremented only when changes are made to the API that are incompatible with previously published specifications.
Therefore, by using a specific API version, you are guaranteed that no backwards-incompatible changes will be made. However, this does not preclude new features being added to the API version that you are using, or changes being made which we deem to be compatible with published specifications.
In principle, older API versions are maintained indefinitely. We do however reserve the right to disable such old API calls as we consider to have fallen into disuse.
In the past, we used a slightly different versioning scheme, which included the use of .../current in URLs. This scheme is no longer used, however; as usual, such older URLs as used to function in this format will continue to be available.