Email Optin Queue

Summary

The OptIn Queue API allows our client to OptIn their subscribers or customers to their email deployments at the client, brand, and deployment type level. All 3 OptIn levels can be submitted in one OptIn Queue API call.

Base Resource URI

clientAbbreviation is the abbreviation for the client who is posting the data.

PLEASE NOTE: Unlike the majority of our APIs, the OptInFilterQueue takes in the CLIENT name, not a BRAND name. Please consult us to receive the proper client name.

Technical Requirements

The HTTP header must contain the following elements: x-omeda-appid a unique id provided to you by Omeda to access your data. The request will fail without a valid id. content-type a content type supported by this resource. See Supported Content Types for more details. If omitted, the default content type is application/json.

Supported Content Types

There are three content types supported. If omitted, the default content type is application/json. JSON application/json

JSON is the preferred data exchange format, because it is lightweight and, in most cases, faster to process and utilizes less bandwidth. There are many available open-source JSON libraries available. See json.org for details.

Supported HTTP Methods

There is one HTTP method supported: POST See W3C’s POST specs for details.

Field Definition

The following tables describe the data elements that can be included in the POST method to store data in the database.

OptIns Elements

DeploymentTypeOptIn Elements

Deployment Type-Level OptIn

A Deployment Type-level OptIn signifies that the email address(es) submitted will be Opted In to the active Deployment Types that is associated with the given x-omeda-appid. Example:

RESULT: A Deployment Type-level OptIn, in this case, will be done for the 2 Deployment Types.

RESULT: A Deployment Type-level OptIn, in this case, will generate an error because the Deployment Type 46 is not associated with a Brand that is associated with the x-omeda-appid.

Request Examples

In these examples, we’re submitting:

JSON Example

Response Examples

Two responses are possible: a successful POST (200 OK Status) or a failed POST (400 Bad Request/403 Forbidden/404 Not Found/405 Method Not Allowed Statuses). See W3C’s Status Codes.

Successful Submission

A successful POST submission may create OptIn entries. Messages may be returned in some cases.

JSON Example

If all OptIns have been processed Without any messages returned, you will get the following response:

If you submit a request Without “DeleteOptOut”:1, it may be possible that zero, one or more OptIns have not been processed. A “Message” element will describe the reason why the specific OptIn has not been processed. Please read the Additional Information section for more details. A typical response may be:

Failed Submission

A failed POST submission may be due to several factors:

This is not an exhaustive list of errors, but common ones. If an error occurs repeatedly, please contact your Omeda representative.

IMPORTANT: If an error occurs, NONE of the OptIns submitted will be processed. The errors array simply indicates the reason why the request was rejected. Fixing the errors in the error array and resubmitting the request should work, provided no new errors have been re-introduced. Please contact your Omeda representative if you need assistance.

JSON Example

DeploymentTypeOptIn

For each DeploymentTypeId submitted, our system verifies that it belongs to a BrandId, and that the BrandId is authorized to receive OptIns for the x-omeda-appid submitted. If this occurs, you would get the error message below.

Additional Information

DeleteOptOut Rules

By convention, we use “DeleteOptOut” to determine whether an ‘IN’ submission will override an existing ‘OUT’ submission.

Table of Contents