# Address cannot be scored

<!-- GENERATED by gateway/scripts/generate-error-docs.mjs — DO NOT EDIT. This page renders gateway/contracts/errors.json; edit the catalogue and regenerate. -->

| | |
| --- | --- |
| HTTP status | `422` |
| Type | `https://docs.investorliftdata.com/errors/unscorable-address` |
| Retryable | No |
| Retry-After header | No |

## What the body says

This error refunds, so its wording depends on whether the Refund had already been
applied when the response was built (it may only claim what the Ledger recorded):

When the Refund is confirmed:

> The submitted address could not be scored. The Credit for this call has been returned to the Account as a Refund.

When the Refund is pending:

> The submitted address could not be scored. A Refund of the Credit for this call is pending and will be applied to the Account.

## What happened to the Credits

The call was charged when it started, and the Credit comes back: the response states whether the Refund has been applied to the Account or is pending.

## Retrying

**Not retryable.** Sending the same request again returns the same error. Change the request as the detail directs before sending it again.

## Body members

None. The body carries exactly the base members: `type`, `title`, `detail`, `status` and `trace_id`.

## Retry-After

No. This response carries no `Retry-After` header.

Every error response is an RFC 9457 Problem Detail sent as `application/problem+json`,
and every response carries a `trace-id` header, repeated in the body as `trace_id`.
The Trace ID is the only handle support needs to find your call.