Location
A location returned by GET /v1/locations. This is the search entry point, not the final merchandising context.
Concepts
The object model behind search, offerings, scheduling, and results.
The public API is easiest to integrate when you treat location search, offering selection, identity, consent when required, direct ordering, questionnaire submission, and scheduling requests as connected steps.
catalog_id + offering_id
GET /v1/locations returns catalog_id and offering_id on each test. Use both in offering products and schedule paths.
test_id
The test id on the single-test product returned by offering products. Include it with catalog_id and offering_id on direct orders.
location id
The location id on GET /v1/locations. It is not required on offering routes or on the preferred direct-order payload.
customer_identity_id
Stable customer identifier returned in data.customer_identity_id by POST /v1/api-first/identities. Create it from your external_customer_id and reuse it across reusable consent, API Partner-provided consent PDF evidence, and orders.
consent_grant_id
Reusable consent grant for an API key provisioned with the Fitnescity Health consent API. Persist grant.id from consent finalization and send it where specified.
partner_consent_evidence_id
Accepted consent-evidence identifier for an API key provisioned for an API Partner-provided consent PDF. It replaces consent_grant_id on the applicable prescreen submission and order; send exactly one consent source.
API Partner-provided physician-order PDF
An independently provisioned mode in which the API Partner uploads appointment-scoped physician-order evidence after scheduling and waits for status=accepted. The Fitnescity Health physician-order service does not use these evidence endpoints.
pending_confirmation
Location request-then-confirm state after a Full API Integration schedule request. It is not a confirmed appointment and is independent of physician_order_status. Webhook appointment.requested maps to this location request.
alternate_test_partners
Fallback search suggestions returned when the requested DEXA search has no in-radius matches. These surface alternative test locations and body-composition modalities so the user does not hit a dead end.
Allowlisted results
Results payloads that are deliberately filtered to the public contract. API Partners receive only approved member, order, appointment, status, and result fields.
Why alternate test locations exist
Alternate test locations are a search fallback. When a DEXA search returns no in-radius matches, the API can suggest nearby locations for other body-composition tests such as SECA, BodPod, or Hydrostatic.
That gives API Partner teams a way to present a helpful alternative instead of an empty state.
API Partners do not need to show this block if it does not fit their UX. It is optional guidance data, not a required part of the ordering workflow.