Schema reporting protocol reference

This document specifies the protocol that any GraphQL server can implement to enable automatic schema registration with the Apollo schema registry.

For reference, Apollo Server uses this protocol in its schema reporting plugin (see the source).

The reportSchema mutation

A server that reports its schema to Apollo does so periodically via a GraphQL API hosted at the following endpoint:

1
https://schema-reporting.api.apollographql.com/api/graphql

Specifically, a server executes the reportSchema mutation, which has the following shape:

1
mutation ReportSchemaMutation($coreSchema: String, $report: SchemaReport!) {
2
  reportSchema(coreSchema: $coreSchema, report: $report) {
3
    inSeconds
4
    withCoreSchema
5
    ... on ReportSchemaError {
6
      code
7
      message
8
    }
9
  }
10
}

This mutation always requires a report input argument, which has the following minimum shape:

1
{
2
  "bootID": "abc123",
3
  "coreSchemaHash": "F908D0B24486E2B2A032ED019A657E7243BCDB7DC5D939AF69820FE7BADFB200",
4
  "graphRef": "docs-example-graph@production"
5
}

The details of this operation and its inputs are described below.

Required information

To successfully report a schema to Apollo, your server requires the following information:

Graph API key

All requests to Apollo's schema reporting endpoint require an X-API-Key header:

1
X-API-Key: service:docs-example-graph:abc123

The value of this header is a graph API key. Developers obtain this API key from Apollo Studio and provide it to their server instance on startup.

Graph ref

Whenever a server reports its schema, it does so to a particular graph and variant in Apollo Studio. Apollo uses strings called graph refs to describe particular graph-variant combinations:

1
my-graph-id@my-variant

A developer can obtain a variant's graph ref from the variant's Schema page in Apollo Studio.

As with API keys, we recommend that developers provide their graph ref to your server via an environment variable (e.g., APOLLO_GRAPH_REF) that's loaded on startup.

Boot ID

Whenever an instance of your server boots up, it should generate a UUID to identify itself among other instances of the same server. You provide this ID with each reportSchema mutation you execute, so that Apollo can distinguish between requests from different instances.

An instance's boot ID should not persist across restarts.

Schema hash

Every reportSchema mutation requires the SHA-256 hash of the schema string you're reporting to Apollo, as a hexadecimal string:

1
F908D0B24486E2B2A032ED019A657E7243BCDB7DC5D939AF69820FE7BADFB200

You should always normalize your schema before generating this hash, as explained below.

Protocol sequence

The following sections illustrate the communication sequence between a GraphQL server (hereafter referred to as the edge server) and the schema reporting endpoint (Apollo) after the server starts up. Each of these sections illustrates the same concepts in different formats.

Diagram

Step-by-step description

1. On startup, the edge server executes the reportSchema mutation, providing a SchemaReport object with the server's details as input.

   • See the SchemaReport object's fields, and its minimum shape.
   • In this initial call, set the coreSchema argument of reportSchema to null.
   • If this or any other reportSchema request fails with a non-2xx response, the edge server should retry after 20 seconds.

2. If the mutation succeeds, Apollo responds with a ReportSchemaResponse object. This response tells the edge server:

   • How many seconds to wait before sending the next reportSchema request (inSeconds)
   • Whether the next reportSchema request should include the coreSchema that corresponds to the coreSchemaHash provided in the previous request (withCoreSchema)

   If the mutation fails, Apollo responds with a ReportSchemaError object. In this case, the edge server should stop reporting its schema. This error should not cause the server to crash.

   • The message field of ReportSchemaError provides a human-readable message describing the error.
   • Correct the error and deploy a new version of your edge server to resume schema reporting.

3. Assuming success in step 2, the edge server waits the specified number of seconds, then executes the reportSchema mutation again.

   • This request includes a normalized coreSchema string if and only if withCoreSchema was true in Apollo's most recent ReportSchemaResponse.

4. Go to step 2.

Pseudocode example

1
val schema = normalize("type Query { .. }")
2
val report = SchemaReport(..)
3
val withSchema = false
4

5
function sendReport() {
6
  val coreSchema = withSchema ? schema : null
7
  val response = reportSchema(coreSchema, report)
8

9
  if (response.code) {
10
    throw exception
11
    return
12
  }
13

14
  withSchema = response.withExecutableSchema
15

16
  setTimeout(sendReport, response.inSeconds)
17
}
18

19
sendReport()

SchemaReport fields

These are the fields of the SchemaReport input type you provide as an argument to the reportSchema mutation.

Schema normalization

Two semantically identical schemas can appear different to the schema registry, such as when those schemas list the same set of object fields in a different order. To avoid this scenario, every edge server should normalize its schema before sending it to the registry.

To normalize your schema, do all of the following:

• Apply stable sorting (such as alphabetical) to the order of all type, field, and argument definitions.
• Remove all redundant whitespace.
• Remove all comments (but not docstrings).

Note that runtime dependencies on your schema document might result in poor user experience in tracking your schema changes, or even throttling of service availability.

Type definitions

The schema reporting protocol uses the following GraphQL types, referred to in Protocol sequence above:

1
type Mutation {
2
  reportSchema(coreSchema: String, report: SchemaReport!): ReportSchemaResult
3
}
4

5
# This type's fields are documented above.
6
input SchemaReport {
7
  bootId: String!
8
  coreSchemaHash: String!
9
  graphRef: String!
10
  libraryVersion: String
11
  platform: String
12
  runtimeVersion: String
13
  serverId: String
14
  userVersion: String
15
}
16

17
interface ReportSchemaResult {
18
  inSeconds: Int!
19
  withCoreSchema: Boolean!
20
}
21

22
type ReportSchemaResponse implements ReportSchemaResult {
23
  inSeconds: Int!
24
  withCoreSchema: Boolean!
25
}
26

27
type ReportSchemaError implements ReportSchemaResult {
28
  code: ReportSchemaErrorCode!
29
  inSeconds: Int!
30
  message: String!
31
  withCoreSchema: Boolean!
32
}
33

34
enum ReportSchemaErrorCode {
35
  BOOT_ID_IS_NOT_VALID_UUID
36
  BOOT_ID_IS_REQUIRED
37
  CORE_SCHEMA_HASH_IS_NOT_SCHEMA_SHA256
38
  CORE_SCHEMA_HASH_IS_REQUIRED
39
  CORE_SCHEMA_HASH_IS_TOO_LONG
40
  EXECUTABLE_SCHEMA_ID_IS_NOT_SCHEMA_SHA256
41
  EXECUTABLE_SCHEMA_ID_IS_REQUIRED
42
  EXECUTABLE_SCHEMA_ID_IS_TOO_LONG
43
  GRAPH_REF_INVALID_FORMAT
44
  GRAPH_REF_IS_REQUIRED
45
  GRAPH_VARIANT_DOES_NOT_MATCH_REGEX
46
  GRAPH_VARIANT_IS_REQUIRED
47
  LIBRARY_VERSION_IS_TOO_LONG
48
  PLATFORM_IS_TOO_LONG
49
  RUNTIME_VERSION_IS_TOO_LONG
50
  SCHEMA_IS_NOT_PARSABLE
51
  SCHEMA_IS_NOT_VALID
52
  SERVER_ID_IS_TOO_LONG
53
  USER_VERSION_IS_TOO_LONG
54
}