Pollers

A Poller makes a scheduled request to a remote system.

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). Each time it is run, it creates a corresponding Poll Request 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 (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: 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 page or in the Pollers tutorial.

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

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 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.