Master Records Overview

Resolve vendor, customer and material rows from several systems of record into golden records with sourced values and merge reasons via /v1/master-records.

The Master Records app resolves the vendor, customer and material rows held in several systems of record, typically the ERPs of merged companies, into one golden record per real-world entity. Every golden value names the sources it came from. Every merge carries the field-by-field reasons it was made. A disagreement on a bank account or a tax id sends the record to review. A person's accept or split decision survives every re-run. The resolution is deterministic and calls no model.

These endpoints belong to the Master Records app (catalog slug master-records). A workspace uses them after adding the app; GET /v1/apps lists the workspace's apps by slug. There are three domains: vendors, customers and materials. A domain is configured with one or more sources; each source is a read-only SELECT on a SQL connection of the workspace that aliases its columns to the domain's canonical fields. The order of the sources is the survivorship priority: the first source wins a tie.

A run reads every source read-only, scores the rows of different sources against each other, links the pairs at or above the review threshold, and replaces the domain's stored records in one transaction. A record is auto when its weakest link is at or above the auto threshold and no field conflict is bad; it is review otherwise. A person's decision turns a record into accepted or split. Because decisions are keyed by the record's members, they apply again after every re-run, and a record whose membership changes gets a new key, so an old decision never applies to a different set of rows.

Authentication uses a tlnc_ API key or an OAuth token in the Authorization: Bearer header. Reads need the read scope. Running a domain and deciding on a record need the write scope and the key's person to be a member or above in the workspace. Saving the configuration needs the write scope and an owner (Admin) key person, because the configuration holds SQL that later runs against the workspace's database connections; a member's key is refused with 403 insufficient_role. The routes act on the workspace of the key.

Worked Example: Configure, Run, Review

An owner's key checks a configuration with dry_run, saves it, and runs the vendors domain. Any member's key can then read the overview and decide on records.

curl -X PUT "https://api.talonic.com/v1/master-records/config" \
  -H "Authorization: Bearer $TALONIC_OWNER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "dry_run": true,
    "config": {
      "domains": {
        "vendors": {
          "sources": [
            { "label": "ERP-A", "connection_id": "c2f4a6e8-1b3d-4f5a-8c7e-9d0b1a2c3e4f", "sql": "SELECT lifnr AS id, name1 AS name, stcd1 AS tax_id, land1 AS country, iban FROM vendors" }
          ]
        }
      }
    }
  }'

curl -X POST "https://api.talonic.com/v1/master-records/vendors/run" \
  -H "Authorization: Bearer $TALONIC_OWNER_API_KEY"

curl "https://api.talonic.com/v1/master-records/vendors/overview?status=review&limit=20" \
  -H "Authorization: Bearer $TALONIC_API_KEY"

curl -X POST "https://api.talonic.com/v1/master-records/vendors/records/3a7f9d1c5e2b8046a1d3c7f09b4e6a28d5c1f390/decision" \
  -H "Authorization: Bearer $TALONIC_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"decision": "accept"}'