API authentication
Get your IGSendMail API token, learn how to pass it on a request, and make your first working call from the command line.
On this page›
The IGSendMail API lets you create contacts, build campaigns and pull reporting data from your own code. This page gets you from nothing to a working request. When you finish you will have a token, you will know how to send it, and you will have listed your own lists from a terminal.
Before you start
You need an IGSendMail account and a tool that can make HTTP requests. The examples here use curl, which ships with macOS and most Linux distributions and is available on Windows 10 and later.
The base URL#
Every API request goes to:
https://mail.igsendmail.com/api/v1
Endpoint paths in these docs are written relative to that base. When a page mentions /lists, the full URL is https://mail.igsendmail.com/api/v1/lists.
Use HTTPS. A plain HTTP request would put your token on the wire in clear text.
Get your token and make a request#
Copy your API token
Open your account area and find API token. Copy the value.
The token identifies your account on its own. There is no separate username or password step, and no login call to make first. Anyone holding the token can act as you against the API, which is why the rest of this page is mostly about keeping it out of the wrong places.
Send the token as a query parameter
Pass the token as an api_token query parameter on every request. There is no session and no cookie, so the token has to be present on each call individually.
https://mail.igsendmail.com/api/v1/lists?api_token=YOUR_API_TOKEN
If you already have other query parameters, add api_token alongside them with &.
Make your first call
List your lists:
curl "https://mail.igsendmail.com/api/v1/lists?api_token=YOUR_API_TOKEN"
Quote the URL. Without quotes, most shells treat & as a background operator and your request loses every parameter after the first one.
A successful call returns JSON describing the lists on your account, including each list's unique identifier. That identifier is the list_uid value the other endpoints ask for, so keep the response open while you work through the next pages.
Check what you got back
If the response is JSON with your lists in it, you are done. If it is an error, or an HTML page rather than JSON, work through the troubleshooting section below before writing any more code.
Add -i to the curl command to see the HTTP status code and response headers along with the body. The status code usually tells you more than the body does.
Keeping the token secret#
The token is a credential with the same weight as a password. Treat it that way.
Never put the token in client-side code. Anything that runs in a browser is readable by anyone who opens developer tools. That includes JavaScript on your website, a single page app, a mobile app bundle and any HTML you serve. If a page in a visitor's browser needs to reach IGSendMail, put your own server in the middle: the browser calls your server, your server holds the token and calls IGSendMail.
Never commit the token to a repository. Public repositories are scanned continuously by people looking for exactly this. Private repositories leak too, when they are forked, when a laptop is stolen, or when the repository is later opened up. Read the token from an environment variable or a secrets manager instead, and add your local environment file to .gitignore.
Do not paste it into a support ticket, a chat message or a screenshot. Those get forwarded.
If your token leaks
Regenerate it. Open your account area, generate a new API token, and the old value stops working. Then update every integration that used the old token, because they will all start failing at the moment you regenerate. Rotating a token is disruptive for a few minutes. Leaving a leaked token active is worse: someone can export your contacts, send mail as you, and delete your campaigns.
If you are unsure whether a token has been exposed, regenerate it anyway. The cost of an unnecessary rotation is a few config updates. See Account security for the rest of the account hardening checklist.
One token per account, not per integration#
Your token represents the whole account, so every integration you connect has the same access. There is no way to give a script read-only access or scope it to a single list. Two consequences follow from that:
- Only connect tools you trust with full account access.
- Keep an inventory of where the token is in use. When you rotate it, you need that list.
If something goes wrong#
You get an authentication error. The token is wrong, truncated or expired. Copy it again from the account area. Watch for a trailing space or newline picked up during copy and paste, and for a shell variable that expanded to an empty string. Print the URL you are actually requesting and look at it.
You get HTML back instead of JSON. You are probably hitting the application rather than the API. Check the path starts with /api/v1 and that you did not typo the version segment.
Your request works in the terminal but not from your code. The usual cause is a URL-encoding problem, where your HTTP library escapes the token or drops the query string. Log the final URL your library builds and compare it character by character with the working curl command.
Everything fails at once after months of working. Somebody regenerated the token. Check with whoever else administers the account before debugging further.
Last updated September 10, 2026