Metadata

Every object you create carries metadata: a map of your own string keys to string values. Put your CRM id on a monitor, your team's name on a notification endpoint, a deal stage on a collection entry — and read it back on every response for that object. Registercheck stores it and returns it; it never reads it or acts on it.

A webhook's alert names its monitor_id, not the monitor's metadata: keep your own map from monitor id to record (you get the id back when you create the monitor), or read the monitor.

It works exactly like Stripe's metadata, with the same limits:

Available on monitors, notification endpoints, collections and collection items.

Set it when you create

curl -X POST https://api.registercheck.de/v1/monitors \
  -H "Authorization: Bearer $RC_KEY" \
  -H "Content-Type: application/json" \
  -d '{"company_id": "3f1c2a9e-5b7d-4c8a-9e21-6d4f0b8a1c55",
       "metadata": {"crm_id": "0015g00000XyZ", "team": "kyc"}}'

Change it with PATCH

An update is merged into what is stored: a key with a string value is added or replaced, a key set to null is removed, and keys you do not name are left alone.

curl -X PATCH https://api.registercheck.de/v1/monitors/$MONITOR_ID \
  -H "Authorization: Bearer $RC_KEY" \
  -H "Content-Type: application/json" \
  -d '{"metadata": {"team": null, "region": "sued"}}'
# -> "metadata": {"crm_id": "0015g00000XyZ", "region": "sued"}

A request that would leave more than 50 keys, or break another limit, answers 400 and changes nothing.