📘 BACKCLICK Doku
Anmelden

Set Double-Opt-In Retroactively

✎ Bearbeiten + Unterseite Historie (0)
⋯
Erstellt von Confluence-Import am · zuletzt geÀndert von Confluence-Import am · v1

Description

This feature offers the possibility to set a Double-Opt-In retroactively. A mechanism can be implemented that collects all data necessary for Single-Opt-Ins from the past this way. This data can be stored for the subscriber. This feature allows up to 100 DOI changes/creations per request. The request object contains an array called “doiRequestItems” for this purpose. This array can hold up to 100 request items per request. The response object will return as many response items as request items were provided.

In order to generate DOI-Confirm-E-Mails EVERY mandator that is supposed to modify subscriber DOIs has to provide a “Subscription (Double-Opt-In)” web interface template. It is possible to use any existing template of this type that defines a <!--CONFIRM-EMAIL-->
<!--/CONFIRM-EMAIL--> block, or - and this is the recommended way to go - create a new “Subscription (Double-Opt-In)” template that defines nothing but a <!--CONFIRM-EMAIL-->
<!--/CONFIRM-EMAIL--> block and DEACTIVATE this template to prevent invocation of this template by a URL call! The ID of the corresponding web interface template has to be specified in the parameter “webTemplateId” of each request item.

Note: In case the system should be overloaded an error “Too much unfinished tasks! Please try again later.” will be thrown and execution will be prevented! This should not happen when using synchronous SOAP requests (default). If a parallel implementation is used and this error occurs the requests should be bundled.

Available starting from Backclick-Version: 5.8.0

In order to set a Double-Opt-In retroactively you have to provide the following information:

  • Mandator ID
  • API-Key (optional authentication, if not provided the IP address will be used for authentication)
  • DOI-Request-Items, provided as an array
    • E-Mail address of the subscriber to be modified
    • Web interface template ID to be used for confirmation mails
    • Subscribers IP, used to verify confirmation
    • Information whether the DOI applies to all lists
    • Subscribers User-Agent (default clientUserAgent = ””) optional
    • Subscribers referrer (default: clientReferer = “”) optional
    • Additional source, for example to allocate to a certain promotion (default: permissionSource =””) optional
    • Mailing lists the request applies to, if it doesn’t apply to all lists

The response object is an array of the same size as the amount of subscribers in the request and contains the corresponding information about the response status. These are the response codes possible:

Response codeMeaning
0

Transaction finished successfully. Changes were logged and a DOI-Confirm-E-Mail was generated using the web interface template provided.

Note

A generated mail is NO guarantee for delivery. In case the recipient’s mailbox doesn’t exist anymore, the receiving server is unreachable or any other errors on the opposite side should occur, the E-Mail may not be delivered.

1A DOI was already logged for every list provided. No changes were logged.
2The E-Mail address provided could not be found. No changes were logged.
3The E-Mail address provided is an inactive subscriber (self triggered but unconfirmed DOI via a web interface DOI subscription template). No changes were logged.
4No mailing list IDs were provided or none of the ones provided could be assigned to the mandator provided. No changes were logged.
5No request items were defined. The doiRequestItems array was empty. No changes were logged.
6The web interface DOI template could not be found, is not a DOI template or does not define a <!--CONFIRM-EMAIL-->
<!--/CONFIRM-EMAIL--> block. No changes were logged.
7An error occurred while creating the DOI-Confirm-E-Mail. All changes were logged though.
-1An unhandled error occurred. In case the response code for all your requests should be -1 constantly, please contact Backclick-Support to search for hints for the reason for this error in the server logfiles!
Note

Due to the importance of being able to proof DOI’s check the return value of this feature IN ANY CASE and react accordingly in case of any errors!

The following error messages can occur in faulty requests:

  • Validation error => There is an error in your request, it does not meet the requirements. Details can be found in the error message.
  • Too much unfinished tasks! Please try again later => Too many parallel requests. Please try again later and bundle your requests if applicable.

Example

$client = new SoapClient($wsdlUrl);
$request = new StdClass();
$request->mandatorId = 1;
$request->doiRequestItems = array();
$requestItem = new StdClass();
$requestItem->subscriberEmail = "[email protected]";
$requestItem->webTemplateId = 2;
$requestItem->clientIp = "127.0.0.1";
$requestItem->validForAllLists = true;
array_push($request->doiRequestItems, $requestItem); 
try {
    $response = $client->modifyDoubleOptIn($request);
    var_dump($response);
} catch (Exception $e) {
    echo "\n" . $e->getMessage() . "\n";
    foreach ($e->detail->ValidationError as $ve) {
       echo $ve . "\n"; 
    } 
}
object(stdClass)#4 (1) {
  ["doiResponseItems"]=>
  object(stdClass)#5 (2) {
    ["subscriberEmail"]=>
    string(21) "[email protected]"
    ["result"]=>
    int(0)
  }
}

Source code

In order to test a working example you can download the source code.

Example for setting a Double-Opt-In retroactively

AnhÀnge (1)