# CLIENT_USER_AGENT_INVALID

# CLIENT_USER_AGENT_INVALID

`client.userAgent` is present but unusable.

## Summary

| Field | Value |
|---|---|
| HTTP status | `400` |
| `errorCategory` | `validation` |
| `retryable` | `false` |

## When This Fires

- **`POST /v1/marketfront/orders/validate`**
- **`POST /v1/marketfront/orders/place`**

…when `client.userAgent` exceeds 512 characters.

A blank or whitespace-only value is reported as [`CLIENT_CONTEXT_REQUIRED`](/errors/CLIENT_CONTEXT_REQUIRED) instead — from the contract's point of view it is a missing field, not a malformed one.

## Recommended Action

Send the customer's `User-Agent` header verbatim, from the request your own front end received:

```jsonc
{
  "client": {
    "ip": "203.0.113.7",
    "userAgent": "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0 Safari/537.36"
  }
}
```

Do not substitute your own service's user agent, and do not synthesise a browser string for a non-browser channel. The value is forwarded to the commerce partner's anti-fraud layer; a value that misdescribes the channel is worse there than one that is plainly not a browser. If your integration is not a web checkout, send a stable, honest identifier for it.

Real user-agent strings sit far below the 512-character bound. Hitting it usually means a concatenated list of values rather than a single header.

## Example

```json
{
  "type": "https://developer.gett-tech.com/errors/CLIENT_USER_AGENT_INVALID",
  "title": "Bad Request",
  "status": 400,
  "detail": "client.userAgent is too long. Supply the end user's User-Agent header value, up to 512 characters.",
  "instance": "/v1/marketfront/orders/validate",
  "requestId": "req_abc123",
  "timestamp": "2026-08-10T14:30:00.000Z",
  "errorCode": "CLIENT_USER_AGENT_INVALID",
  "errorCategory": "validation",
  "retryable": false
}
```