We’re architecting a bidirectional sync between Zendesk Sell 2022 and our ERP system for account data. I’m evaluating two approaches and would love to hear real-world experiences from teams who’ve implemented either pattern.
Option A: Event-driven using Zendesk webhooks to push account changes immediately to our middleware, which then updates the ERP in near real-time.
Option B: Scheduled batch jobs that poll Zendesk API every 15 minutes, pull changed accounts, and sync to ERP in bulk.
Our main concerns are API rate limits (we have about 2000 active accounts with frequent updates), webhook reliability for critical business data, and overall system complexity. The event-driven approach feels more modern but introduces webhook endpoint hosting and monitoring overhead. Batch jobs are simpler but the 15-minute sync lag might be problematic for time-sensitive account updates. What have others found works best at scale?
We went with webhooks initially and regretted it. The problem isn’t Zendesk’s webhook reliability - that’s actually pretty solid. The issue is maintaining your own webhook endpoint infrastructure. You need proper queue management, retry logic, dead letter handling, and 24/7 monitoring. When our webhook endpoint went down for 2 hours during a deployment, we lost sync on 340 account updates. Zendesk retries for 24 hours, but we still had gaps. Switched to batch polling with 5-minute intervals and haven’t looked back.
You’re right about webhook payload limitations, but there’s a hybrid approach that works well. Use webhooks for event notification, but implement smart caching and batching on your middleware side. When a webhook arrives, queue it and wait 30 seconds to see if more webhooks for the same account arrive. Then make a single API call to fetch the complete account data. This gives you near real-time sync with minimal API consumption. We’re syncing 3500 accounts this way and average about 400 API calls per day for account sync operations. The 30-second micro-batch window reduces redundant API calls by about 60% compared to immediate webhook processing.
Having implemented both patterns across multiple Zendesk Sell deployments, I can offer some concrete guidance based on your specific requirements.
For API rate limit management with 2000 accounts and Zendesk Sell 2022, the event-driven approach is significantly more efficient. Here’s why: Zendesk’s rate limits are 100 requests per minute for Professional plans. Polling 2000 accounts every 15 minutes means you need to fetch account data in batches. Even with the bulk API endpoints that return 100 records per call, you’re making 20 API calls every 15 minutes, or about 2000 calls per day minimum. This doesn’t account for follow-up calls to fetch related data like contacts, deals, or custom fields.
With webhooks, you’re only making API calls for accounts that actually changed. In our experience with similar account volumes, typical daily change rates are 8-12% of total accounts. That’s 160-240 accounts changing per day, requiring maybe 250-300 API calls total including enrichment calls. You’re using 12-15% of your API quota versus 20% with polling, leaving headroom for other integrations.
Regarding webhook reliability, the concerns raised are valid but manageable. Modern webhook architectures should include:
-
Immediate acknowledgment: Your webhook endpoint returns 200 OK immediately and queues the payload for processing. This prevents Zendesk timeout issues.
-
Idempotency handling: Store webhook event IDs and deduplicate. Zendesk may send the same webhook multiple times if your endpoint is slow to respond.
-
Dead letter queue: Failed processing attempts go to a DLQ for manual review. We typically see 0.1-0.3% of webhooks end up here, usually due to data validation issues not webhook delivery failures.
-
Monitoring and alerting: Track webhook delivery latency, processing success rate, and queue depth. Alert if webhook endpoint hasn’t received events in 30+ minutes (could indicate Zendesk configuration issue or endpoint downtime).
For batch job scheduling, if you go this route, implement these patterns:
-
Delta queries: Use Zendesk’s updated_at filter to only fetch accounts modified since last successful sync. This dramatically reduces API calls.
-
Checkpoint persistence: Store the last successful sync timestamp in your database. If a batch job fails mid-execution, you can resume from the last checkpoint rather than starting over.
-
Rate limit backoff: Implement exponential backoff when hitting 429 rate limit responses. Zendesk provides Retry-After headers.
My recommendation for your scenario: Start with event-driven webhooks for account sync. The API efficiency gains are substantial, and with proper webhook endpoint architecture (serverless functions + message queue), operational overhead is minimal. Use batch jobs as a supplementary reconciliation process - run a full sync once daily during off-hours to catch any missed webhook events or resolve data inconsistencies. This hybrid approach gives you the best of both worlds: near real-time sync with event-driven updates plus a safety net of periodic full reconciliation.
One final note: Zendesk Sell 2022 introduced webhook event filtering that lets you specify which field changes trigger webhooks. Use this to reduce noise - for example, only trigger webhooks when critical account fields change (name, status, owner) rather than every field update. This can reduce webhook volume by 40-50% while still capturing business-critical changes.
Fair point about batch job complexity. We solved overlap issues with distributed locking using Redis. Each batch job acquires a lock before starting and releases it when complete. If a job is still running when the next interval triggers, the new job just skips and waits for the next cycle. The nice thing about polling is predictable load patterns - we know exactly when API calls happen and can plan capacity accordingly. With webhooks, you get traffic spikes when users make bulk changes in Zendesk, and your infrastructure needs to handle those peaks even if they’re rare.