Skip to main content
SendPost API is built on REST API principles. Authenticated users can interact with any of the API endpoints to perform:
  • GET- to get a resource
  • POST - to create a resource
  • PUT - to update an existing resource
  • DELETE - to delete a resource
The API endpoint for all API calls is:
Some conventions that have been followed in the API design overall are following:
  • All resources have either /api/v1/subaccount or /api/v1/account in their API call resource path based on who is authorised for the resource. All API calls with path /api/v1/subaccount use X-SubAccount-ApiKey in their request header. Likewise all API calls with path /api/v1/account use X-Account-ApiKey in their request header.
  • All resource endpoints end with singular name and not plural. So we have domain instead of domains for domain resource endpoint. Likewise we have sender instead of senders for sender resource endpoint.
  • Body submitted for POST / PUT API calls as well as JSON response from SendPost API follow camelcase convention
  • All timestamps returned in response (created or submittedAt response fields) are UNIX nano epoch timestamp.
SendPost uses conventional HTTP response codes to indicate the success or failure of an API request.
  • Codes in the 2xx range indicate success.
  • Codes in the 4xx range indicate an error owing due to unauthorize access, incorrect request parameters or body etc.
  • Code in the 5xx range indicate an error with SendPost’s servers ( internal service issue or maintenance )
In SendPost all responses return created in UNIX nano epoch timestamp.

Authentication

SendPost uses API keys for authentication. You can register a new SendPost API key at our developer portal. SendPost expects the API key to be included in all API requests to the server in a header that looks like the following: X-SubAccount-ApiKey: AHEZEP8192SEGH This API key is used for all Sub-Account level operations such as:
  • Sending emails
  • Retrieving stats regarding open, click, bounce, unsubscribe and spam
  • Uploading suppressions list
  • Verifying sending domains and more
In addition to X-SubAccount-ApiKey you also have another API Key X-Account-APIKey which is used for Account level operations such as :
  • Creating and managing sub-accounts
  • Allocating IPs for your account
  • Getting overall billing and usage information
  • Email List validation
  • Creating and managing alerts and more
You must look at individual API reference page to look at whether X-SubAccount-ApiKey is required or X-Account-ApiKey
In case an incorrect API Key header is specified or if it is missed you will get HTTP Response 401 ( Unauthorized ) response from SendPost.

HTTP Response Headers

API Reference

SendX REST API can be broken down into two major sub-sections:
  • Sub-Account
  • Account
Sub-Account API operations enable common email sending API use-cases like sending bulk email, adding new domains or senders for email sending programmatically, retrieving stats, adding suppressions etc. All Sub-Account API operations need to pass X-SubAccount-ApiKey header with every API call. The Account API operations allow users to manage multiple sub-accounts and manage IPs. A single parent SendPost account can have 100’s of sub-accounts. You may want to create sub-accounts for different products your company is running or to segregate types of emails or for managing email sending across multiple customers of yours.

SMTP Reference

Simple Mail Transfer Protocol (SMTP) is a quick and easy way to send email from one server to another. SendPost provides an SMTP service that allows you to deliver your email via our servers instead of your own client or server. This means you can count on SendPost’s delivery at scale for your SMTP needs.

Integrating SMTP

  1. Get the SMTP username and password from your SendPost account.
  2. Set the server host in your email client or application to smtp.sendpost.io. This setting is sometimes referred to as the external SMTP server or the SMTP relay.
  3. Set the username and password.
  4. Set the port to 587 (or as specified below).

SMTP Ports

  • For an unencrypted or a TLS connection, use port 25, 2525 or 587.
  • For a SSL connection, use port 465
  • Check your firewall and network to ensure they’re not blocking any of our SMTP Endpoints.
SendPost supports STARTTLS for establishing a TLS-encrypted connection. STARTTLS is a means of upgrading an unencrypted connection to an encrypted connection. There are versions of STARTTLS for a variety of protocols; the SMTP version is defined in RFC 3207. To set up a STARTTLS connection, the SMTP client connects to the SendPost SMTP endpoint smtp.sendpost.io on port 25, 587, or 2525, issues an EHLO command, and waits for the server to announce that it supports the STARTTLS SMTP extension. The client then issues the STARTTLS command, initiating TLS negotiation. When negotiation is complete, the client issues an EHLO command over the new encrypted connection, and the SMTP session proceeds normally.
If you are unsure which port to use, a TLS connection on port 587 is typically recommended.

Sending email from your application

Many programming languages support sending email using SMTP. This capability might be built into the programming language itself, or it might be available as an add-on, plug-in, or library. You can take advantage of this capability by sending email through SendPost from within application programs that you write. We have provided examples in Python3, Golang, Java, PHP, JS.