account/monitors

Creating a monitor and the first baseline are free. A cycle of 30 days is charged as soon as the monitor becomes active. The price depends on the check interval and covers all checks the interval schedules within one cycle.

An interval between two tiers costs as much as the next more frequent tier: every four days costs as much as every three days.

Extra checks happen mainly when you shorten the interval in the middle of a cycle. Each successful extra check costs the amount in the table.

After 30 days the cycle renews automatically at the price valid then. Failed checks cost nothing. When you pause, archive or change the interval, we refund nothing.

Each account can have up to 50 monitors at the same time, one per company. Within 24 hours you can create up to 50 monitors; archived ones count too.

You get the price of an interval for free with GET /v1/account/monitoring/pricing, here for a check every seven days:

1. Create. You name the company, the check interval and at least one verified webhook endpoint. The monitor starts with the status initializing.
2. Baseline. We record the signals of the last few days as known. They are not delivered, so you only get what is new after that.
3. Activate. We charge the cycle, the monitor becomes active and checks for the first time right away.
4. Check. After that it checks at the chosen interval. Each new signal triggers one message per monitor to your webhook endpoints.
5. Renew. After each cycle the next one is charged automatically, as long as your balance covers it.

The check interval is between 1 and 30 days. The exact time of a check can vary within an hour. Each check looks back a few days, so entries published late still arrive.

A monitor delivers the Signals topics of your plan: five in every account, Insolvencies with Pro, Transformations & M&A with Max. A webhook carries the same signal in the field data.signal as signals does.

For paused monitors and errors, status_reason explains why, for example no_verified_endpoint or insufficient_cycle_floor.

All paths are under /v1/account. You read and write with your API key in the header x-api-key.

Every write request needs the header Idempotency-Key, a unique value per operation, ideally a UUID. Without it the API answers with 428.

If you repeat a request with the same key and the same data within 24 hours, you get the stored response back. It carries the header Idempotency-Status: replayed. That way a network error does not create a second monitor.

This also applies to error responses. So for a new attempt after a correction, use a new key. The same key with different data returns 409.

Up to 128 characters are allowed: letters, digits and . _ : -. The first character is a letter or a digit. A key in any other format returns 400.

You need the company's entity_id and at least one verified webhook endpoint, see account/webhook-endpoints.

The API answers with 202: the monitor is created, and baseline and activation run in the background. meta.billing.charged_credits shows that nothing was charged for this.

GET /v1/account/monitors returns up to 100 monitors under monitors, with total. Archived ones are not in the list.

GET /v1/account/monitors/{id} also shows the current cycle in billing_cycle and the latest checks in recent_runs.

PATCH /v1/account/monitors/{id} changes the check interval. The next check then follows at the new interval, counted from the change.

The current cycle keeps its price and included checks. The new price applies from the next cycle. A shorter interval can trigger extra checks in the current cycle.

POST …/{id}/pause stops an active monitor. The paid cycle keeps running out, and nothing is refunded.

POST …/{id}/resume resumes a paused monitor or a monitor with an error. We check webhook endpoints, balance and price again.

Within the current paid cycle, resuming costs nothing. If the cycle has run out, a new cycle starts now at the current price. meta.request_credit_cost shows the amount.

If, say, a verified webhook endpoint is missing, the API still answers with 200, but with meta.activated: false. The monitor's status and status_reason give the reason.

If the price has changed, an active monitor stops at the end of the cycle with pricing_consent_required. With resume you agree to the new price.

DELETE …/{id} archives the monitor for good. This is final and refunds nothing.

Errors have the structure {"error": "…", "meta": {"message": "…"}}. In your program, check the value of error. The text in meta.message is in English and can change. Errors cost nothing.