# Event types

## Event types
| `event_type` | Fires when |
|  --- | --- |
| `tender.completed` | A tender offer is **released to the partner API** — the seller clicks **Finalize** (Export → API) in the matching view. Carries `tender_id` (= the request id) and `completed_at`; fetch the full record from `GET /tenders/{tender_id}`. Fires again (with a newer `completed_at`) on every re-release. (Other export paths — PDF, offer email/download, the ERP callback — do NOT fire this.) |
| `order.completed` | An order is **finalised** (marked exported) for handoff. Carries `order_id` (= the request id) and `completed_at`; fetch the full record from `GET /orders/{order_id}`. |
| `order.status_changed` | An order moves between the **stages of the orders inbox** — `PROCESSING` -> `ACTION_REQUIRED` -> `READY_TO_EXPORT` -> `EXPORTED` -> `ARCHIVED`, or to `DELETED`. Carries `order_id`, `name`, the new `status`, the `previous_status` it left, a `reason` when the order needs a human (`ACTION_REQUIRED`), and `changed_at`; fetch the full record from `GET /orders/{order_id}`. This is the *progress* signal for the whole pipeline, where `order.completed` is the *handoff* signal only — subscribe to this one if you want to follow an order before it is finished. |
| `project.exported` | A Mercura user hands a **project** (*Objekt*) over to your system — the **Send to ERP** button on the project page. Carries `project_id` and the current `object_number`; fetch the full record from `GET /projects/{project_id}`, create it on your side, then report the outcome with `POST /projects/{project_id}/acknowledgements`. Unlike the `*.completed` events this is an explicit handoff, not a lifecycle transition: the project's `status` is untouched and re-clicking emits again. The button only appears for organisations subscribed to this event. |
| `job.finished` | A bulk-write job from this API (`POST /articles` / `/customers` / `/suppliers`) reaches a terminal status (`COMPLETED` or `FAILED`), once per job. Replaces the need to poll `GET /jobs/{job_id}`; fetch it once when the job failed or had row errors. |
| `webhook.test` | A human clicks **Send test event** in the admin UI. Carries a fixed synthetic payload — useful for end-to-end smoke tests of your verification code. Always JSON, also on subscriptions that carry files. |

Every event type uses the same headers and signature scheme (below), so a
`webhook.test` delivery validates your verification code against the
exact production contract before you rely on any real event. The body is
the JSON envelope below unless the subscription carries export files —
see **File payloads**.

Version: 1.79.2

## Description:

  - `Event types` ()
    | `event_type` | Fires when |
|  --- | --- |
| `tender.completed` | A tender offer is **released to the partner API** — the seller clicks **Finalize** (Export → API) in the matching view. Carries `tender_id` (= the request id) and `completed_at`; fetch the full record from `GET /tenders/{tender_id}`. Fires again (with a newer `completed_at`) on every re-release. (Other export paths — PDF, offer email/download, the ERP callback — do NOT fire this.) |
| `order.completed` | An order is **finalised** (marked exported) for handoff. Carries `order_id` (= the request id) and `completed_at`; fetch the full record from `GET /orders/{order_id}`. |
| `order.status_changed` | An order moves between the **stages of the orders inbox** — `PROCESSING` -> `ACTION_REQUIRED` -> `READY_TO_EXPORT` -> `EXPORTED` -> `ARCHIVED`, or to `DELETED`. Carries `order_id`, `name`, the new `status`, the `previous_status` it left, a `reason` when the order needs a human (`ACTION_REQUIRED`), and `changed_at`; fetch the full record from `GET /orders/{order_id}`. This is the *progress* signal for the whole pipeline, where `order.completed` is the *handoff* signal only — subscribe to this one if you want to follow an order before it is finished. |
| `project.exported` | A Mercura user hands a **project** (*Objekt*) over to your system — the **Send to ERP** button on the project page. Carries `project_id` and the current `object_number`; fetch the full record from `GET /projects/{project_id}`, create it on your side, then report the outcome with `POST /projects/{project_id}/acknowledgements`. Unlike the `*.completed` events this is an explicit handoff, not a lifecycle transition: the project's `status` is untouched and re-clicking emits again. The button only appears for organisations subscribed to this event. |
| `job.finished` | A bulk-write job from this API (`POST /articles` / `/customers` / `/suppliers`) reaches a terminal status (`COMPLETED` or `FAILED`), once per job. Replaces the need to poll `GET /jobs/{job_id}`; fetch it once when the job failed or had row errors. |
| `webhook.test` | A human clicks **Send test event** in the admin UI. Carries a fixed synthetic payload — useful for end-to-end smoke tests of your verification code. Always JSON, also on subscriptions that carry files. | Every event type uses the same headers and signature scheme (below), so a
`webhook.test` delivery validates your verification code against the
exact production contract before you rely on any real event. The body is
the JSON envelope below unless the subscription carries export files —
see **File payloads**.