Rather than continuously poll for new data via the /keywords/check endpoint, we give you the option of supplying a Callback URI instead.
The callback URI needs to accept a simple POST request that will contain the following:
|The keyword_id of the check being reported. A keyword_id will only be supplied for a keyword in the daily queue.|
|The priority_id of the request being reported. A priority_id will only be supplied for a keyword in the priority queue.|
|The delayed_id of the request being reported. A delayed_id will only be supplied for a keyword in the delayed queue.|
|engine_code||string||The engine_code for the check being reported.|
|check_id||string||The check_id for the check being reported. This should be used in your subsequent call to the /keywords/serp endpoint.|
|timestamp||unix timestamp||The timestamp of the check being reported. This is the timestamp that the check actually took place, not the current request.|
Your callback URL must be able to handle very high-concurrency. Due to this, we strongly recommend that only simple logging is carried out within the request-handling process and all other logic is off-loaded to external workers or a queue for later processing.