Developer Center
Callbacks
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:
Callback parameters
| Name | Type | Description |
|---|---|---|
| keyword_id | string optional |
The keyword_id of the check being reported. A keyword_id will only be supplied for a keyword in the daily queue. |
| priority_id | string optional |
The priority_id of the request being reported. A priority_id will only be supplied for a keyword in the priority queue. |
| delayed_id | string optional |
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.
Note: we only ever try a callback once and with a very low timeout (5s). If the callback fails we will not notify you, however we can add additional logging to your account
to monitor callback status where issues are suspected. We recommend that you do not rely solely on callbacks and always make a backup call to /keywords/check when an expected callback does not arrive.