{"_id":"56ab8bbfd4432d1900eed1b1","parentDoc":null,"project":"568fce2a04440a1700e4cb47","user":"55116f88e2990b0d00fb0552","version":{"_id":"568fce2b04440a1700e4cb4a","project":"568fce2a04440a1700e4cb47","__v":20,"createdAt":"2016-01-08T14:56:43.101Z","releaseDate":"2016-01-08T14:56:43.101Z","categories":["568fce2b04440a1700e4cb4b","568fd1b8b700ce0d002f4b1c","568fd23804440a1700e4cb5b","568fd2444719c119002ce5d8","568ff21204440a1700e4cbc1","5693732c8aa8040d009f2c28","5693738393445b0d00abdad0","5693740093445b0d00abdad1","56937445974aaa0d001ca699","5693b82173f48f0d0075c90d","5694c4cd1005590d0062cb25","569f854466a5640d00efa54c","56a264cdd15dd70d008d825b","56aa56bf318e6c1700a19ddb","56b0e6347ae4550d000627bd","56b200c0f48f270d00e0de6f","56b200c6f48f270d00e0de70","56b22a9665ddf50d0076ba40","56e92ef71996862200fd7f42","574d6577fb835c0e00ca316a"],"is_deprecated":false,"is_hidden":false,"is_beta":false,"is_stable":true,"codename":"","version_clean":"1.0.0","version":"1.0"},"__v":8,"category":{"_id":"568fd23804440a1700e4cb5b","project":"568fce2a04440a1700e4cb47","__v":3,"pages":["569fb6a8b4f2d31900898ced","56ab2dc70b9e0b0d006161c4","56efbfcb20419a0e00113caa"],"version":"568fce2b04440a1700e4cb4a","sync":{"url":"","isSync":false},"reference":false,"createdAt":"2016-01-08T15:14:00.072Z","from_sync":false,"order":7,"slug":"soap-web-services","title":"SOAP API"},"updates":[],"next":{"pages":[],"description":""},"createdAt":"2016-01-29T15:56:47.596Z","link_external":false,"link_url":"","githubsync":"","sync_unique":"","hidden":false,"api":{"results":{"codes":[]},"settings":"","auth":"required","params":[],"url":""},"isReference":false,"order":6,"body":"[block:callout]\n{\n  \"type\": \"warning\",\n  \"body\": \"Polling APIs are restricted to authorised users only as of preferred method of sending data to customer in the [forwarding system](doc:receipt-forwarding), rather than polling for efficiency reasons. If you are interested in using this method please contact us to arrange access.\",\n  \"title\": \"Restricted Access\"\n}\n[/block]\nThe Dynmark Polling APIs allows integrators for whom HTTP forwarding is not suitable to poll the Dynmark Messaging Platform for receipts, inbound messages and tracked URL click details. Polling is not a real-time mechanism, so if responsiveness is required, you should use HTTP Forwarding instead.\n\n#Polling Frequency\nWe recommend a polling frequency of once every 5 minutes or more. To protect the Dynmark Cloud from overheads caused by polling, we limit checks for new items to once every 2 minutes. Clients that poll more frequently will not see new items arriving within this two minute interval and you will receive a **PollingFrequencyException**. If you require more responsiveness than this, you should consider using HTTP Forwarding instead which forwards items in near real time.\n\nIf your polling request returns a full batch however, we will allow an immediate polling call, so if you have a batch size of 50 and 120 items to download you can make three successive calls, so simply test the batch size and if it’s full re-poll until the returned batch is only partly fulfilled, then pause.\n\nIf you are using the batch reset key, we will keep a record of the number of calls made with that key during a specified time and if it exceeds a count of 10 we will not perform the polling action, you will receive a **PollingKeyException **in this case.\n\n##Batch Tracking\nIn normal operation, we track the outstanding items for you. We keep a record of the last returned item and use it as the start for the next batch selection.\n\nEach call to the polling APIs returns a batch of items, of size determined by you, and a string unique identifier that identifies the start point of this batch.\n\nIf you use this “batch reset key” it will return a batch with the same starting point as the batch relating to the key supplied, it may not be same batch as previously, since you can change the batch size (e.g. you could dynamically alter batch sizes down to more manageable chunks on error) or if it wasn't a full batch there may be more items that have arrived since the first call, which will be included. In the case of message receipts the message status will be updated 1 or more times so there is the possibility of a message Id moving from the front of the batch to the end with a new status.\n\nIt is important to note that use of this key will cause our internal tracking of your polling activity to be reset to the end point of the batch returned with the key use, hence once you have received the requested batch again, you will then receive any subsequent batches you may have polled since this batch, once you resume normal processing.\n\nYour system must be able to handle duplicate returns for this to be effective. In normal use we will not return duplicate entries, excepting receipts where the status of a particular message has changed, although the status will always move forward from a queued status, to an interim status, to a final status. Depending on your polling frequency it may be that only the final status will be polled.","excerpt":"","slug":"soap-polling-overview","type":"basic","title":"Polling APIs"}
[block:callout] { "type": "warning", "body": "Polling APIs are restricted to authorised users only as of preferred method of sending data to customer in the [forwarding system](doc:receipt-forwarding), rather than polling for efficiency reasons. If you are interested in using this method please contact us to arrange access.", "title": "Restricted Access" } [/block] The Dynmark Polling APIs allows integrators for whom HTTP forwarding is not suitable to poll the Dynmark Messaging Platform for receipts, inbound messages and tracked URL click details. Polling is not a real-time mechanism, so if responsiveness is required, you should use HTTP Forwarding instead. #Polling Frequency We recommend a polling frequency of once every 5 minutes or more. To protect the Dynmark Cloud from overheads caused by polling, we limit checks for new items to once every 2 minutes. Clients that poll more frequently will not see new items arriving within this two minute interval and you will receive a **PollingFrequencyException**. If you require more responsiveness than this, you should consider using HTTP Forwarding instead which forwards items in near real time. If your polling request returns a full batch however, we will allow an immediate polling call, so if you have a batch size of 50 and 120 items to download you can make three successive calls, so simply test the batch size and if it’s full re-poll until the returned batch is only partly fulfilled, then pause. If you are using the batch reset key, we will keep a record of the number of calls made with that key during a specified time and if it exceeds a count of 10 we will not perform the polling action, you will receive a **PollingKeyException **in this case. ##Batch Tracking In normal operation, we track the outstanding items for you. We keep a record of the last returned item and use it as the start for the next batch selection. Each call to the polling APIs returns a batch of items, of size determined by you, and a string unique identifier that identifies the start point of this batch. If you use this “batch reset key” it will return a batch with the same starting point as the batch relating to the key supplied, it may not be same batch as previously, since you can change the batch size (e.g. you could dynamically alter batch sizes down to more manageable chunks on error) or if it wasn't a full batch there may be more items that have arrived since the first call, which will be included. In the case of message receipts the message status will be updated 1 or more times so there is the possibility of a message Id moving from the front of the batch to the end with a new status. It is important to note that use of this key will cause our internal tracking of your polling activity to be reset to the end point of the batch returned with the key use, hence once you have received the requested batch again, you will then receive any subsequent batches you may have polled since this batch, once you resume normal processing. Your system must be able to handle duplicate returns for this to be effective. In normal use we will not return duplicate entries, excepting receipts where the status of a particular message has changed, although the status will always move forward from a queued status, to an interim status, to a final status. Depending on your polling frequency it may be that only the final status will be polled.