GraphQL mutations

The checked sandbox schema exposes four mutation fields for each of its 162 FHIR and Ovok platform types: create, update, patch, and delete. Each field returns the affected type. These fields are schema capabilities, not authorization grants; the caller still needs project scope and corresponding resource permissions.

Operation	Example signature
Create	PatientCreate(res: PatientCreate!): Patient
Update	PatientUpdate(id: ID!, res: PatientCreate!): Patient
Patch	PatientPatch(id: ID!, patch: [PatchOperationInput!]!): Patient
Delete	PatientDelete(id: ID!): Patient

Replace Patient with the resource name for that type operation and input names. The resource catalogs list every mutation field. FHIR structure and REST interaction semantics remain documented in FHIR resources, FHIR basics, and Ovok primitives.

Create a resource

A create mutation accepts a resource-specific input through res. The inspected PatientCreate input follows the FHIR Patient shape and includes fields such as resourceType, identifier, name, telecom, gender, birthDate, and address.

mutation CreatePatient($resource: PatientCreate!) {
  PatientCreate(res: $resource) { id resourceType }
}

{
  "query": "mutation CreatePatient($resource: PatientCreate!) { PatientCreate(res: $resource) { id resourceType } }",
  "variables": {
    "resource": {
      "resourceType": "Patient",
      "name": [{ "family": "Example", "given": ["Alex"] }]
    }
  }
}

This synthetic request was not executed and is not a guarantee that every project accepts it. Validate the resource against the current schema and FHIR rules, use sandbox data, and request only needed fields in the mutation response.

Update, patch, and delete

Update takes the resource ID and the resource-specific ...Create input. Treat it as a full resource update and include fields required by that resource. For partial changes, the schema exposes PatchOperationInput with op: String!, path: String!, and value: String. Since value is a string in this schema, do not assume it has another server patch typing or behavior. Confirm a patch against the target sandbox; use the FHIR REST PATCH interaction when standard REST patch behavior is needed.

Delete takes the resource ID and returns that resource type. Project policy, references, or lifecycle rules may prevent deletion. Check the error response and the relevant FHIR resource page before building delete flows.

Mutation ordering and transactions

GraphQL mutations do not by themselves promise an all-or-nothing write across multiple FHIR resources. When a workflow needs an atomic multi-resource write, use the supported FHIR transaction bundle behavior in transaction bundles and the FHIR REST reference.

Authorization and errors

• Introspection succeeding does not mean the current token can execute a mutation.
• AccessPolicy and project scope still apply; GraphQL is not an authorization bypass.
• Inspect the GraphQL errors array as well as HTTP status.
• Never put client secrets or long-lived credentials in a GraphQL request, variables, source code, or logs.