type URI identifies the problem and equals https://api.casepathiq.com/problems/ plus the code. Branch client logic on the top-level code, the stable outcome code for the response; use the per-field errors[].code values (at most 50) to locate what to correct. Never branch on human-readable title or detail. The full list of codes is in the ProblemDetails schema of the API reference.
Common outcomes
Every response from the application includes
X-Request-Id; the only exception is a 429 answered by the network edge before the request reaches the application, which carries Retry-After but no request id. Keep it with your integration telemetry for support correlation. A 429 or 503 always carries Retry-After in seconds. While the platform pauses Partner API writes, every write returns 503 partner_writes_paused and reads keep working; retry the same request later.
Retry decision guide
CasePath IQ v1 does not use a callerIdempotency-Key, sourceRevision, sourceEventId, or predecessorSourceRevisionId.
Identical Matter PUT or PATCH content returns
200 with no new sourceRevisionId and unchanged updatedAt only while that representation remains current — and only when its precondition still holds. A delayed retry that arrives after another write carries a tag that is no longer current, so it is refused 412 without mutation instead of reverting the Matter to older content.
An identical Payment observation retry returns the existing observation. The same external payment ID with different content returns 409 payment_observation_conflict.
An exact lifecycle retry returns the accepted occurrence only while that occurrence is still the current lifecycle head. A stale or superseded command returns a typed 409; read the Matter before choosing a new transition.
Concurrent writes
Serialize writes per Matter and per external payment ID. If different Matter PUT or PATCH requests race, CasePath IQ accepts at most one. The loser returns412 precondition_failed when its precondition was already superseded, or 409 source_write_conflict when two writes reach the Matter lock together. Either way the server does not silently chain the losing request onto state it did not read.
Balance-changing Payment observations and lifecycle operations also lock the Matter while validating and applying their effects. A failed request does not leave a partial observation, balance, lifecycle, readiness, or audit change.
Support correlation
When contacting support, include:X-Request-Id- Environment
- Route template and HTTP method
- UTC timestamp
- Problem
type,status, and fieldcodevalues - The
etagyou wrote against, for a412you cannot explain