Docs

Authentication

Every Labcorp API is reached through a single Labcorp API gateway. Your application authenticates to the gateway with the OAuth 2.0 Client Credentials flow, then sends the resulting access token as a Bearer credential on every request. The gateway holds the service-account credentials for the downstream APIs, so you never authenticate to an individual API directly — you only authenticate to the gateway.

Sequence

1. Get OAuth 2.0 credentials from Labcorp

Before your application can call the gateway, Labcorp must provision your account in our internal systems. You will be issued a Client ID and Client Secret that uniquely identify your application. To request credentials, use the Contact Sales button at the top of the page. New development requests must originate through Sales and receive divisional approval before Labcorp can begin provisioning, so plan for some lead time.

If you're already working with a Labcorp vendor analyst or project manager, send them your vendor name and a technical contact's name, phone number, and email address. Labcorp sends certification and production credentials separately, by secure email.

Treat the client secret like a password: store it in a secrets manager, rotate on a schedule, and never commit it to source control.

2. Exchange credentials for an access token

The token endpoint:

Only supports HTTPS
Only supports POST
Requires Content-Type: application/x-www-form-urlencoded
Supports the client_secret_post authentication method

Token endpoints by environment

Environment	Token endpoint
Production	`https://auth.aperture.labcorp.com/oauth2/token`
Certification	`https://auth-certification.dev.aperture.labcorp.com/oauth2/token`
Sandbox	`https://auth-stage.dev.aperture.labcorp.com/oauth2/token`

Form fields

Key	Value
`grant_type`	Must be `client_credentials`
`client_id`	Your Labcorp-issued client ID
`client_secret`	Your Labcorp-issued client secret

Example request

Code
curl --request POST \
  --url 'https://auth.aperture.labcorp.com/oauth2/token' \
  --header 'content-type: application/x-www-form-urlencoded' \
  --data grant_type=client_credentials \
  --data client_id=T6nvlXSLs0Og28P \
  --data client_secret=e5aU8OXju9O6ab1

Example response

Code
HTTP/1.1 200 OK
Content-Type: application/json

{
  "access_token": "efJz9sdf343dddd7f",
  "token_type": "Bearer",
  "expires_in": 3600
}

expires_in is in seconds. Tokens are valid for one hour. After expiration, the gateway will reject the request and you must request a new token.

Entitlements

Your credentials are provisioned with access to the specific APIs (products) your application is entitled to. You do not manage per-API scopes yourself; the gateway enforces your entitlements when it proxies your request to the downstream API. If you need access to an additional API, use Contact Sales.

3. Call an API through the gateway

Send the token in the Authorization header on every request to the gateway. Make sure your application targets the matching environment for the token (a sandbox token will not work against production). Reference the APIs page for the API's subdomain and path.

Code
curl --location 'https://<api subdomain>.aperture.labcorp.com/<path>' \
  --header 'Content-Type: application/json' \
  --header 'Authorization: Bearer efJz9sdf343dddd7f'

4. Verify gateway connectivity

Before integrating a specific API, confirm that authenticated communication with the gateway works by calling the gateway health-check endpoint with your token:

Code
curl --location 'https://gateway.aperture.labcorp.com/health' \
  --header 'Authorization: Bearer efJz9sdf343dddd7f'

A 200 OK confirms two things: your token is valid, and the gateway is reachable from your environment. This isolates connectivity and credential issues from any individual API integration. If you get a 401, re-check the token; if the request never reaches the gateway, check network egress and TLS.

Token lifecycle

Lifetime: 1 hour (expires_in: 3600)
Refresh: There is no refresh token in the Client Credentials flow. Request a new access token from the token endpoint when the current one is close to expiring
Caching: Cache the token in memory for the lifetime returned by the server (with a small safety margin, e.g., 60 seconds). Avoid requesting a new token on every API call
Reuse: A single token can be used for many requests until it expires

Common errors

Status	Meaning	Likely cause
`400 Bad Request`	Invalid token request	Missing `grant_type`, wrong content-type, malformed body
`401 Unauthorized` (token endpoint)	Invalid credentials	Wrong client ID/secret, or sending to the wrong environment
`401 Unauthorized` (gateway)	Token rejected	Token expired, wrong environment, missing `Bearer` prefix
`403 Forbidden`	Not entitled	Your application is not provisioned for that API; use Contact Sales

Operational checklist

Store credentials in a secrets manager, not in code or config files
Rotate the client secret on a schedule and after any suspected exposure
Use separate credentials per environment (sandbox, certification, or production)
Cache tokens; do not request a new one per request
Log token failures (status + correlation ID) but never log the token itself

Last modified on October 22, 2026

Getting Started