What causes "Network response was not ok" in payloadcms/payload?

Verify the `uri` is reachable from the server (curl it) and returns 2xx with valid JSON.

payloadcms/payload · error · Error

Network response was not ok

Error message

Network response was not ok

What it means

The JSON field's validator fetches a remote JSON Schema (via the field's `jsonSchema.uri`) and the HTTP response status was not ok (`!response.ok`, i.e. non-2xx). The fetch runs as part of validating submitted JSON against the schema, so a transport/HTTP failure surfaces as this generic `Error`.

Source

Thrown at packages/payload/src/fields/validations.ts:350

    if (Array.isArray(value) && value.length === 0) {
      return false
    }

    if (typeof value === 'object' && Object.keys(value).length === 0) {
      return false
    }

    return true
  }

  const fetchSchema = ({ schema, uri }: { schema: JSONSchema4; uri: string }) => {
    if (uri && schema) {
      return schema
    }
    return fetch(uri)
      .then((response) => {
        if (!response.ok) {
          throw new Error('Network response was not ok')
        }
        return response.json()
      })
      .then((_json) => {
        const json = _json as {
          id: string
        }
        const jsonSchemaSanitizations = {
          id: undefined,
          $id: json.id,
          $schema: 'http://json-schema.org/draft-07/schema#',
        }

        return Object.assign(json, jsonSchemaSanitizations)
      })
  }

  if (required && !value) {

View on GitHub (pinned to 00c58b35c0)

Solutions

Verify the `uri` is reachable from the server (curl it) and returns 2xx with valid JSON.
Inline the schema using `jsonSchema: { schema: {...} }` to remove the network dependency.
Host the schema on a stable, same-origin endpoint and ensure it allows the relevant origin/headers.
Catch fetch failures and provide a fallback, or skip remote schema validation in low-trust environments.

Example fix

// before
{ name: 'config', type: 'json', jsonSchema: { uri: 'https://old.example.com/schema.json' } }
// after (inline schema, no network)
{ name: 'config', type: 'json', jsonSchema: { schema: myJsonSchemaObject } }

Defensive patterns

Strategy: retry

Validate before calling

// before persisting, confirm the remote schema is reachable and 2xx
async function schemaUriOk(uri) {
  try {
    const res = await fetch(uri, { method: 'GET' })
    return res.ok
  } catch { return false }
}
if (!await schemaUriOk(field.jsonSchema.uri)) {
  // fall back to inline schema or skip remote validation
}

Type guard

function isJsonFieldWithRemoteSchema(f: any): f is { type: 'json'; jsonSchema: { uri: string } } {
  return f?.type === 'json' && typeof f?.jsonSchema?.uri === 'string' && !f.jsonSchema.schema
}

Try / catch

// the validator is internal; wrap the create/update call
try {
  await payload.create({ collection: 'things', data })
} catch (err) {
  if (/Network response was not ok/i.test(err?.message ?? '')) {
    // likely the json schema fetch failed; retry with backoff or fall back to inline schema
  } else throw err
}

Prevention

Prefer inline `jsonSchema: { schema: {...} }` over remote `uri` to remove network dependency.
Host schemas on a stable same-origin endpoint with monitoring.
Ensure the runtime (node/edge) permits outbound requests to the schema host.

When it happens

Trigger: A `json` field configured with `{ jsonSchema: { uri: 'https://example.com/schema.json' } }` where the URL returns 404, 500, requires auth, or is unreachable; the host is down; CORS blocks the request from the browser/runtime.

Common situations: External schema URL moved or changed scheme; firewall/proxy blocking outbound requests in the deployment environment; schema endpoint temporarily 5xx; running validations in a sandboxed/edge runtime without network access.

Related errors

AI-assisted analysis of payloadcms/payload@00c58b35c0 (2026-08-12). Data as JSON: /api/errors/4e3cdf5402c96ab3. Report an issue: GitHub.