1 min readintegrations · apis
Retiring a tag job cut our Zendesk API usage 60%
Replacing a four-hourly tag-sync job with real-time GraphQL data cut Zendesk API usage by 60%. Integration cost is usually a design problem, not a capacity problem.
By Asif Iqbal
On a marketplace serving millions of users, every support interaction that touches Zendesk can become an API call, and API usage becomes an infrastructure concern on its own.
At Upwork, Zendesk only knew who a user was from tags. A scheduled job worked out each user's account state, turned it into tags, and regenerated them for every user every four hours. Those tags reached Zendesk only when the user started an SSO session in the Help Center. So Zendesk always worked from a snapshot that could be hours old, live chats sometimes reached the wrong agent group, and the job itself made a large share of our Zendesk API calls.
As Engineering Lead I replaced the tags with real-time data: the Help Center read user data from Upwork's GraphQL API at request time, the incoming-ticket workflow was redesigned around that live data, and with nothing depending on it, the tag job was retired.
That cut Zendesk API usage by 60% and ended live-chat misrouting caused by stale tags. (Internal estimate.)
The lesson I took from it: integration cost is usually a design problem, not a capacity problem. Before asking for higher limits, look at which calls the system makes, why it makes them, and which ones a better design would never need. (Opinion.)