API Surface

Overview

Stratum exposes a REST API for programmatic access to upload, analytics, and SQL query capabilities. The OpenAPI reference is at API Reference.

Authentication model

All authenticated API routes use:

Authorization: Bearer <token>

There are two practical token sources today:

interactive user sessions
service-account API keys created in the product UI

Service-account keys are still enforced as bearer-authenticated calls. The key determines what kind of token can be issued and what routes it can access.

Available endpoints

Upload — ingest STDF files
Ingest jobs — track file processing status
Lots — list and query uploaded lots
Analytics — wafer maps, test results, CPK, bin summaries
SQL — run queries against your data

API key scopes

Service accounts use scoped keys:

Scope	Access
`ingest`	Upload files, read job status
`read`	All GET endpoints
`full`	Upload, query, and SQL execution

Typical permission patterns:

Task	Scope needed
Upload STDF	`ingest` or `full`
Check job status	`ingest`, `read`, or `full`
Query analytics	`read` or `full`
Run SQL	`full`

Response contract today

Successful responses are JSON.

For alpha, many non-2xx responses still return plain-text bodies instead of structured JSON envelopes. That is current product reality, not a missing feature in the docs.

Plan around:

401, 403, 404, 409, and many 400 errors returning plain text
429 rate-limit responses returning plain text plus rate-limit headers

Analytics endpoints

Read-only query surfaces for lot data:

wafers and die maps
test results
CPK summaries
bin definitions
lot metadata

What-if scenario endpoints remain internal to the product UI.

Snapshots and analytics semantics

Most analytics routes accept snapshot_job_id.

Use it when you need a frozen analytical view instead of the lot’s current active ingest. This is the main reproducibility mechanism for external integrations.

Capability semantics today:

stacked lot Cp/Cpk use within-wafer sigma when available
stacked lot Pp/Ppk use overall lot sigma
single-wafer views often make capability and performance match because there is no subgroup drift left

If you are validating capability numbers against JMP or another external tool, prefer Exact raw in Analysis Defaults instead of summary-backed Auto.

SQL access

The SQL editor is backed by API endpoints for:

schema discovery
query execution
result pagination

Analysis context (selected lot, die subset, scenario limits) carries into SQL automatically.

Current SQL execution guardrails:

exactly one SELECT or EXPLAIN statement per request
read-only validation; mutating statements are rejected
filesystem, network, and export helpers are blocked
30s timeout
hard cap of 100,000 rows per request
default page size of 1,000 rows when limit is omitted

API keys

Keys are created and revoked through the product UI. They are not manageable via API.

Versioning expectations

The published OpenAPI is still an alpha contract.

That means:

the surface is good enough for pilots and lightweight internal integrations
snapshot-aware analytics and ingest routes are intentional and should remain
route names, loose metadata payloads, and some error formats are still subject to cleanup before a broader long-term compatibility promise

Current limits

No public SDK yet
Notebook collaboration and admin routes are still UI-only
Upload-size limits are deployment-defined today and are not yet a stable API contract
Best suited for data ingestion, analytics reads, and lightweight internal integrations

Rate limiting

Current route buckets are enforced server-side and surfaced through x-ratelimit-* headers:

analytics GET routes: 60/min
SQL query execution: 30/min
upload and upload inspect: 10/min

These limits are part of the current alpha deployment posture and may change before a broader public API commitment.