What can I test with a sandbox key?

You can test all four request and response contracts against synthetic non-PHI data, including provenance, unknown, null, and withholding states. Sandbox values are not observed payer results.

What changes when I move from sandbox to production?

The schema stays the same, but the data status and scope change. Live access requires review, returns customer-scoped results, and can withhold network aggregates when fewer than three practices contribute.

Can I send patient data to this API?

This surface is built so you do not need to. It is intentionally limited to policy, anonymized aggregates, and scoring inputs that stay on the non-PHI side of the boundary.

Who is this API meant for?

It is meant for builders who need payer requirements, benchmarks, and submission-pattern signals inside revenue-cycle, workflow, or analytics products without standing up their own payer-behavior network first.

Upstream Data API

The developer surface for the Upstream Data network.

Evaluate four non-PHI contracts for requirements, benchmarks, submission-risk signals, and prior-auth readiness. Sandbox data is synthetic; live access is scoped and evidence can be withheld.

Request a sandbox key About the data

What can you build on this surface?

Products that need payer requirements, anonymized benchmarks, and submission-pattern scoring without pulling protected health information across the boundary. The API is the clean external edge of the same network that sharpens the platform internally.

Endpoints

Four contracts, with status and limits in the response.

GET/data/v1/requirements
Available coverage and documentation requirements for a payer and procedure, with source provenance and an explicit unknown state when support is missing.
GET/data/v1/benchmark
A customer-scoped payer-and-procedure benchmark with sample sizes. The network result is withheld when fewer than three practices contribute.
POST/data/v1/denial-risk
A submission-risk signal with drivers and model status. The current response is labeled heuristic until a model clears its production promotion gates.
GET/data/v1/prior-auth-readiness
The available prior-auth readiness posture for a payer and procedure, including source, requirements, unknowns, and the next safe action.

Start with a benchmark call.

Pass your key as a Bearer token. The sandbox response identifies itself as synthetic and exercises the same null and withholding states consumers must handle in live use.

benchmark request

curl https://api.upstream.cx/data/v1/benchmark \
  -H "Authorization: Bearer sk_test_your_key" \
  -G \
  --data-urlencode "payer=Aetna" \
  --data-urlencode "cpt=64483"

{
  "payer": "Aetna",
  "cpt": "64483",
  "sandbox": true,
  "data_status": "synthetic",
  "customer": null,
  "network": null,
  "withheld_reason": "synthetic_sandbox"
}

Start in sandbox. Move to live when ready.

sk_test

Sandbox key, free

Validate the published schemas and failure states against synthetic data. A sandbox response is never presented as observed payer behavior.

sk_live

Production key

Customer-scoped access after review. Network results can remain null or withheld when the contribution threshold is not met.

Keep keys server-side. The API returns coverage policy, anonymized aggregates, and scores only. It is built so no protected health information crosses this surface.

Authenticate every request with an Authorization Bearer header.

Start in sandbox

Test all four request and response contracts with synthetic non-PHI data before requesting live access.

Move with the same contract

The schema remains stable, while live access adds customer scope, source provenance, and contribution-gated network results.

Keep PHI on your side

This surface stays focused on policy, anonymized aggregates, and scoring so your architecture stays cleaner by default.

Developer questions, answered plainly.

What can I test with a sandbox key?: You can test all four request and response contracts against synthetic non-PHI data, including provenance, unknown, null, and withholding states. Sandbox values are not observed payer results.
What changes when I move from sandbox to production?: The schema stays the same, but the data status and scope change. Live access requires review, returns customer-scoped results, and can withhold network aggregates when fewer than three practices contribute.
Can I send patient data to this API?: This surface is built so you do not need to. It is intentionally limited to policy, anonymized aggregates, and scoring inputs that stay on the non-PHI side of the boundary.
Who is this API meant for?: It is meant for builders who need payer requirements, benchmarks, and submission-pattern signals inside revenue-cycle, workflow, or analytics products without standing up their own payer-behavior network first.

Test the contract before requesting live data.

Tell us what you are building. We will review the use case and issue a sandbox key for synthetic contract evaluation.

Request a sandbox key About the data