APIs and JSON for software support

APIs in customer-facing support

SaaS products talk to themselves and to other systems through APIs: billing providers, SSO, webhooks, partner integrations, and the browser’s own XHR/fetch calls. When a customer reports “Salesforce sync failed” or “the dashboard is empty,” the truth is often in an API response—not in the button label.

JSON as a support artefact

JSON is structured text: objects in curly braces, arrays in square brackets, keys with values. You do not need to write JSON to support a product. You do need to spot fields like error, message, code, or status and quote them accurately in the ticket.

{
  "error": "payment_method_required",
  "message": "Add a card before starting a trial."
}

That response is more useful to engineering than “upgrade button broken,” even if the UI only showed a generic toast.

What good API notes look like

• Endpoint and method (for example POST /v1/invoices)
• Status code and timestamp (with timezone if possible)
• Relevant IDs (org, user, invoice)—never paste secrets
• Sanitised error JSON or a redacted HAR

Common mistakes

• Pasting full tokens or Authorization headers into public tickets or Slack.
• Assuming the UI error string matches the API error—always check the Network response.
• Treating “API” as coding work; reading responses is a support skill.