Posted Customer Refunds Realtime-enabled

Read-only posted customer refunds, a webhook source for status writeback: subscribe to be pushed the moment a refund posts to the customer ledger. The applications child reports which invoices the refund settled and each one's resulting balance, so a partial refund is a single event here.

The settlement-truth feed

This feed is where payment/settlement status lives. When a refund posts, fully or partially, you are pushed one notification on postedCustomerRefunds. $expand=applications (or GET postedCustomerRefunds({id})/postedDocApplications) to see, per settled invoice, the appliedAmount, the invoice's resulting appliedRemainingAmount, and appliedOpen. So a $30 refund against a $100 invoice tells you "invoice now $70 outstanding"; the next $70 refund tells you "paid in full", without the invoice feed re-firing.

Late application (a refund posted unapplied, then applied via Apply Entries) re-fires this refund, never the invoice feed.

Subscribing

Register a subscription against the entity set; Business Central notifies your endpoint when a row changes. The notification carries the record id. GET it to read the current values.

POST /subscriptions
{
  "resource": "/postedCustomerRefunds",
  "notificationUrl": "https://your-endpoint",
  "clientState": "<secret>"
}

Status

status is the human-readable settlement state (Open, Partially Settled, or Settled) computed from the ledger entry, so you write status back without interpreting raw open/remaining-amount semantics. remainingAmount and settledAmount carry the figures behind it.

Retention

The projection is a short-lived event feed, not a store: rows are purged by the background job once their posting date is older than the configured retention window, 7 days by default (options 7, 14, 28 on the setup page, or via the integrationSetup API). The backfill only seeds documents within that window, and a purge sends subscribers a delete notification. Consume and reconcile within the window.