Skip to content
Upstream Data API

The developer surface for the Upstream Data network.

Query payer requirements, benchmark behavior against the network, and score submission risk from the same non-PHI layer that sharpens the care intelligence platform.

Get a keyAbout 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

Three endpoints, one payer-behavior model.

  • GET/data/v1/requirements

    What a payer checks for a given procedure: coverage state, prior-authorization need, clinical criteria, step-therapy proof, and documentation, with the source policy.

  • GET/data/v1/benchmark

    Your payer-and-procedure performance next to the anonymized network baseline, with sample sizes and the delta. Aggregates only, no patient anywhere.

  • POST/data/v1/denial-risk

    A calibrated submission-risk score for a submission, with the drivers behind it and an honest model status. Scoring on what payers do, from codes and rates only.

Start with a benchmark call.

Pass your key as a Bearer token. Start with the sandbox, then move to live with the same shapes. JSON in, JSON out.

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",
  "customer_denial_rate": 0.22,
  "customer_sample_size": 180,
  "network": {
    "payer": "Aetna",
    "cpt": "64483",
    "network_denial_rate": 0.16,
    "contributing_practices": 7,
    "sample_size": 2400
  },
  "delta_vs_network": 0.06,
  "sandbox": true
}

Start in sandbox. Move to live when ready.

sk_test

Sandbox key, free

Build and test against representative data at no cost. Same shapes, same auth, no metering.

sk_live

Production key

Production access to customer-scoped results from the network. Move from sandbox when you are ready by swapping one key.

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 the exact request and response shapes with representative non-PHI data before you wire anything real.

Move with the same contract

Promotion to production is a key swap, not a new integration shape or a second API to learn.

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 the real request and response shapes for requirements, benchmark, and submission-risk endpoints against representative non-PHI data. The goal is to validate the integration contract before you swap in a production key.
What changes when I move from sandbox to production?
The contract stays the same. The move is a key swap and an access review, not a second API surface or a new response model.
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.

Build on the network.

Tell us what you are building. We will set you up with a sandbox key and the docs to move from exploration into production.

Get a keyAbout the data