---
title: "Boomi → Stuut: confirm whether SAP applied a writeback"
method: POST
path: "/v2/integrations/providers/boomi/activities/processing-response"
tags: ["integrations"]
---

# Boomi → Stuut: confirm whether SAP applied a writeback

`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)
- URL: `https://api.stuut.ai/v2/integrations/providers/boomi/activities/processing-response`
- Auth: HTTP bearer

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.

## Request body

- BoomiActivityProcessingResponse: Async ack from Boomi confirming whether SAP applied a writeback. Boomi POSTs this once it has heard back from SAP for a previous outbound activity-sync push. The `request_id` echoes the row id Stuut sent on the wire; Stuut uses it to flip the matching ``BoomiActivityDelivery`` row from SENT to DELIVERED or FAILED.
  - `request_id` string, 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_at` string, date-time, required: When SAP confirmed / rejected the writeback
  - `sap_document_number` string, nullable: BKPF-BELNR Boomi updated, echoed for audit. Required on success; may be omitted on failure.
  - `sap_fiscal_year` string, nullable: BKPF-GJAHR echoed for audit
  - `sap_line_item` string, nullable: BSEG-BUZEI of the customer line that was overwritten (success only)
  - `error_code` string, nullable: Stable identifier on failure — INVOICE_NOT_FOUND, INVOICE_NOT_OPEN, CUSTOMER_MISMATCH, SAP_LOCKED, SAP_ERROR, INTERNAL_ERROR.
  - `error_message` string, nullable: Human-readable error detail

## Response `200`

Successful Response

- BoomiActivityProcessingAck: Sync response Stuut returns when it accepts a processing-response.
  - `request_id` string, required
  - `received_at` string, 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.
  - `message` string, nullable, required

## Other responses

- `422`: Validation Error

---

[API](https://skmtc.dev/stuut/apis/stuut-api.md) - [All operations](https://skmtc.dev/stuut/apis/stuut-api/llms.txt) - [OpenAPI document](https://skmtc.dev/stuut/apis/stuut-api/revisions/ff0ad16a55ff?raw)