Copy page

Webhooks

Operations & domains

Operations & domains events fire against things Most is doing for you or tracking on your behalf — bulk tasks, order batches, and per-domain lifecycle events like expiry, deletion, blocks and abuse complaints. They cover the hot path of day-to-day automation.

task.completed

Fires whenever an async task finishes — success, partial, or full failure. Use it to avoid polling GET /v1/tasks/{id}.

Tasks cover a handful of bulk operations:

Task type	Source endpoint
domain.renew	POST /v1/domains/renew
domain.set_nameservers	POST /v1/domains/set-nameservers
domain.get_auth_info	POST /v1/domains/get-auth-info

The data shape is the same across all task types — only type and the per-item result[].data content changes. See GET /tasks/{id} for the full schema and example responses for each task type.

Code
{
  "event": "task.completed",
  "data": {
    "taskId": "cm3x4task001",
    "type": "domain.renew",
    "status": "COMPLETED",
    "total": 2,
    "completed": 2,
    "failed": 0,
    "result": [
      {
        "domainId": "cm3x4domain001",
        "domain": "example.com",
        "ok": true,
        "data": { "term": 1, "newExpiry": "2027-04-11T00:00:00.000Z" }
      },
      {
        "domainId": "cm3x4domain002",
        "domain": "test.net",
        "ok": true,
        "data": { "term": 2, "newExpiry": "2028-04-11T00:00:00.000Z" }
      }
    ]
  },
  "timestamp": "2026-04-11T12:00:16.000Z"
}

Possible status values:

• COMPLETED — every item succeeded.
• PARTIAL — some items succeeded and some failed. Walk result[] and check each ok flag to tell them apart.
• FAILED — every item failed, or the task hit a fatal error before per-item processing.

orders.registered

Order processing is a two-stage flow: first the order is submitted to the registrar (stage 1, registration), then the requested nameservers are applied (stage 2, configuration). Some registrars need noticeable NS-setup time because the domain must be fully provisioned on their side before NS can be attached.

orders.registered fires as soon as every order in a batch has cleared stage 1 — independent of whether NS has been applied yet. Use it for fast UX feedback ("your domains are registered") without waiting for the slower configuration stage. Fires exactly once per batch.

Code
{
  "event": "orders.registered",
  "data": {
    "batchId": "batch_a1b2c3d4e5f6",
    "total": 3,
    "registered": 3,
    "failed": 0,
    "orders": [
      { "id": "cm3x4order001", "domain": "example.com", "status": "SETTING_NS", "errorMessage": null },
      { "id": "cm3x4order002", "domain": "test.net",    "status": "SETTING_NS", "errorMessage": null },
      { "id": "cm3x4order003", "domain": "demo.io",     "status": "REGISTERED", "errorMessage": null }
    ]
  },
  "timestamp": "2026-04-11T12:03:02.000Z"
}

Each order's status at this point will be REGISTERED, SETTING_NS, COMPLETED, or FAILED. Orders that failed during stage 1 are counted in failed and excluded from registered.

orders.completed

Fires when every order in a batch reaches a terminal state (COMPLETED or FAILED) — i.e. both registration and NS configuration are done. Fires exactly once per batch. If you only care about stage 1, subscribe to orders.registered instead — they are independent events, not redeliveries of the same one.

Code
{
  "event": "orders.completed",
  "data": {
    "batchId": "batch_a1b2c3d4e5f6",
    "total": 3,
    "completed": 2,
    "failed": 1,
    "orders": [
      { "id": "cm3x4order001", "domain": "example.com", "status": "COMPLETED", "errorMessage": null },
      { "id": "cm3x4order002", "domain": "test.net",    "status": "COMPLETED", "errorMessage": null },
      { "id": "cm3x4order003", "domain": "fail.io",     "status": "FAILED",    "errorMessage": "Insufficient balance" }
    ]
  },
  "timestamp": "2026-04-11T12:03:22.000Z"
}

domain.expiring

Fires at eight checkpoints before a domain's expiry date, so you can build a gentle escalation (first reminder → daily nudges → last-chance alert):

checkpoint	When it fires
30	~1 month before expiry
7	1 week before
6	6 days before
5	5 days before
4	4 days before
3	3 days before
2	2 days before
1	1 day before (last warning)

Each (domain, checkpoint) pair fires at most once per expiry period — renewing the domain resets the counter for the next cycle. The scan runs every 6 hours, so the event lands within a few hours of the actual threshold. If the scanner was down, missed checkpoints are caught up on the next run.

Code
{
  "event": "domain.expiring",
  "data": {
    "domainId": "cm3x4domain001",
    "domain": "example.com",
    "expiredAt": "2026-05-05T00:00:00.000Z",
    "daysLeft": 7,
    "checkpoint": 7,
    "client": { "login": "acme-corp" },
    "registrar": {
      "id": "cm3x4prov001",
      "type": "SPACESHIP"
    }
  },
  "timestamp": "2026-04-28T06:00:00.000Z"
}

Tip: drive your UI off checkpoint (stable, predictable values) rather than daysLeft (the exact real-time delta, which can be off by a few hours).

domain.deleting

Fires once when a domain has crossed its expiry date and is about to be removed by the registrar. This is your last-chance notification — after this event the domain will shortly be released into the public pool.

Code
{
  "event": "domain.deleting",
  "data": {
    "domainId": "cm3x4domain001",
    "domain": "example.com",
    "expiredAt": "2026-05-05T00:00:00.000Z",
    "daysOverdue": 1,
    "client": { "login": "acme-corp" },
    "registrar": {
      "id": "cm3x4prov001",
      "type": "SPACESHIP"
    }
  },
  "timestamp": "2026-05-06T06:00:00.000Z"
}

Fires at most once per expiry period. If you renew the domain after this event, the next expiry cycle starts fresh and the eight domain.expiring checkpoints re-arm for the new period.

domain.blocked

Fires when a domain's status transitions to BLOCKED. Does not fire if the domain was already blocked — this is an edge-triggered event, not a periodic reminder.

Typical triggers:

• A registrar's abuse team acts on a complaint (phishing, malware, trademark, CSAM).
• An automated scanner at the registry or the registrar flags the domain.
• Most's own abuse handling (when it lands) marks the domain defensively.

See the Webnic entry on the Registrar peculiarities page for why a single abuse hit on Webnic can sometimes block multiple unrelated domains in the same reseller account — they'll each fire this event independently, so expect bursts.

Code
{
  "event": "domain.blocked",
  "data": {
    "domainId": "cm3x4domain001",
    "domain": "example.com",
    "reason": "Abuse complaint — phishing",
    "client": { "login": "acme-corp" },
    "registrar": {
      "id": "cm3x4prov001",
      "type": "SPACESHIP"
    }
  },
  "timestamp": "2026-04-11T15:42:00.000Z"
}

domain.complaint

Reserved — not yet emitted.

Will fire when Most receives an abuse complaint against one of your domains (phishing, malware, copyright, trademark, CSAM). Scoped separately from domain.blocked so you can triage and reply to a complaint before the registrar auto-blocks — in most cases you have a few hours to respond.

Expected payload shape (subject to change):

Code
{
  "event": "domain.complaint",
  "data": {
    "domainId": "cm3x4domain001",
    "domain": "example.com",
    "category": "phishing",
    "reporter": "[email protected]",
    "description": "Fake login page impersonating …",
    "severity": "high",
    "deadlineAt": "2026-04-12T15:00:00.000Z",
    "client": { "login": "acme-corp" },
    "registrar": { "id": "cm3x4prov001", "type": "SPACESHIP" }
  },
  "timestamp": "2026-04-11T15:00:00.000Z"
}