Until recently, the trigger mechanism only supported notifications of newly received submissions, however, we have now implemented the ability to notify your custom application(s) when a submission is edited in your research console as well – thereby maintaining data integrity between our systems and yours.

In both cases we have also improved the processing mechanism in terms of dealing with failed delivery. The submission trigger mechanism will now reprocess a trigger in the event of a delivery failure (such as network failure or your server being offline). This ultimately means you are always ensured of receiving a notification of a submission even if your processing application is down while a submission is received. The new processing mechanism will make up to 6 attempts to notify your application as per the following schedule (assuming failure of the first and subsequent requests):

• Retry 1 minute after first failure
• Retry 5 minutes after second failure
• Retry 20 minutes after third failure
• Retry 1 hour after fourth failure
• Retry 4 hours after fifth failure

If the result of the 6^th attempt is a failure, we will notify you via email and wait on a resolution before re-processing the undelivered notification(s).

A successful notification delivery is defined as an attempt that results in a “200 OK” HTTP status code being returned by the relevant web server. If any other code is returned our system will deem the delivery a failure and enter the reprocessing workflow as described above. Furthermore, if a “500 Internal Server Error” code is returned we will record the error message returned and supply this information to you in the event the notification is not delivered after 6 successive attempts.

In terms of the requirements for setting up a create/update notification trigger, we simply require the URL endpoint of your service and the survey ID you wish to setup the trigger(s) for. Once setup, the notification to your URL endpoint is simply made via a GET request with the following query string parameters.

On submission created notification:

On submission modified notification:

If you have any comments, questions or suggestions, please feel free to post them here, alternatively, please contact support.

We hope you find these new features useful.

We recommend that you always access your console through this secure instance, and as such, have decided to implement a minor update which will ensure anyone connecting to the default address will be automatically redirected to the secure instance. This update will be in effect from 27 August 2009.

For those of you utilising the API service, this will impact your applications as the API will no longer be available from the default (HTTP) endpoint. The API is already available via HTTPS so the change is simply limited to updating your configuration to point to the HTTPS address.

We apologise for any inconvenience this may cause you but this change is in the interest of improved security. Please feel free to contact support should you have any queries or concerns.