Monitoring
Subscribe to a company and be told when its register entry changes.
A subscription ties your account to one company or person. When the register entry changes, the subscription raises an event.
This is the supported alternative to polling. Re-reading a company record on a schedule costs 10 credits a time and will usually tell you nothing changed.
Creating a monitor
curl -X POST "https://api.registercheck.de/v1/monitors" \
-H "Authorization: Bearer $REGISTERCHECK_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"company_id": "c359aa06-1ac0-4dab-9c60-d5c69a06ff2c",
"event_types": ["*"]
}'Only company_id is required. Leave event_types out and you get ["*"] — every type,
including ones added later. The monitor always belongs to the account that owns the API
key; there is no way to create one for another account.
Event types
Pass the changes you care about, or * for all of them.
| Value | Raised when |
|---|---|
company.name.changed | The registered name changes |
company.address.changed | The registered seat or address changes |
company.legal_form.changed | The legal form changes |
company.capital.changed | Registered capital changes |
company.officer.appointed | Anyone gains a role — a director, a board member, or a Prokurist |
company.officer.removed | Anyone loses one |
company.shareholder.added / .removed / .changed | A new shareholder list changes the cap table |
* | Any of the above, including types added later |
An authorised signatory is an officer here, as everywhere else in the API: subscribing to
company.officer.appointed covers both a board appointment and a grant of Prokura. You
do not need, and cannot ask for, a separate Prokura type.
`*` keeps working as the list grows
A monitor on * picks up event types added after you created it. A monitor listing types
explicitly does not — which is the point of listing them, but worth knowing if you meant
"tell me everything".
Sending a value outside this list returns 400 with a problem document naming the offending
value. Creating a monitor costs 10 credits; every other monitor operation is free.
Managing monitors
| Operation | Endpoint | Cost |
|---|---|---|
| List | GET /monitors | free |
| Read one | GET /monitors/{id} | free |
| Change types, or pause | PATCH /monitors/{id} | free |
| Delete | DELETE /monitors/{id} | free |
Only creating a monitor costs anything. Managing your own is free, so there is no reason to cache the list rather than reading it.
PATCH changes only what you send: {"status": "paused"} stops delivery without touching
the event types, and {"status": "active"} resumes it. A paused monitor keeps its
configuration and delivers nothing.
A monitor belonging to another account answers 404, not 403 — a 403 would confirm it
exists.
Receiving events
Events are delivered to a webhook endpoint configured in API management. Your endpoint should:
- Respond
2xxquickly and do the work afterwards. Slow handlers are retried. - Be idempotent. Assume every event may arrive more than once, and deduplicate on the
svix-idheader — there is no event id in the body. - Treat the payload as a signal, not as truth. Re-read the company to get the new state.
Webhooks has the exact payload, the signature headers and a verified handler.
Detection latency
Changes are detected by re-reading register entries on a cycle, not by a push from the courts. A change is typically visible within a day or two of appearing in the register, which is itself days or weeks after the underlying event. Monitoring is for keeping a portfolio current, not for real-time decisions.