Insolvency data, by API

Authenticate

Send your key as an X-API-Key header, or as anapi_key query parameter when a header is awkward.

There are two kinds. A read-only key reaches the search endpoints. An account key, which looks likeask_... and is issued once when you subscribe, reaches those plus the watch and webhook routes. Store it when you see it; it is not shown again.

curl "https://api.insolvencyalerts.com.au/v1/notices?q=drifta" \
  -H "X-API-Key: YOUR_API_KEY"

Search notices

GET /v1/notices takes a company name, an ACN, or filters like state and appointment type. Every request needs anX-API-Key header.

curl "https://api.insolvencyalerts.com.au/v1/notices?q=briagin" \
  -H "X-API-Key: YOUR_API_KEY"

{
  "data": [
    {
      "id": "6ce624e8-038a-4c93-acd1-06ed9be1974d",
      "company_name": "BRIAGIN PTY LIMITED",
      "acn": "163753428",
      "notice_title": "NOTICE OF APPLICATION FOR WINDING UP ORDER",
      "notice_code": "465A(1)(c)",
      "appointment_type": "Winding Up Application",
      "state": "NSW",
      "is_deregistration": false,
      "published_date": "2026-09-17",
      "source_url": "https://publishednotices.asic.gov.au/browsesearch-notices/notice-details/BRIAGIN-PTY-LIMITED-163753428/6ce624e8-038a-4c93-acd1-06ed9be1974d",
      "seq": 4821
    }
  ],
  "meta": { "page": 1, "limit": 20, "total": 1 }
}

Screen a whole book in one call

POST /v1/match answers "which of these have notices?" and stores nothing. It takes up to 50,000 identifiers at a time, ACNs or ABNs, and resolves ABNs through ASIC's company register.

Deregistrations are hidden by default here and everywhere else: 88.7% of all notices collected are deregistrations, so counting them would report that almost every company in your book "has notices" when almost none are distressed. Opt in withinclude_deregistration when you actually want them.

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

Watch a list, then stop polling

A watch needs identifiers, at least one filter, or both — one with neither would match every notice and is rejected. Identifiers that cannot be resolved come back in unresolved instead of being silently dropped, which matters because around 30% of notices are for companies outside the register.

Attach a webhook to the watch and matches are pushed to you. Add and remove identifiers as your book changes, without rebuilding the watch.

POST /v1/watches

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

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

Get webhooks instead of polling

Register an https:// endpoint on a watch and matching notices arrive as signed POST requests. Verify withX-ASIC-Signature, an HMAC-SHA256 of the raw body, and dedupe on X-ASIC-Delivery, which stays the same across retries.

Any 2xx acknowledges. A failure is retried five times with increasing delays; ten consecutive failures deactivate the watch, and reactivating it delivers what queued up meanwhile. When something looks wrong, GET /v1/watches/{id}/deliveries shows the status, attempt count and the last error your endpoint returned.

POST https://your-app.example/asic
X-ASIC-Signature: sha256=<hex>
X-ASIC-Delivery: dlv_...
Content-Type: application/json

{
  "watch_id": "wch_...",
  "delivered_at": "2026-09-23T01:15:00.000Z",
  "notice": { "company_name": "BRIAGIN PTY LIMITED", "acn": "163753428", ... }
}

Poll without missing late arrivals

Pass since with the highest seq you have seen. The response switches to ascending order and returns only higher seq values, so a notice that ASIC publishes late still reaches you rather than falling behind a date cursor.

Use meta.next_since for the next call. It advances past notices your filters excluded, not just the ones returned, so a filtered poll keeps making progress instead of stalling on a tail of rows it will never be shown.

curl "https://api.insolvencyalerts.com.au/v1/notices?since=4821" \
  -H "X-API-Key: YOUR_API_KEY"

{
  "data": [ ... ],
  "meta": { "next_since": 4877 }
}