poll_events
Retrieve mission events like claims, submissions, and messages to stay updated on progress without manually checking each mission.
Instructions
Poll for new events on your missions.
Returns events like mission_claimed, proof_submitted, mission.message.received, and others. Use this to stay informed about mission progress without repeatedly checking each mission individually.
Event types:
mission_claimed: A worker picked up your mission — it's starting
mission_started: Worker marked the mission as in progress
proof_submitted: Worker submitted proof — you should review it promptly
mission_completed: Mission was approved and finalized
mission_cancelled: Mission was cancelled
mission_expired: Deadline passed without completion
mission_dropped: Worker abandoned the mission — it returns to OPEN
mission.message.received: Worker sent you a message — check and respond
POLLING STRATEGY — You should set up regular polling to stay responsive:
During active missions (CLAIMED/IN_PROGRESS): poll frequently, ideally every 30-60 seconds. Workers may be on-site waiting for your response.
When all missions are OPEN or COMPLETED: poll less often (every 5-10 minutes).
Always store the timestamp of your last poll and pass it as the 'since' parameter to avoid processing duplicate events.
If you have configured a webhook for real-time event delivery, you should STILL poll periodically (every few minutes) as a fallback safeguard. Webhooks can miss events due to network issues, and polling ensures you never miss a proof_submitted or message event that needs your attention.
Args: since: ISO 8601 timestamp — only return events after this time limit: Max events to return (default 20, max 100)
Returns: JSON string with list of events. Each event includes event_type, task_id, and timestamp.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| since | No |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |