Update an existing location record by 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.