Record a client settlement-deposit ack
Records the client’s STR deposit ack for a relayed position notify and drives the settlement instruction to ACKED for a SENT deposit (from PENDING or NOTIFIED) (the client owns the STR connection; the SLC emits NO LDL0022). A FAILED result is recorded but leaves the instruction unchanged so the deposit can be re-driven. Synchronous and definitive. Idempotent via the Idempotency-Key header (a retry carrying the same key replays the stored response). result must be SENT or FAILED (coded 400 otherwise). RBAC: funding:write; tenant is always derived from the validated request identity, never the payload.
Authorizations
JWT bearer token issued by the identity provider.
Headers
Idempotency key for safe retries; a replay carrying the same key returns the stored response instead of appending a duplicate audit row (scoped to tenant + this instruction's ack route).
Path Parameters
Settlement instruction id (UUID).
"018f8a3e-4b2c-7c1a-9e5d-2f6a1b3c4d5e"
Body
Client deposit result: SENT (deposited) or FAILED (could not). Case-insensitive — the value is upper-cased before validation, so "sent"/"failed" are accepted (intentionally lenient).
"SENT"
When the client reported the ack (RFC3339). Omitted stores NULL.
"2026-06-28T11:00:00Z"
Deposited amount in cents.
5011
Failure reason when result is FAILED.
"insufficient reserves"
Client reference to its LDL0022 (IF->STR); recorded for audit, outside the SLC.
"LDL0022-2026-06-28-000123"
Response
OK
The settlement instruction id the ack was recorded against.
The accepted ack result (SENT/FAILED), upper-cased.
Whether this ack drove the instruction to ACKED. True only for a SENT ack that matched an instruction in PENDING or NOTIFIED; false for FAILED and for a SENT ack against an instruction not in PENDING/NOTIFIED (already acked/settled). The ack is recorded either way.
The resulting instruction state — present ONLY when this ack drove the transition (always ACKED). Omitted when transitioned is false; do not infer a state from the result.

