Processing step and import queue

📘
Most integrations don't need this page. It only applies if your participant has one of the optional setups below. If you exchange messages between your ERP and Unimaze, see Webhooks.

These setups build on Webhooks. Signatures, routing rules, retries and delivery guarantees work the same way for their events.

Setup	Extra events	Extra event categories	Acknowledge with
Processing step, such as an approval system	`processingNotified`, and the processing statuses in `messageStatusChanged`	Inbound processing notifications	`mark-as-processed`
Documents added later by another system	`attachmentAdded`, `attachmentRemoved`	None: sent with the message's other events	Nothing
Import queue	`importNotified`, `importStatusChanged`	Inbound import notifications, Outbound import notifications	`mark-as-imported`

Processing step

Most participants' inbound messages go straight to pendingdelivery, where the ERP fetches them. A participant can instead have a processing step, where its own processing system, such as an approval system, works on each message before the ERP:

The message becomes pendingprocessing, and the processing system gets processingNotified.
The processing system may call mark-as-in-process to show that it is working on the message, if your participant is set up for it. The message becomes processing.
When it calls mark-as-processed, the message becomes pendingdelivery and your ERP gets deliveryNotified.

Each status change is also sent as messageStatusChanged, for example pendingprocessing → processing.

`action`	Inbound	Outbound	Sent when	What you must do
`processingNotified`	✔		The message is waiting for your processing system (status `pendingprocessing`).	Fetch the document, optionally call `mark-as-in-process`, and call `mark-as-processed` when processing is done.

processingNotified is sent in its own event category, Inbound processing notifications, so it can go to the processing system's endpoint while the ERP gets the other events (see Event categories). Each system then has one event to act on:

The processing system acts on processingNotified. It doesn't need created.
The ERP acts on deliveryNotified, which describes the final message as the ERP gets it.

A processing step holds the message back from your ERP until mark-as-processed. When people approve invoices by hand, that can take days. If your ERP needs to know about the message before then, use created: note the messageId, and import the documents only when deliveryNotified arrives, because the processing system can add to them, for example with booking data (see Documents added later).

📘
Some setups have a pre-processing step before that, with the statuses pendingpreprocessing and preprocessing. Your systems don't act on it: you only get messageStatusChanged events.

Documents added later

A created event lists all the documents sent with the message. A system can add supplementary documents later, such as booking data from an approval system, with POST /messages/:mid/booking-data/documents. These changes are sent in the Inbound messages or Outbound messages category, so they reach the same endpoint as the message's other events.

`action`	Inbound	Outbound	Sent when	What you must do
`attachmentAdded`	✔	✔	A supplementary document was added to the message after it was created. `data` lists all its documents.	Refresh your copy if needed.
`attachmentRemoved`	✔	✔	A supplementary document was removed from the message (`DELETE /messages/:mid/booking-data/documents/...`). `data` lists the documents it still has.	Refresh your copy if needed.

If you import on inbound deliveryNotified, you can ignore these events for documents added before it: deliveryNotified lists them all.

Pending import messages

Some messages are created by one of your systems and must be imported by another. For example, a billing or worklog system creates invoices that your ERP must book.
The import status is tracked alongside the message status, so an import queue doesn't interfere with the ERP's inbound flow. A processing step, by contrast, comes before delivery.

`action`	Inbound	Outbound	Sent when	What you must do
`importNotified`	✔	✔	The message is waiting to be imported into your system (import status `Pending`).	Import the document and call `mark-as-imported`.

Messages in the import queue have an import status that is Pending until the receiving system calls mark-as-imported, in both directions:

GET /messages/pending-import lists messages waiting to be imported.
POST /messages/:mid/mark-as-imported marks a message as imported.

Each change of the import status is sent as a status event:

`action`	Sent when	Example values
`importStatusChanged`	The import status changed, for example after you call `mark-as-imported`. The values are the same as `importStatus` in MAPI: `NotSet`, `Pending` and `Imported`.	`Pending` → `Imported`, `Imported` → `Pending`

importStatusChanged has no properties. Like other status events, it is also sent for your own changes (mark-as-imported and reset-import-status), unless you switch that off per routing rule.

Import notifications are sent in their own event categories, Inbound import notifications and Outbound import notifications, so they reach the system that does the import (see Event categories).

Event categories

These categories are added to Inbound messages and Outbound messages (see Endpoints and routing). They are only shown in the webhook setup if your participant has the setup:

Event category	Includes	Shown
Inbound processing notifications	Inbound `processingNotified`	If your participant has a processing step
Inbound import notifications	Inbound `importNotified` and `importStatusChanged`	If your participant has an inbound import queue
Outbound import notifications	Outbound `importNotified` and `importStatusChanged`	If your participant has an outbound import queue

The Inbound messages category then includes all inbound events except processing and import notifications, and Outbound messages all outbound events except import notifications.

For example, a billing system creates the outbound invoices and follows their delivery, the ERP receives the inbound messages and imports the invoices, and a purchasing system imports the outbound orders:

Event category	Filter	Endpoint
Inbound messages		ERP
Outbound messages		Billing system
Outbound import notifications	`Invoice/XML,CreditNote/XML`	ERP
Outbound import notifications	`Order/*`	Purchasing system

Acknowledging messages

As in the main flow, responding 2xx to a webhook never changes the message (see Acknowledging messages). Acknowledge each message with a MAPI call after you have safely stored it:

Notification	Acknowledge with	On failure
`processingNotified`	`POST /messages/:mid/mark-as-processed`	`POST /messages/:mid/mark-as-failed`
`importNotified`	`POST /messages/:mid/mark-as-imported`	Leave it pending and retry, or resolve it in MUI

Add these to your daily safety-net check (see Unacknowledged messages):

With a processing step, GET /messages?status=pendingprocessing&transfer=inbound returns messages your processing system never marked as processed.
With an import queue, GET /messages/pending-import returns messages that were never marked as imported.

Testing

Send test event in the webhook setup works for these categories too: choose the category, such as Inbound processing notifications, and one of its actions.

Checklist

In addition to the Webhooks checklist:

If your participant has a processing step:

Inbound processing notifications routed to the processing system
Every processingNotified acknowledged with mark-as-processed
Daily check for messages left in pendingprocessing

If your participant has an import queue:

Import notifications routed to the importing system
Every importNotified acknowledged with mark-as-imported
Daily check of GET /messages/pending-import