What supporting the GitHub API all day teaches you
Notes from GitHub API support: rate limits, pagination, webhooks, and the quiet art of reading someone else's request.
Update, 24 October 2026: My official title is Support Engineer. The two-person specialist arrangement described in the original version of this post has ended; REST and GraphQL API support remains part of my current role. The original publication date is retained.
My day job is Support Engineer at GitHub. A big chunk of it is the REST and GraphQL APIs. Supporting customer integrations teaches you things that are easy to miss when you only build your own tools.
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 often starts with: 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.