Fiserv Case Management mock API and live sandbox

By treating the constant as what it is: an intake receipt, not an identity. The sandbox confirms each verb's request shape and success envelope but maintains no registry, so two creates yield the same key and a close never changes what the overview reports. Multi-case logic — distinct keys, state that moves, a search that finds what you filed — belongs in a private WireMock Cloud copy, where scenario stubs can mint differing keys and advance a case's status per call. Here, assert the envelope: SUCCESS, the operation message, an empty errors array.

The complete result contract, including its edge. Case search, Solr search, secondary-index search, and the by-user-id view all answer with matchingRecordsCount 0, an empty record list, and a pagingKey field — which makes them precise fixtures for the no-results path every case UI needs: rendering empty states, not paginating past nothing, and distinguishing "found none" from "request failed". The populated path then needs only the same shape with rows in a private copy.

The document surface answers structurally: previewDocument returns an empty responseMap — the keyed container the real service fills with rendered content — and the letter-config list, document types, and attach-detach verbs each answer their envelopes. That's enough to wire the request path and the unwrapping code on the client side. For rendering tests, seed the responseMap in your own copy with a base64 payload your viewer accepts, sized to your needs.

It's the generic engine — fraud is one tenant of it. For contrast, the Card Developer template carries the fraud desk's own case routes with populated fixtures (a searchable OPEN case under a nine-nines case number, claims with composite item identifiers), which makes it the better surface for asserting on case content; this template is the one for exercising workflow breadth — the diarize-close-reopen arc, task states, queue wiring — that the specialized surfaces don't expose.