One quick glance on the left-side navigation menu reveals the InfoSlips stack. This Documentation is for every available API endpoint and a webhook. This Documentation contains the entire InfoSlips API offering.
Remember to log in. Documentation and code examples are personalized, making them easier for you to use.
Get your login credentials and API key from your InfoSlips Project Manager.
Log in API.
While InfoSlips API is free to explore for everyone, you will need an InfoSlips account to use it. After the sign-up process, you will get your API key and credentials, which you need to start using the InfoSlips API.
We support multiple authentication methods like an API key and OAuth 2.0. Our recommendation is to use the API key whenever possible.
Each InfoSlips account has its unique Base URL, which you should use in every API request you make. If you are currently logged into InfoSlips, you will find your Base URL at the top of this page. It will already be injected in every API endpoint and code example throughout the Documentation. You need to use it in your API requests like in this example:
API request example
We use the base URL to route your request to the correct "regulatory region" and optimize your traffic between data centers with the region. Our Support teams also use the base URL for troubleshooting.
When upgrading to a major version, carefully review the specific library changelog, read the relevant migration guide where available, and, of course, test the newly upgraded integration.
For each API endpoint, we provide one or more use case examples. Each use case has including/excluding parameters on how to complete a task (e.g., Send basic text SMS, send scheduled SMS, send SMS in a specific language, etc.) Each code example is available in multiple programming languages, as well as cURL command and as request payload in JSON; Code examples are auto-generated from the {????????}. You can copy code examples and use them in your project.
We provide the result status codes(which are sent back by the server for any HTTP transaction) and API status codes when it comes to status codes. Find the API Status codes in the response of sent message(s), delivery reports, and message logs. They are there to help you track the status of sent messages but can also be very useful when troubleshooting. Like status codes, error codes can also be returned as part of the response for the sent message(s) and delivery reports.
For detailed information, refer to Response Statuses and Error Codes.
Each of our 200+ documented API endpoint URLs contains a current API version number. The endpoint version will change only if a breaking change is introduced. Adding a new field, for example, is not considered a breaking change. However, removing a filed or a model structure change is a breaking change. When you introduce a new version, the old one is labeled as "deprecated."
We will never completely retire an API endpoint without notifying you in advance. At least six months before we retire that endpoint.
There are exceptions to this rule. For example, for endpoints labeled as "early access." In those cases, you need to be prepared to keep up, iterate faster and experiment with us. Even though the endpoint is flagged as early access, we will notify you about the change if we detect in our logs that you have been using API recently.
As always, we appreciate your feedback, but it's precious to us in this phase, so please reach out to us.
The question we often get is how much traffic our API handle can. This depends on which API endpoint is called.
Message sending APIs do not have an upper limit. Many of the largest global enterprises are sending messages over our APIs, and we have enough capacity to handle their traffic peaks with resources to spare. However, it would be best to keep in mind that bottlenecks may occur with specific channel providers, which sit between InfoSlips and message recipients.
Every API endpoint that is not sending messages is configured to throttle requests if the usage goes well over its common use cases. If this happens, you will get an HTTP status code 429 (Too Many Requests). It is usually a sign that you are using the API endpoint in a way that was not designed to be used. In these situations, you may want to explore other endpoints which may be more suitable for your use case, or you could reach out for advice.
Our throttling mechanism is configured based on the maximum number of requests in a unit of time. So if you stop sending API requests and wait it out a bit, you will be able to call the API again.
We are working extra hard to make the smoothest experience for developers using our API. One of the ways we try to make that happen is by focusing on consistency in following specific approaches, standards, and practices.
You may have noticed that code examples in our Documentation are not URL encoded. The major reason behind such a decision was to keep our code examples easy to read and understand. If are dependent on a system, programming language, or library that requires explicit URL encoding for request query parameters, you will need to do it yourself. Moreover, for most programming languages and libraries that trigger HTTP calls, that will be done under the hood.
If you got stuck, here's what you can do: