Error Handling

\<font color="#78b5c7">\</font> topic type constraint purpose explain how apis report and enforce request‑level errors audience api integrators and client developers applies to apis that return structured error responses does not apply to internal batch processing or non‑request‑based integrations error responses indicate that an api request could not be processed as submitted errors are distinct from fraud decisions and do not reflect risk outcomes errors are returned immediately and prevent the request from entering fraud evaluation or downstream processing understanding error semantics is critical for building resilient integrations error categories errors may occur due to missing or invalid required fields failed conditional dependencies authentication or hashing failures structural or formatting issues unsupported or inconsistent values each error category represents a violation of platform constraints rather than an evaluation result handling errors correctly when an error is returned the request should be reviewed and corrected the same invalid request should not be repeatedly retried errors should be treated as integration or data quality issues retry logic should only be applied after correcting the underlying cause logging and monitoring expectations clients should log error responses and monitor error rates over time persistent errors may indicate integration drift schema mismatches credential or authentication issues monitoring error patterns helps ensure continued alignment with platform constraints