---
title: "Recompute Signals"
method: POST
path: "/api/v1/pipeline/recompute-signals"
tags: ["pipeline"]
---

# Recompute Signals

`POST /api/v1/pipeline/recompute-signals`

## Request

- Base URL: `https://app.goodleads.club` (the document declares no server; this is the origin it was published from)
- URL: `https://app.goodleads.club/api/v1/pipeline/recompute-signals`
- Auth: API key in header `X-API-Key`

Force-recompute RA Intelligence, Contact Relevance, and/or Classification on a scope.

ADR-004 Phase 3 surface. Runs inline — for targeted recomputes (typically
1–200 entities after an operator/agent change). Whole-state recomputes
should go through the normal pipeline trigger with filters.

Bypasses the ADR-004 Phase 1 skip-if-current filter so entities already
stamped at the current service version still get recomputed. That's the
whole point — the operator has reason to distrust the current stamp and
wants the service to run anew.

`service="classify"` exists because the classification service VERSION
(classification_v1) has never been bumped by a keyword/taxonomy batch —
shipping a new keyword does not, by itself, retroactively reclassify any
entity that was already stamped (including ones stamped "unclassified").
This is the small-batch path to actually apply a shipped keyword/taxonomy
change to the specific records it should have caught, without a
whole-state pipeline run.

## Request body

- RecomputeSignalsRequest: ADR-004 Phase 3 request shape. `service` selects the IP service(s) to recompute. `entity_ids` is **required** — this endpoint is for targeted recomputes only. Whole-state recomputes go through the pipeline trigger endpoint with filters, or through the CLI (`python -m backend.services.ra_intelligence_service --state CO --force-recompute`). No hard count cap. If an ALB/proxy timeout hits mid-request, the service's session rollback-on-exception (ra_intelligence_service.py and contact_relevance.py `except/rollback` blocks) guarantees no partial writes — the caller just sees a 504 and can retry with a smaller batch. API worker saturation (if it ever becomes a real problem) is a rate-limiting concern, not a per-request bound.
  - `service` string, required
  - `state` string, required
  - `entity_ids` string[], required
  - `force` boolean
  - `dry_run` boolean

## Response `200`

Successful Response

- RecomputeSignalsResponse
  - `service` string, required
  - `state` string, required
  - `ra_intelligence` object, nullable
  - `contact_relevance` object, nullable
  - `classify` object, nullable
  - `dry_run` boolean, required

## Other responses

- `422`: Validation Error

---

[API](https://skmtc.dev/goodleads/apis/formation-gtm-api.md) · [All operations](https://skmtc.dev/goodleads/apis/formation-gtm-api/llms.txt) · [OpenAPI document](https://skmtc.dev/goodleads/apis/formation-gtm-api/revisions/2068d13a82cf?raw)