Building a Complete Report

When an organization selects all three data scopes in your authorization — QR Score, Score Trend, and Pillar Breakdown — your credential can combine every endpoint into a complete resilience picture: the current score and grade, what’s driving it, and where it’s heading.

Note

Your access is limited to the scopes the organization selected when creating your authorization. If your integration only needs the headline score, request only that scope — the examples below assume all three were granted.

Pull everything

cURL

CLIENT_ID="osc_x7k2q9_9f8b7c6d5e4f3a2b1c0d9e8f7a6b5c4d"
BASE="https://api.overspace.io/orion/v1/customers/$CLIENT_ID"

curl "$BASE/score"           -H "x-api-key: $API_KEY"
curl "$BASE/pillars"         -H "x-api-key: $API_KEY"
curl "$BASE/trend?days=90"   -H "x-api-key: $API_KEY"

JavaScript

const CLIENT_ID = 'osc_x7k2q9_9f8b7c6d5e4f3a2b1c0d9e8f7a6b5c4d';
const BASE = `https://api.overspace.io/orion/v1/customers/${CLIENT_ID}`;
const headers = { 'x-api-key': process.env.API_KEY };

const [score, pillars, trend] = await Promise.all([
  fetch(`${BASE}/score`, { headers }).then((r) => r.json()),
  fetch(`${BASE}/pillars`, { headers }).then((r) => r.json()),
  fetch(`${BASE}/trend?days=90`, { headers }).then((r) => r.json()),
]);

Python

import os
import requests

CLIENT_ID = "osc_x7k2q9_9f8b7c6d5e4f3a2b1c0d9e8f7a6b5c4d"
BASE = f"https://api.overspace.io/orion/v1/customers/{CLIENT_ID}"
HEADERS = {"x-api-key": os.environ["API_KEY"]}

def get(path):
    response = requests.get(f"{BASE}{path}", headers=HEADERS, timeout=10)
    response.raise_for_status()
    return response.json()

score = get("/score")
pillars = get("/pillars")
trend = get("/trend?days=90")

Assemble the report

The three responses share the same clientId and scoreDate, so they compose directly into a single view:

{
  "clientId": "osc_x7k2q9_9f8b7c6d5e4f3a2b1c0d9e8f7a6b5c4d",
  "scoreDate": "2026-03-18",
  "score": 68,
  "grade": "Strengthen",
  "pillarScores": {
    "structuralIntegrity": 72,
    "failureResistance": 65,
    "deviceHealth": 58,
    "recoveryCapability": 75
  },
  "trend90d": {
    "change": 10,
    "series": [
      { "scoreDate": "2026-03-18", "score": 68 },
      { "scoreDate": "2026-03-17", "score": 67 },
      { "scoreDate": "2026-02-15", "score": 64 },
      { "scoreDate": "2025-12-19", "score": 58 }
    ]
  }
}

This composed view answers the three questions every audience asks:

Question	Source	Answer in this example
Where do they stand?	Get Score	68 — “Strengthen”: adequate, with specific areas needing attention
What’s driving it?	Get Pillars	Device Health (58) is the weakest pillar
Which way is it heading?	Get Trend	Up 10 points over 90 days — actively improving

Pattern: publishing a public trust page

The composed report above is exactly what powers a public trust page — Overspace’s own trust page runs this pattern in production. The key property: your credential never reaches the browser. A scheduled job holds the credential, composes the snapshot, and publishes a static JSON artifact that the page fetches.

1. Keep the credential server-side. Store the Client ID and API key in your scheduler’s secret store (CI environment secrets, cron worker config) or your enterprise secrets vault. The public page only ever fetches the composed output.
2. Refresh on a schedule. Scores are calculated daily, so a periodic pull (e.g., every 6 hours) keeps the published number continuously re-attested without meaningful lag.
3. Compose and validate before publishing. Pull /score, /pillars, and /trend, assemble the snapshot, and validate every field — a malformed artifact should fail the refresh, never reach the public page.
4. Strip the Client ID from anything world-readable. The snapshot is public; the credential identifiers that produced it are not.
5. Publish only on change. If the composed snapshot is identical to the last one, skip the publish — your artifact history then reads as a change log of the score itself.

{
  "score": 82,
  "grade": "Optimize",
  "scoreDate": "2026-08-11",
  "pillarScores": {
    "structuralIntegrity": 85,
    "failureResistance": 79,
    "deviceHealth": 81,
    "recoveryCapability": 83
  },
  "trend": [
    { "scoreDate": "2026-08-11", "score": 82 },
    { "scoreDate": "2026-08-10", "score": 82 },
    { "scoreDate": "2026-08-09", "score": 81 }
  ]
}

The same snapshot artifact serves every audience at once: the trust page renders it, the board deck cites it, and a counterparty can be issued their own credential to verify the number independently against the API.

Reading the combined picture

A single score snapshot can mislead in both directions — the combination is what makes the assessment defensible:

• A 68 trending up from 58 reflects an organization actively investing in resilience; a 68 trending down from 75 tells the opposite story, at the same score
• A composite of 68 with one weak pillar (Device Health at 58) points to a specific, addressable gap rather than systemic weakness
• Re-pulling daily and storing the series gives you your own audit trail of the organization’s posture over the life of the relationship