Fitnescity Health Developers
Public API documentation

Use Full API Integration—the default approach—to keep diagnostic testing search, customer identity, consent when required, ordering, questionnaires, scheduling, and results in your product. Start in Staging (Sandbox) for API Partner testing before switching hosts and credentials for live traffic.

Default test host
https://api-staging.engineeringfitnescity.com
Request access
Getting Started

How to request access, test in staging, and prepare for production.

Fitnescity Health uses a shared staging environment as the sandbox for API Partner testing. API Partners start there with a staging API key, then switch to the production host and production key when their implementation is approved for live traffic.

Environments

Use staging for implementation and API Partner testing. Switch the host and credentials only when you are ready to send live traffic.

Staging (Sandbox)

Default reference
https://api-staging.engineeringfitnescity.com

Use this shared non-production environment for implementation, QA, and API Partner testing before go-live.

Credentials

Use a staging-only API key. Staging keys do not work in production.

  • Shared environment used for API Partner testing and Fitnescity Health validation.
  • No production data should be used in staging.
  • Behavior matches the current v1 contract, but releases may arrive here before production.

Production

https://public-api.fitnescity.com/

Use this environment for live member traffic after your integration is ready to launch.

Credentials

Use a production API key issued separately from staging credentials.

  • Live environment for member traffic and results retrieval.
  • Switch to production only after validating your integration in staging.
  • Keep environment-specific secrets and API hosts separate in your deployment config.

Staging catalog data

Staging is shared and its records can change. Discover identifiers through GET /v1/locations instead of storing UUIDs copied from examples. A current catalog_id and offering_id pair returned by GET /v1/locations is expected to resolve through both products and schedule.

An empty available_dates array means a valid offering with no current availability. A 404 means the pair is not resolvable or is no longer accessible; a 503 is a transient calendar dependency failure.

For a maintained CALST certification fixture or another test-type fixture, contact support@fitnescity.com instead of relying on a temporary offering identifier.

Support-assisted lifecycle certification

After creating a staging appointment and webhook endpoint, ask support to exercise center confirmation, changed-time confirmation, and physician-order approval. Include the appointment ID, initial slot, replacement slot, and the webhook events you need to observe.

A center confirmation produces appointment.confirmed. A confirmed-to-confirmed time change produces appointment.rescheduled. Reconcile both with GET /v1/appointments.

Physician rejection is not currently an API Partner self-service staging action. Include that scenario in your support request if your certification requires rejection handling.

Confirm your provisioned modes and scopes

During onboarding, Fitnescity Health provides your initial configuration by provisioning customer consent and physician orders independently. Each environment's API key carries the scopes needed for those configured modes. Do not infer modes from a key name, its scopes, trial requests, or choose a mode per request.

As an optional check, call GET /v1/integration-configuration to confirm the current configuration at any time, including after requesting a change. The response identifies the environment and the provisioned customer-consent and physician-order modes for newly created workflows.

An API Partner-provided PDF branch also requires an active api-first-partner-evidence-v1 certification that matches every enabled branch and test type. Complete certification first, have Fitnescity Health issue a scoped key for the selected environment, and then activate the modes after the readiness checks pass. Activation fails closed when the certification or required key scopes do not match.

Fitnescity Health consent API
Complete the reusable consent bundle and session flow, then send consent_grant_id where specified.
API Partner-provided consent PDF
Use read:consent_evidence and write:consent_evidence to upload accepted evidence, then send partner_consent_evidence_id instead of consent_grant_id.
Fitnescity Health physician-order service
Do not upload physician-order evidence; monitor the appointment while Fitnescity Health completes it.
Structured physician-order API
Create and finalize the physician-order bundle and session, then poll for the generated artifact.
API Partner-provided physician-order PDF
After scheduling, use read:physician_order_evidence and write:physician_order_evidence to upload and wait for accepted appointment-scoped evidence.

Continue with identity, the provisioned customer-consent branch, conditional Calcium Score prescreening, order, questionnaire, scheduling, and the provisioned physician-order branch in the complete Full API Integration guide.

Access and credentials

  1. Request access at support@fitnescity.com with your company name, technical contact, and the tests or integration surfaces you plan to launch first.
  2. Fitnescity Health issues a staging key first and delivers it through a one-time reveal link. Production credentials are issued separately when you are ready to launch.
  3. Keep hosts and keys environment-specific. Do not reuse staging secrets in production config.
  4. Rotation and resend flows issue a fresh one-time reveal link. Store the secret in your own secret manager when you first open it because the raw key is not shown again later.
Quick start

Start with location search in staging. Once search, offering-product resolution, and schedule preview work in your UI, continue with Full API Integration: create the customer identity, establish the provisioned customer consent, complete Calcium Score prescreening when required, create the order, submit the appointment questionnaire, request scheduling, and establish the provisioned physician order.

curl -X GET "https://api-staging.engineeringfitnescity.com/v1/locations?lat=40.7128&lng=-74.0060&page=1&page_size=5" \
  -H "x-api-key: <staging-prefix>.<staging-secret>"

Recommended implementation order

  1. 1. Confirm the independently provisioned customer-consent and physician-order modes and their required API key scopes.
  2. 2. Implement GET /v1/locations with staging credentials.
  3. 3. Resolve the returned catalog_id and offering_id into offering product and schedule calls.
  4. 4. Create or reuse the customer identity with Full API Integration.
  5. 5. Complete the provisioned Fitnescity Health consent API or API Partner-provided consent PDF flow, then complete Calcium Score prescreening when is_prescreening_required=true. Keep pcp_consent independent of reusable consent.
  6. 6. Create the externally paid order with POST /v1/orders and persist its order and appointment identifiers.
  7. 7. Fetch and submit the appointment questionnaire, then call POST /v1/appointments/{appointmentId}/schedule with the selected and alternate availability.
  8. 8. Complete the provisioned Structured physician-order API or API Partner-provided physician-order PDF flow; otherwise monitor the Fitnescity Health physician-order service. Then track form availability and results through reads or webhooks.

Before you ship, review the dedicated Error Handling guide so your client logic treats 401, 403, 409, and 429 responses correctly.