Skip to main content
GoldenMatch includes a local HTTP server for real-time matching, cluster browsing, and data steward review.

Start the server

The server loads data, runs initial matching, and exposes endpoints on the specified port.

Authentication and CORS

The server is fail-closed: binding to a non-loopback host refuses to start unless GOLDENMATCH_API_TOKEN is set. When the token is set, every endpoint except GET /health requires it as a bearer token.
Cross-origin requests are denied by default (no wildcard). To allow specific browser origins, set a comma-separated allowlist:
The default bind is 127.0.0.1, which runs token-free for local use.

Endpoints

Health check

Returns 503 with "status": "initializing" until the initial matching run has populated results — readiness, not just liveness.

Stats

Match a record

Batch match

Explain a match

Clusters

List all clusters

Get cluster detail

Review queue

The review queue surfaces borderline pairs for data steward approval or rejection.

Get pending reviews

Make a decision

Decision values: "approve" or "reject".

List completed decisions

Python client

GoldenMatch includes a REST client that uses only stdlib urllib (no extra dependencies):

AutoConfigController telemetry (v1.7-v1.12)

Two endpoints expose what the controller decides and why. Same JSON shape as the workbench GET /api/v1/controller/telemetry, the CLI goldenmatch autoconfig output, and the SQL goldenmatch_autoconfig_telemetry() function — write a parser once and reuse across surfaces.

POST /autoconfig

Runs auto_configure_df and returns the committed config + telemetry.

GET /controller/telemetry

Returns the cached telemetry from the most recent POST /autoconfig call without re-running the controller. Before any autoconfig call:

Docker deployment