> For the complete documentation index, see [llms.txt](https://docs.sharelogic.com/unifi/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.sharelogic.com/unifi/configure/polling/pollers.md).

# Pollers

In cases where it is not possible for a remote system to send us the data, we can make a scheduled request for it using Pollers. All Pollers belong to an integration. Although a Poller belongs to only one integration, an integration can have multiple Pollers.

A Poller is a configuration record which defines the frequency of polling and which logic to use (the logic itself is defined in the [*Poll Processor*](/unifi/configure/polling/poll-processors.md)). Each time it is run, it creates a corresponding [*Poll Request*](/unifi/operate/transport/poll-requests.md) record.

## Challenges

Depending on the use case, the use of a Poller to collect data from a remote system poses some development challenges which need to be considered. Namely, there is an additional responsibility and workload placed on the host system to store and check some returned data in order to evaluate what has changed.

For example, in order to decide whether the state has changed, or what comments have been added, or even which system has made the updates to the data (we don't want to pull back data we have changed), checks have to be built into the scripts. This is aided by holding a copy of the relevant returned data, using [*Data Stores*](/unifi/configure/administration/data-stores.md) (see the relevant page in the *Administration* section).

When to use Pollers?

The following are some scenarios where pollers may be used and why:

* [**Fetching attachments**](https://docs.sharelogic.com/unifi/configure/attachments/fetching-attachments): Many systems don't provide a mechanism to push attachments when added. In these cases a poller GET attachment message may be triggered when attachments are added or to check periodically.
* **Supporting data syncs**: Where data is maintained on one system and needs to be synced with another without sending events, a periodic sync may be used. These syncs often cannot filter for incremental changes, resulting in them taking a while to run; as such, they should be scheduled infrequently (e.g. daily or weekly).
* **Systems with incomplete outbound triggers**: Some systems don't send updates for events made by automations and rules, or ignore changes to some fields. To remedy this, polling can ensure these updates are still captured.
* **Avoiding unauthenticated webhooks**: Systems which don't support authentication for outbound webhooks may be better served by polling. This avoids opening an unprotected endpoint on the receiving system.
* **Keeping integration contained to one system**: Where development is limited to the Unifi side, polling allows a complete integration to be built, only using the target systems' out-of-the-box APIs.

## Debugging Pollers

The starting point for debugging pollers is the **Poll Requests** table (`x_snd_eb_poll_request`). Locate and open the relevant record; this will be done automatically in testing if Unifi's 'Execute Now' button is used. Review the following key fields:

* **Endpoint URL**
* **Request Payload**
* **Response Code**
* **Response Status**

These values are populated by the **Poll Processor**. If any are missing or incomplete, review the poll processor logic. More details on this may be found on the [Poll Processors](/unifi/configure/polling/poll-processors.md) page or in the [Pollers tutorial](/unifi/integration-guides/servicenow-table-api/incident-update-poller-guide/polling.md).

#### Response Codes

HTTP response codes indicate the outcome of the poll request:

* **2xx** – Success
* **4xx** – Client error
* **5xx** – Server error

Further details: [MDN HTTP status codes](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status#client_error_responses)

**Common 4xx Errors**

Here are some common errors you are likely to encounter when building pollers.

| Code | Meaning            | Action                                                |
| ---- | ------------------ | ----------------------------------------------------- |
| 400  | Bad request        | Check for malformed or misspelled URL/query           |
| 401  | Unauthorised       | Verify credentials on the integration connection      |
| 403  | Forbidden          | Confirm the user has sufficient permissions           |
| 404  | Not found          | Validate the endpoint URL                             |
| 405  | Method not allowed | Ensure the HTTP method is supported (GET, POST, etc.) |

If a request returns **200 but the outcome is incorrect**, the issue likely occurs during response processing or downstream logic rather than the API call itself. This may be debugged in Activity logs.

#### Activity Logs

[Activity logs](/unifi/configure/administration/activity-logs.md) provide detailed execution tracing within Unifi.

Pollers typically generate two key logs:

* **Execute Poller - Portal**\
  Covers poller execution up to the outbound request, including setup and request scripts. Errors here usually indicate script issues (e.g. `ReferenceError`).
* **Poll Request execute**\
  Covers response handling and downstream processing, including inbound messages. Errors here typically occur after a successful request, during response handling or triggered logic.

For complex issues, add targeted `console` logging within scripts—these entries are captured in activity logs and can significantly improve traceability.