Signal failures are now returned in the response body

The Signals API now returns HTTP 200 for any signal it can retrieve — including failed ones — and conveys failure in the response body instead of an error status code.

What changed

• GET and POST /v1/companies/signals (and /:id), and the contacts equivalents, now return HTTP 200 whenever the signal is retrievable, regardless of its processing state.
• A failed signal is reported in the body as status: "failed" together with a new retryable boolean:
  • retryable: true — transient failure; the request may succeed if retried (previously surfaced as HTTP 500).
  • retryable: false — non-retryable failure such as validation or a rate limit; do not retry (previously surfaced as HTTP 422).
• Failed signals no longer return 422 or 500. Genuine request errors — malformed body, bad input, authentication, or not-found — still return their normal 400, 401, 404, and 422 codes.

{
  "id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "status": "failed",
  "retryable": false,
  "error": "LinkedIn data is currently unavailable due to rate limits.",
  "errorCode": "LINKEDIN_RATE_LIMIT_EXCEEDED"
}

Who is affected

Developers and RevOps teams that call the Signals API directly and branch on the HTTP status code to detect failed signals.

Customer action

If your integration treats a 422 or 500 from a signal endpoint as a signal failure, update it to:

1. Treat a 200 as a successful retrieval of the signal, then inspect body.status.
2. When body.status is "failed", read body.retryable to decide whether to retry: retry only when retryable is true, using your existing backoff.
3. Continue to handle 400, 401, 404, and 422 as genuine request errors — these are unchanged.

This is a single coordinated cut with no backward-compatibility shim, so make the change before relying on the new behavior.

Learn more

• Company Signals
• Contact Signals
• Rate Limits
• API Reference