Jam Documentation
LoginTwitterHelp
  • Welcome to Jam
  • Get Started
  • Company
    • Mission and values
    • Security, privacy and compliance
  • Product Features
    • Instant Replay
      • Performance
      • Privacy
      • iFrame & canvas support
    • Video Screen Recording
      • Desktop Recording
      • Video blur
      • Video annotations
    • Screenshot
      • Full screen screenshot
      • Screenshot hover states
    • DevTools
      • Security
      • Network req/resp bodies
      • GraphQL
      • Jam.Metadata
    • Jam for Incognito
    • Mobile inspector
    • Keyboard shortcuts
    • Team Workspaces
      • Manage Seats in Jam
      • Workspace Discoverability
    • Security and compliance features
      • How to configure SSO for your organization
    • Jam for Customer Support
      • Getting started with Jam.js
    • Jam AI
      • AI policies
      • AI debugger
  • Integrations
    • Asana
    • ClickUp
    • Figma
    • GitHub
    • GitLab
    • Jira
    • Linear
    • Notion
    • Sentry
    • Slack
    • Azure DevOps
    • Fullstory
    • LogRocket
  • Downloads and Browsers
    • Browser support
  • Configuration
    • How to auto-deploy Jam organization wide
    • Configuring Jam for AI apps
    • How to run Jam only on some websites
    • How to ignore logs from Jam in the developer console
    • How to use Jam with local files
Powered by GitBook
On this page

Was this helpful?

  1. Product Features
  2. DevTools

GraphQL

PreviousNetwork req/resp bodiesNextJam.Metadata

Last updated 1 year ago

Was this helpful?

One major difference between GraphQL and REST APIs is how they handle errors. In a REST API, different HTTP status codes indicate the outcome of a request. For example, a 200 status code means the request was successful, while a 400 status code means there was a client error.

In contrast, GraphQL always returns a 200 status code, even if there are errors in the response body. The suggests that servers respond with a structured errors field. This makes errors machine-readable but drops the semantic meaning of HTTP status codes. Everyone knows what a 404 status code means but a GraphQL server will instead return a 200 with application-specific errors in the errors field in the response. This means that to effectively debug GraphQL, you typically have to comb through every single request to identify errors.

That's why we've built special error handling support for GraphQL.

We added extra logic to the dev tools section to mark GraphQL requests as errors even if they return an HTTP 200 code, if they have an errors object inside the response body.

GraphQL spec
Here's a Jam of Jam, the GraphQL requests are red for "error" even though they return 200.