Skip to content

Guides

Support for an API or developer product

Developers want exact answers, working code and honest status. Support for an API is more about precision and reproducibility than about warmth, though a courteous reply still helps.

Last reviewed

Ask for the request and response

Ask for the request, the response and the timestamp up front. With those, most issues can be reproduced without a back and forth, and the right engineer can look at it.

Answer with working code

A short, correct code sample beats a paragraph of explanation. Test it before you send it, and link the reference page it comes from.

Keep a changelog and status page

Many questions come from a change or an outage. A visible changelog and an honest status page let developers answer themselves.

Offer a sandbox

A test environment lets developers try things without risk, and lets you reproduce their problem without touching real data. Mention it in your first reply when it fits.

Turn questions into docs

If several developers ask the same thing, the reference is missing something. Update the page and send them the link, so the next person finds it.

Escalate bugs cleanly

Pass engineers a short report with the request, the expected result and the actual result. Tell the developer what you found and when to expect news.

Questions

Who should answer API questions?

Someone who can read the code and the logs, or who can reach an engineer quickly. A generic first line often adds a day without helping.

Should I give priority to paying developers?

Many teams do. State it plainly in your support terms so free users know what to expect and paid users get the speed they bought.

How do I handle breaking changes?

Announce them early in the changelog and by email, give a clear date and keep the old version running for a stated period.

Written by Flatdesk, a help desk for small support teams at one flat price per agent. Try it free for 14 days, no card.