Skip to main content

Letter — new field location (PracticeLocation)

Summary

The GraphQL type Letter now exposes a read-only field location of type PracticeLocation.

This resolves the room id stored on the letter (the same value you pass as location on createLetter and updateLetter) into structured location data: id, name, groupName, address, facility, and servicesProvided (when requested).

PracticeLocation.facility is also available on other types that expose PracticeLocation (for example Practice.locations, AvailabilitySettings.location, and online booking configuration). It is a nullable String that identifies a facility partner when the room is the practice's active OneWelbeck-synced room (practice.settings.oneWelbeck.active is true and syncedRoom matches the room id). For synced rooms the value is the stable identifier OneWelbeck; otherwise null.

Existing queries and mutations are unchanged. If you do not request location on letter or letters, behaviour and performance are the same as before.

Query example

query GetLetter($id: ID!) {
letter(id: $id) {
id
title
location {
id
name
groupName
facility
address {
address
city
postcode
}
}
}
}

The letters connection supports the same nested selection on each item in data.

Integration guidance

  • Optional field: Add location { ... } only when your integration needs clinic/room details; omit it otherwise.
  • Same type as elsewhere: PracticeLocation is shared with types such as Practice.locations, AvailabilitySettings.location, and online booking configuration—use the same client models where possible.
  • Stored id unchanged: Mutations still accept location as an ID (room id string). The new field is for reading resolved location data, not for changing how letters are created or updated.

If something breaks after this change

Problems are unlikely unless you use strict schema validation that rejects unknown fields on Letter. Refresh your schema snapshot, regenerate clients, and extend Letter types to include optional location.

See also