Binding failed

Identifiers

Field	Value
Type URI	https://echo.labstack.com/pro/problems/binding-failed
Code	binding_failed
HTTP status	400

HTTP status	English title
400	Bad Request

When it occurs

The application’s request binding, such as c.Bind, could not decode the request. The application uses this code only for a known binder failure. It does not disclose the parse error.

Client handling

Send a well-formed body and parameters in the format the API documents. Sending the same request again gives the same result.

Example response

If your application installs a custom handler, the body may differ.

HTTP/1.1 400 Bad Request
Content-Type: application/problem+json

{
  "code": "binding_failed",
  "status": 400,
  "title": "Bad Request",
  "type": "https://echo.labstack.com/pro/problems/binding-failed"
}

Server correction

Check the binder’s error in sanitized server logs. Keep the documented body and parameter formats aligned with the binder.

Response fields

Your application (problem.NewError)

• type (string, always): The exact type URI above.
• title (string, always): The catalog title in the rendered language: English by default, Japanese only when the application selects it.
• status (integer, always): The HTTP status of the response.
• code (string, always): The stable code above.
• detail (string, optional): Display text that your application sets, up to 256 bytes with problem.NewError. Omitted when you set none.

Headers:

• Cache-Control (conditional): no-store, set by problem/echoadapter.
• Content-Language (conditional): en or ja, set by problem/echoadapter from its configured language.

Notes:

• The adapter keeps existing WWW-Authenticate, Allow and Retry-After headers and adds no challenge or retry advice of its own.
• On HEAD, the adapter’s Content-Length equals the GET body’s length.

Related behavior

See the problem catalog for application error handling.