A successful HTTP response confirms that Insider One received your request. It does not always confirm that the email was sent or that the content was saved as you expect. Test each Email API with one email, campaign, or template first.
The Transactional Email API has no sandbox, so every 202 sends a real email. Send your first test to an address you own. On V2, you can run POST /mail/v2/validate first. It checks the request without sending it. Give test campaigns and templates a clear name, so you can find and delete them later.
Check the result in the InOne panel
Save the message_id, the campaign id, or the template ID from the response.
Open the page that matches your API:
API | What to check |
|---|---|
Go to Reports > Email Analytics > Transactional Email Analytics, select the date range, and check Sent, Delivered, and Bounce Rate. If the email does not arrive, check Bounce Rate, Spam Reports, Invalid Emails, and Blocks in the same report: an address that bounced or reported spam on an earlier transactional email can be dropped. Also check the spam folder of your test inbox. | |
Open the Email Campaigns page and find the campaign by name. The status is Draft, and the campaign has the email-content-api tag. Open it and check the subject, preheader, HTML, and UTM parameters. The sender and reply-to address are your default sender, which the API cannot change. The API does not save the content as a template. | |
Go to Email > Templates and find the template by name. Select Promotional or Transactional to match is_transactional. A template created with is_architect_template: true is not listed here. Call the get endpoint with its ID to confirm it was saved. Check the HTML and the categories. |
If nothing appears, wait a few minutes and check again.
Compare the values in the panel with your request.
Transactional emails are not filtered by Global Unsubscribe or unsubscribe groups: a recipient on those lists still receives transactional email.
V2 only: call GET /mail/v2/messages/{message_id} with the message_id from the 202 response. It returns pending, partial, sent, or dropped for each recipient. sent means Insider One handed the email to the email provider, not that it reached the inbox. Status is kept for 2 days. After that, or for an unknown ID, the endpoint returns 404. V1 has no status endpoint: use Transactional Email Analytics. A V1 message_id does not work with the V2 endpoint.
Read the response
A 202 means the whole request passed validation and was queued. It does not mean every recipient was sent: recipients can be dropped later, for example, a uuid with no email address. On V2, check per-recipient results with GET /mail/v2/messages/{message_id}. The Content API and the Content Manager API return one result for the whole request.
Response | Meaning | What to do |
|---|---|---|
Transactional 202 | Insider One accepted the whole request and queued it. A recipient can still be dropped later. | Verify the send in Transactional Email Analytics. |
Transactional V2 409 or V1 208 | Insider One received a byte-identical request body in the last 15 minutes. The response includes the message_id of the original. A change in whitespace or field order counts as a new request. | Do not resend. |
Transactional 400 | The request failed validation. One invalid recipient rejects the whole request. | Read the error message, fix the request, and resend. On V1, an unchanged invalid payload resent within 15 minutes returns 208 instead of the original 400, so change the body when you test. |
Content API 201 with id | Insider One created a Draft campaign. | Open the campaign in the panel, then schedule it there. |
Content API 400 | The request failed validation, e.g., the wrong number of variations for the campaign type (experiment needs exactly 2; single and recurring need exactly 1), a type value that is not exactly single, experiment, or recurring in lowercase, a campaign name that already exists, or a missing Content-Type: application/json header. | Read the error message, fix the request, and resend. |
Content API 500 | The body could not be parsed, for example, broken JSON or a wrong data type. | Check the JSON syntax and the data types. |
Content API 413 | The body is larger than 2 MB. | Reduce the size. The HTML must be base64 encoded. |
Content Manager API 200 | The call succeeded. Content Manager returns 200 for every successful operation. | Verify the result in the panel or with the GET endpoint. |
Content Manager API 400 | Both is_transactional and is_architect_template are true, or a template with the same name exists (create, update, and duplicate). The body says Downstream request rejected, so the reason is not in the body. | Set at most one of the two flags to true. Both can be false for a promotional template. Check for a template with the same name. |
Content Manager API 404 | The template does not exist (get, update, duplicate). | Check the ID or search the templates first. |
401 or 403 | The API key is missing or not valid, or the key has an IP restriction and your IP i’t on the list. | Check the key and the X-INS-AUTH-KEY header. The Content API and the Content Manager API both use the Email Content and Templates key. The Transactional Email API uses its own key. |
429 | You reached the rate limit. | Wait, then retry. The Content API allows about 60 requests per 60 seconds for each key. The Content Manager API allows about 3 requests per second. |
A category ID that does not exist does not return an error: the template is saved without that category, so compare the categories in the panel. Deleting a template ID that does not exist returns 200.
The Content Manager API normally returns success or an error, but if a create returns 200 with id 0 or a message other than Template created, the template was not saved correctly: do not store the ID, and check the template in the panel before you retry.
If a transactional request failed with 502, retry it. On V2, the retry returns 202 (the first attempt was not queued) or 409 (it was). On V1, the retry returns 202 or 208; a 208 on V1 does not confirm that the email was queued, so check Transactional Email Analytics, and if the email is missing after 15 minutes, send again.
On V2, a request accepts up to 100 recipients, and you cannot use content and template_id together. The V1 response, which includes status_message, is supported until August 2027.
Reproduce a failure in Postman
Open the endpoint page and select Run in Postman. The Insider One Postman documentation opens at that endpoint.
In the top right corner of the Postman documentation, select Run in Postman.
In the Fork collection into your workspace window, select Fork Collection. Postman opens the collection in the Postman app or in your browser.
Select the environment and set the API key variable for your API, for example {{transactionalEmailApiKey}} for the Transactional Email API.
In the Body tab, select raw and paste the payload from your integration.
Select Send and compare the response with your integration log.
Remove personalization fields or variations one at a time until the response changes.
Remove the API key, recipient addresses, and email HTML before you share the request or response.
To trigger a known error on purpose, send a Content API request with the type experiment and only one variation. The API returns 400. To see a duplicate response, send the same transactional payload twice within 15 minutes. V2 returns 409, and V1 returns 208.
For more information, see Insider One APIs in Postman and API Status and Error Codes.