Guides
Error Handling
Every error response from the API uses a standard ErrorResponse
envelope. All error responses include a JSON body with diagnostic
information.
Error Response Format
Code
| Field | Type | Description |
|---|---|---|
title | string | Short human-readable summary |
status | int | HTTP status code |
detail | string | Human-readable explanation specific to this occurrence |
errorCode | string | Machine-readable error code for programmatic handling |
errors | ValidationError[] | One entry per failed validation rule (field, message, code) |
source | string | Where the error originated (e.g. "Application", "Infrastructure") |
timestamp | string | ISO 8601 timestamp when the error occurred |
instance | string | URI reference for the specific occurrence |
extensions | object | Additional context-specific data |
HTTP Status Codes
| Status | Meaning |
|---|---|
400 | Bad request — validation failure or invalid input |
404 | Not found — resource does not exist |
409 | Conflict — operation conflicts with current state (e.g., file locked) |
500 | Server error — unexpected internal failure |
Handling Errors in SDK Clients
The SDK raises a typed ErrorResponse exception that carries the
fields from the JSON body — Status, Title, Detail, ErrorCode,
Errors, and more. Catch it directly so you can inspect the structured
error rather than relying on the generic exception message:
ErrorResponse inherits from Kiota's base ApiException (C#) /
APIError (Python), so you can still catch the broader type if you
need to handle transport errors (network drops, timeouts) the same way.
Last modified on

