What supporting the GitHub API all day teaches you
Notes from being one of two EMEA-timezone API specialists: rate limits, pagination, webhooks, and the quiet art of reading someone else's request.
My day job is Technical Support Engineer at GitHub. A big chunk of it is the REST and GraphQL APIs — I'm one of two engineers covering API issues in the EMEA timezone. You learn things supporting a platform used by 150 million developers that you don't learn building your own toys.
Most "bugs" are the contract working as designed
The single most common pattern: someone hits a wall, assumes it's broken, and it's actually the documented behaviour. Secondary rate limits. Pagination they're not following. A token without the scope they think it has. The skill isn't knowing the answer — it's reading their request carefully enough to see the gap between what they meant and what they sent.
Rate limits are a conversation, not a wall
People treat 403 and 429 as the platform being hostile. They're really the platform telling you how to behave: back off, respect Retry-After, paginate, use conditional requests so unchanged data is free. Once you frame limits as a protocol rather than an obstacle, integrations get calmer and faster.
Webhooks fail in boring, findable ways
Delivery debugging is 90% of webhook support and it's almost always one of: the endpoint isn't reachable, the signature check is wrong, or the handler is too slow and the delivery times out. The fix is observability — look at the actual delivery, the response code, the timing — not guesswork.
The transferable bit
Reading telemetry to find the real story (Datadog, Splunk, a KQL query) is the same muscle whether I'm resolving a customer ticket or chasing a p99 in order flow imbalance on one of my own systems. Support made me a better builder, and building made me a better support engineer. Funny how that works.