STstuut
integrations

Boomi → Stuut: confirm whether SAP applied a writeback

Authenticates with the same Bearer api_key the inbound push endpoints use. The request_id must match a BoomiActivityDelivery row owned by the resolved connection — Stuut flips that row to DELIVERED on status == "success" or FAILED otherwise.

Re-posting the same terminal status is a no-op (returns the cached row's state). Posting a different terminal status for the same request_id is rejected with 409 so Boomi noise doesn't silently overwrite a prior outcome.

post/v2/integrations/providers/boomi/activities/processing-response

Request

  • Base URL
    https://api.stuut.ai (the document declares no server; this is the origin it was published from)
  • Auth
    HTTP bearer

Request body

request_idstring required

Echoes the request_id Stuut sent on the activity-sync push

status'success' | 'failed' required

Terminal outcome — Stuut treats anything other than 'success' as a final failure.

processed_atstring date-time required

When SAP confirmed / rejected the writeback

sap_document_numberstring nullable

BKPF-BELNR Boomi updated, echoed for audit. Required on success; may be omitted on failure.

sap_fiscal_yearstring nullable

BKPF-GJAHR echoed for audit

sap_line_itemstring nullable

BSEG-BUZEI of the customer line that was overwritten (success only)

error_codestring nullable

Stable identifier on failure — INVOICE_NOT_FOUND, INVOICE_NOT_OPEN, CUSTOMER_MISMATCH, SAP_LOCKED, SAP_ERROR, INTERNAL_ERROR.

error_messagestring nullable

Human-readable error detail

Response

Successful Response

request_idstring required
received_atstring date-time required
activity_status'synced' | 'failed' | 'orphaned' required

'synced' / 'failed' mirror the delivery row's new terminal state. 'orphaned' means Stuut accepted the callback but had no matching row — useful for Boomi-side retries after a Stuut DB rollback.

messagestring nullable required

Changes

No recorded changes to this operation across all 2 revisions of this API.