Rejected e-mails: triage & override

Driving orders via the API

Not every mail in the order mailbox is an order. Quotations, order confirmations, delivery notes, invoices, internal requisitions and marketing mail are classified and rejected — recorded with the classifier's reason, never extracted, and never sent to your ERP. The product prefers a false "not an order" (recoverable by a person) over a phantom order in your ERP.

Listing

GET/rejected/list?status=pendingintegration key

{ "items": [ { "request_id": "…", "email_type": "invoice", "sender": "supplier@example.com", "from_name": "Supplier",
               "subject": "Invoice 12345", "timestamp": "…", "classification_reason": "Document reads as an invoice, not an order",
               "rejection_status": "pending", "original_email_type": null, "message_id": "<abc@example.com>", "metadata": {} } ],
  "total": 12, "limit": 100, "offset": 0 }

status=pending (default) — awaiting a decision. status=overridden — already reprocessed by someone.

Overriding

POST/rejected/{request_id}/reprocessintegration key

Forces the mail through order processing under the same request_id. The original classification is preserved (original_email_type) and the item moves to overridden. From then on it is a normal order: poll GET /order_status/{request_id}.

for mail in client.rejected.list().items:
    if looks_like_an_order(mail):                     # your heuristic, e.g. known sender + "bestelling" in subject
        client.rejected.reprocess(mail.request_id)

409 if already overridden or a concurrent override won; 404 for ids that are not rejections.

Uploaded raw e-mails

When you upload an .eml that turns out not to be an order, POST /order/raw/upload answers 400 with the structured detail and records it here, so the same override path applies.

Typical automation

• Daily digest of pending rejections to the sales inbox (sender, subject, reason).
• Auto-override for a short allow-list of senders whose mails are always orders but look like something else (e.g. a customer whose "confirmation" is really an order).
• Never auto-override globally: the classifier is right far more often than not.