Receiving orders: polling or notifications

Choose one method: API notifications (recommended) or regular Partner API polling.

Method 1. API notifications

• Enable receiving POST notification. How notifications work: Guide
• Receive order events and immediately request details: GET v2/campaigns/{campaignId}/orders/{orderId}
• Notification types and data format: POST notification

Method 2. Regular API polling

• Request order lists:
  • GET v2/campaigns/{campaignId}/orders
  • POST v1/businesses/{businessId}/orders
• Use filters:
  • fromDate and toDate — delivery date range for new orders
  • updatedAtFrom and updatedAtTo — orders with changes
• Respect polling intervals:
  • Express — every 10–15 minutes
  • FBS, DBS — at least once per hour
• For each found order, fetch details: GET v2/campaigns/{campaignId}/orders/{orderId}

What to choose

• Prefer API notifications for real-time reaction. Ensure receiving POST notification, idempotent processing, storing event time (createdAt/updatedAt), and duplicate handling
• Add a fallback polling loop to cover notification outages and rare desyncs. Poll every 15–30 minutes and always after incidents on your side
• When polling, limit time windows (fromDate/toDate) and use updatedAtFrom/updatedAtTo for incremental reads. Respect rate limits and use exponential backoff on errors
• For high reliability, combine notifications + background polling. Persist a checkpoint (e.g., max updatedAt) and alert on delay/error growth