# Introduction > ### 📌 API versioning & the v1 response contract > > This reference documents the **v1 response contract** — the stable, camelCase > response shape that SendPost commits to. This is the shape you should build against. > > **During the current deprecation window**, requests authenticated with an account > or sub-account API key receive the **legacy** response shape by default, so existing > integrations keep working unchanged. To receive the documented v1 shape today, send: > > ``` > X-SendPost-Public-Contract: v1 > ``` > > **How to tell which shape you got.** Every public response echoes the applied > contract in the `X-SendPost-Public-Contract` response header. While the legacy > shape is being served, responses also carry standard deprecation signals: > `Deprecation: true`, a `Sunset` header with the exact cut-over date, and a > `Link: ; rel="deprecation"` header pointing at the migration guide. **Read the > `Sunset` header for the authoritative end date** rather than hardcoding one. > > **After the sunset date**, v1 becomes the default and the legacy shape is no longer > served. New integrations should send `X-SendPost-Public-Contract: v1` now and rely on > the shapes in this reference. SendPost provides email API and SMTP relay which can be used not just to send & measure but also alert & optimised email sending. You can use SendPost to: * Send personalised emails to multiple recipients using email API * Track opens and clicks * Analyse statistics around open, clicks, bounce, unsubscribe and spam At and advanced level you can use it to: * Manage multiple sub-accounts which may map to your promotional or transactional sending, multiple product lines or multiple customers * Classify your emails using groups for better analysis * Analyse and fix email sending at sub-account level, IP Pool level or group level * Have automated alerts to notify disruptions regarding email sending * Manage different dedicated IP Pools so to better control your email sending * Automatically know when IP or domain is blacklisted or sender score is down * Leverage pro deliverability tools to get significantly better email deliverability & inboxing [](https://god.gw.postman.com/run-collection/33476323-e6dbd27f-c4a7-4d49-bcac-94b0611b938b?action=collection%2Ffork&source=rip_markdown&collection-url=entityId%3D33476323-e6dbd27f-c4a7-4d49-bcac-94b0611b938b%26entityType%3Dcollection%26workspaceId%3D6b1e4f65-96a9-4136-9512-6266c852517e) # Overview ## REST API 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: https://api.sendpost.io/api/v1 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. 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. 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 eror with SendPost's servers ( internal service issue or maintenance ) 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](https://app.sendpost.io/register). 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 Code | Reason | Details ---------------| -----------------------| ----------- 200 | Success | Everything went well 401 | Unauthorized | Incorrect or missing API header either X-SubAccount-ApiKey or X-Account-ApiKey 403 | Forbidden | Typically sent when resource with same name or details already exist 406 | Missing resource id | Resource id specified is either missing or doesn't exist 422 | Unprocessable entity | Request body is not in proper format 500 | Internal server error | Some error happened at SendPost while processing API request 503 | Service Unavailable | SendPost is offline for maintenance. Please try again later # API SDKs We have native SendPost SDKs in the following programming languages. You can integrate with them or create your own SDK with our API specification. In case you need any assistance with respect to API then do reachout to our team from website chat or email us at **[email protected]** * [PHP](https://github.com/sendpost/sendpost_php_sdk) * [Javascript](https://github.com/sendpost/sendpost_javascript_sdk) * [Ruby](https://github.com/sendpost/sendpost_ruby_sdk) * [Python](https://github.com/sendpost/sendpost_python_sdk) * [Golang](https://github.com/sendpost/sendpost_go_sdk) # 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](https://www.ietf.org/rfc/rfc3207.txt). 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 ```javascript "use strict"; const nodemailer = require("nodemailer"); async function main() { // create reusable transporter object using the default SMTP transport let transporter = nodemailer.createTransport({ host: "smtp.sendpost.io", port: 587, secure: false, // true for 465, false for other ports auth: { user: "" , // generated ethereal user pass: "", // generated ethereal password }, requireTLS: true, debug: true, logger: true, }); // send mail with defined transport object try { let info = await transporter.sendMail({ from: '[email protected]', to: '[email protected]', subject: 'Test Email Subject', html: 'Hello Geeks!!!', }); console.log("Message sent: %s", info.messageId); } catch (e) { console.log(e) } } main().catch(console.error); ``` For PHP ```php

Go to Download