> ## Documentation Index
> Fetch the complete documentation index at: https://surf-dcinside-api.kr.ask.surf/llms.txt
> Use this file to discover all available pages before exploring further.

# Errors and Recovery

> Current error handling, proposed recovery rules and rehearsal gaps

## Error body

Errors use an `error` object containing a machine-readable `code`, a `message` and optional field details (`path`, `problem`). The implementation may return the first failing semantic check; it does not guarantee a complete list of every problem in one response.

## Handling responses

| Status | Meaning and action |
| - | - |
| 400 | Malformed JSON or request-schema failure. Inspect and fix the payload. |
| 401 | Missing or unknown API key. Confirm the environment and credential. |
| 404 | No completed response is stored for that cycle. Completed responses survive restarts, but a receipt can exist without one after an inference failure; replay the unchanged request before concluding it was never accepted. |
| 409 | An existing cycle ID or weights version was reused with a different body. Recover the original result or correct the request; do not overwrite it. |
| 413 | Body exceeds an implementation size protection. Arrange a limit change or batch protocol; do not discard candidates. |
| 415 | Unsupported image content type. The proposed image route accepts JPEG. |
| 422 | Semantic validation failed, such as a cycle time more than 60 seconds ahead of server time or a cycle ID that does not match its timestamp. Inspect the error body. |
| 408, 429, 500, 502, 503, 504 | Potentially transient; the supplied client supports bounded retries. Preserve the cycle ID and body, and stay within 60 seconds from sending, including at most one retry. Honor `Retry-After` if provided. |

Per-endpoint `403` scope checks and a rate-limiter returning `429` are not currently implemented by the API. Their presence in earlier documentation did not establish that they were active. Repeated candidates and removals are not rejected: identity is `gall_id` plus `post_no`, a repeat is stored and counted once, and a retry cannot revive a removed post.

## Late responses and undelivered data

DCinside skips late or stale scores for that decision cycle. This is separate from reliable delivery: preserve unacknowledged candidates, images and removals until they can be reconciled. The next request's current engagement alone cannot recover missing candidate metadata.

After an uncertain timeout, retrieve the stored response or replay the original request with the same ID and body. If no completed result is found, include that cycle's candidates and removals again in the next cycle, as described in [Conventions](/conventions#retries-and-recovery). Verify restart recovery in the deployed environment. An HTTP `500` does not itself prove an alert was sent; no-data alert delivery is a separate rehearsal check.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.