Web Service

Requirements

A Web Service enables machine-to-machine communication based on HTTP or HTTPS via computer networks such as the Internet. Data were exchange and functions call up on remote computers. Each web service has a Uniform Resource Identifier (URI) that uniquely identifies it, and an interface description in machine-readable format that defines how to interact with the web service. The communication with our service takes place via the HTTP (Port 80) /HTTPS (Port 443) protocol via JSON-based information messages.

Your Web service must be able to receive the JSON-based notification. Please note in your resource planning that a high volume of information will be send back to you.

Our system will provide you with at least three push notifications (reception / processing / delivery) for each message. This means that with a volume of 3,000,000 Emails you will receive at least a volume of 9,000,000 push notifications back. When using additional features such as open and link tracking, the factor increases accordingly.

Authentication (REST)

Instead of using the JobRequest Method to define the Web-Service endpoint, you may also setup a default configuration during the implementation phase. By doing so, there is no longer a need to specify the endpoint in each JobRequest. This configuration will then be setup at the L2-Account level (see chapter 2.1 “Service Administration Hierarchy”). You have the option to choose between two authentications options for your Web-Service: “Basic Authentication” or “OAuth 2.0”, as described below:

Basic authentication: simple and commonly used method for providing credentials (username and password) when making a request.
OAuth 2.0: "Open Authorization," is an open standard protocol that enables secure third-party access to an application's data without directly exposing credentials. However, if you opt for the OAuth 2.0 authentication method, you must provide the OAuth Server and run it on your side. In this case, Transactional Email is then considered the “Business Client”.

The OAuth 2.0 authentication method cannot be used within a JobRequest. If you defined a default OAuth 2.0 authentication at the L2-Account level but also choose to declare a Basic Authentication within a JobRequest, the Basic Authentication parameters will overwrite the OAuth ones

Authentication (SMTP)

Instead of using the SMTP-Header Method to define the Web-Service endpoint, you may also setup a default configuration during the implementation phase. By doing so, there is no longer a need to specify the endpoint in each STMP-Header request. This configuration will then be setup at the L2-Account level (see chapter 2.1, “Service Administration Hierarchy”). You have the option to choose between two authentication options for your Web-Service: “Basic Authentication” or “OAuth 2.0”, as described below:

Basic authentication: simple and commonly used method for providing credentials (username and password) when making a request.
OAuth 2.0: "Open Authorization," is an open standard protocol that enables secure third-party access to an application’s data without directly exposing credentials. However, if you opt for the OAuth 2.0 authentication method, you must provide the OAuth Server and run it on your side. In this case, Transactional Email is then considered the “Business Client”.

The OAuth 2.0 authentication method cannot be used within a SMTP-Header request. If you defined a default OAuth 2.0 authentication at the L2-Account level but also choose to declare a Basic Authentication within the SMTP-Header request, the Basic Authentication parameters will overwrite the OAuth ones.