[FIX] http: drop error detail from 4xx/5xx bodies (PRO-456)

docs/INTEGRATION.md

@@ -54,6 +54,8 @@ verifies on-chain. The exact bytes that are signed are built in `src/signing/`
 
 ## Errors
 
-A failure returns a status code and a short reason. Some are retryable and some
-are terminal. The codes and how they map to HTTP are in `src/error.rs` and
-`src/http.rs`.
+A failure returns a status code and a JSON body that carries the stable error
+code and nothing else. v2 returns `{ "error": "<code>" }`. v1 also repeats the
+code as `error_message`, the key old v1 clients surface. Internal detail stays
+in the server log. Some codes are retryable and some are terminal. The codes
+and how they map to HTTP are in `src/error.rs` and `src/http.rs`.

src/error.rs

@@ -9,14 +9,19 @@ use serde::Serialize;
 use thiserror::Error;
 
 /// JSON error body returned by the HTTP layer.
+///
+/// The body carries the stable error code and nothing else. Internal detail
+/// (a parse error, a configured value, an upstream message) stays in the
+/// server log. A client acts on the status and the code; a human message would
+/// only widen what the service reveals.
 #[derive(Debug, Serialize)]
 pub struct ErrorResponse {
     /// Stable, machine-readable error code (e.g. `"ct_not_found"`).
     pub error: &'static str,
-    /// Human-readable reason. Mirrors cofhe dispatcher's `error_message` field so
-    /// a dispatcher client reads the same key; falls back to the `error` code when
-    /// there's no extra detail. Safe to expose; never leaks internals.
-    pub error_message: String,
+    /// v1 only: old v1 clients surface `error_message`, so it repeats the code
+    /// there. v2 omits the key, like the dispatcher's v2 routes.
+    #[serde(skip_serializing_if = "Option::is_none")]
+    pub error_message: Option<&'static str>,
 }
 
 /// Top-level error type for the Teecryptor service.