Skip to main content

Update an existing location record by ID

PUT 
/locations/:id

Updates the core location, group location, and tenant-group-location sub-records for the location identified by {id}, scoped to the tenant identified by the required tenant-id header.

When to use: Use when you need to update a single location's fields using its ID. To update address, network, and specialty sub-entities together in one batch call, use PUT /locations/update instead, which accepts locationId and tenantGroupLocationId and handles specialty management.

Preconditions: The tenant-id header is required. The {id} path parameter is the location's crosswalkId (unlike GET /locations/{id}, this endpoint does not fall back to a certifyLocationId lookup). The underlying write is an upsert: if {id} does not match an existing crosswalk, a new CoreLocation row is created rather than returning 404 — but the subsequent group-location lookup for that new record will then fail, surfacing as a 500 (see the 500 response below). Each of the three nested sub-documents (locationData, groupLocationData, tenantGroupLocationData) is independently validated against a JSON schema — validation failures return 400.

Idempotency: Submitting the same payload for the same {id} produces the same state. The three DAL writes are executed sequentially and are not wrapped in a single transaction; a 500 mid-sequence may leave partial updates committed. Inspect the error and verify record state before retrying.

Request​

Responses​

A LocationResponse object containing the updated location's id (= crosswalkId), crosswalkId, tenantId, billing/effective/termination dates, and a partial generalInfo (locationName, suppressSiteFromDirectory). Note: this is a sparser shape than GET /locations/{id} — entityAddressId and tenantGroupLocationId are not populated on this response.