Email Deployment Schedule

Summary

The Deployment Schedule API provides the ability to schedule a deployment for sending. Once scheduled, a deployment is queued to send and will send at the specified time. Before a deployment can be scheduled, the a test deployment must be sent using the Deployment Test. Once you schedule a deployment, you can unschedule the deployment at any time before the deployment is deployed to recipients. Accordingly, if you wish to change the scheduled date for a currently scheduled deployment, you will need to unschedule the deployment and then make another Deployment Schedule Api call with the new date you prefer.

The Deployment Schedule Api also does a series of validation steps on the deployment. This validation includes but is not limited to, ensuring that merge variables are properly formatted, that the audience list being used has fields that match merge variables in the deployment content, and that the message content is valid.

An HTTP POST request is used when scheduling a deployment to send.

Base Resource URI

For Production, use: https://ows.omeda.com/webservices/rest/brand/{brandAbbreviation}/omail/deployment/schedule/*

For Testing, use: https://ows.omedastaging.com/webservices/rest/brand/{brandAbbreviation}/omail/deployment/schedule/*

brandAbbreviationis the abbreviation for the brand to which the data is being posted.

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-typea 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

If omitted, the default content type is application/json.JSONapplication/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:POSTSee W3C’s POST specs for details.

POST method is used when assigning a list to a deployment split that does not have an existing list attached.

Field Definition

The following tables describe the hierarchical data elements.

List Elements

Attribute Name	Required?	Data Type	Description

Attribute Name	Required?	Data Type	Description
UserId	required	string	UserId of the omail account authorized to schedule this deployment. This must be the same account userId designated as either ‘OwnerUserId or ‘FinalApproverUserId’ during the Deployment Api call.
TrackId	required	string	TrackId is the unique identifier for the deployment.
ScheduledDate	required	date	ScheduledDate is the date and time (Central Daylight/Standard Time) that the deployment will start sending.Format: ‘yyyy-MM-dd HH:mm’, Ex. 2012-01-03 21:45 (January 3rd, 2012 at 9:45 PM). Time is Central Daylight/Standard Time. Alternatively, you may pass in ‘[NOW]’ in your API call, and the deployment will be scheduled for the time the API call is made.

POST JSON Request Example: When scheduling a deployment

{
    "UserId" : "omailAccount1",
    "TrackId": "FOO0102003002",
    "ScheduledDate": "2012-01-03 21:45"

}

POST JSON Request Example: When scheduling a deployment for immediate preparation and deployment

{
    "UserId" : "omailAccount1",
    "TrackId": "FOO0102003002",
    "ScheduledDate": "[NOW]"

}

Response Examples

Responses 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 submission will schedule the deployment for the specified date. A successful POST request will return a Url that can be used to retrieve deployment information such as link tracking, delivery statistics, deployment status, history, etc. (See Deployment Lookup Resource). A successful request will also return a unique submission Id that can be used as needed.

JSON Example

Failed Submission

Potential errors:

A failed request will return a unique submissionId that can be used as needed. A failed submission may be due to several factors:

Status	Description

Status	Description
400 Bad Request	Typically, this error occurs when the request does not follow the specifications.
403 Forbidden	Typically, this error occurs when the credentials are erroneous. Potentially, an incorrect x-omeda-appid or a UserId that is not authorized to edit the specified deployment.
404 Not Found	Typically, this error occurs with a malformed URL or the resource that is searched for is not found. This can occur if a TrackId submitted is not found in our system.
405 Method Not Allowed	Typically, this error occurs when the resource accessed is not allowed by the HTTP Method utilized. Make sure you employ the appropriate HTTP Method (POST) for this request.

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

JSON Example

JSON Example with missing merge variables

Table of Contents

1 Email Deployment Schedule
- 1.1 Summary
- 1.2 Base Resource URI
- 1.3 Technical Requirements
- 1.4 Supported Content Types
- 1.5 Supported HTTP Methods
- 1.6 Field Definition
- 1.7 Response Examples
  - 1.7.1 Successful Submission
    - 1.7.1.1 JSON Example
  - 1.7.2 Failed Submission
    - 1.7.2.1 JSON Example
    - 1.7.2.2 JSON Example with missing merge variables