Skip to content

Watches

Watch routes need an account key (ask_...), which is issued when you subscribe. It’s different from a read-only key: see Getting started.

POST /v1/watches

{
"name": "debtor book",
"identifiers": ["163753428", "32613554233"],
"appointment_type": ["Court Liquidation"],
"include_deregistration": false
}

identifiers accepts 9-digit ACNs and 11-digit ABNs, up to 50,000 per request. ABNs are resolved to ACNs through ASIC’s company register. Any that can’t be resolved come back in unresolved rather than being silently dropped, since about 30% of notices are for companies outside the register.

A watch needs identifiers, at least one filter (appointment_type, notice_purpose, notice_code, state), or both. One with neither would match every notice and is rejected.

Response:

{
"id": "wch_...",
"name": "debtor book",
"acn_count": 2,
"unresolved": []
}

Matches show your watch’s full history from the day it’s created, not only notices that arrive afterwards. A company that was already in liquidation when you added it appears immediately.

  • POST /v1/watches/{id}/acns: add identifiers, body {"identifiers": [...]}.
  • DELETE /v1/watches/{id}/acns: remove identifiers, same body.

Both accept up to 50,000 identifiers per request, and resolve ABNs the same way POST /v1/watches does.

  • GET /v1/watches: list your watches.
  • GET /v1/watches/{id}: one watch, with acn_count.
  • DELETE /v1/watches/{id}: remove it.
  • GET /v1/watches/{id}/matches: matching notices, paged with ?since= exactly like /v1/notices.
  • PATCH /v1/watches/{id}: update a watch. Accepts active (see Webhooks for reactivation behaviour), name, and alert_email: an email address to associate with the watch, or null to clear it.

POST /v1/match answers “which of these have notices?” without storing anything. Useful for screening a book once rather than monitoring it.

{
"identifiers": ["163753428", "999999999"]
}
{
"data": {
"checked": 2,
"matched": 1,
"matches": [{ "acn": "163753428", "notice_count": 3 }],
"unresolved": [],
"include_deregistration": false
}
}

Like every other read surface in this API, /v1/match hides deregistration notices by default. Around nine in ten notices collected are deregistrations — GET /health reports the live split, as notices.notices against notices.insolvency_notices — so counting them by default would tell a credit team that nearly every company in its book “has notices” when almost none are actually distressed. Pass {"include_deregistration": true} in the body to opt in. The response always echoes back include_deregistration, and notice_count only counts non-deregistration notices unless you opted in.

Creating a watch, or adding identifiers to one, is checked against your plan’s limits before anything is written. See Getting started for the full quota table and error shapes (quota_exceeded, watch_limit_reached), both returned as HTTP 402.