PPactDocs
Enrichment

Schedules

Define recurring, cron-style enrichment sweeps over a saved target query with per-run target and cost caps — and how they relate to Pact's live per-record refresh.

Recurring enrichment sweeps

A schedule is a saved, cron-style plan for continuous enrichment: a target query, a level (or enrichment types), a cadence, and per-run guardrails. Instead of kicking off a batch by hand, you describe "re-enrich my active-pipeline accounts every Monday, at most 1,000 records, capped at $50 per run" once.

Schedules are stored in the enrichment_schedules table (alembic 0049), scoped to your tenant.

Schedule shape

FieldMeaning
target_queryThe saved query selecting records to enrich
level / enrichment_typesHow deep to enrich
cron_exprCadence, cron syntax
next_run_at, last_run_at, last_run_idScheduling state
max_targets_per_runCap on records per sweep (default 1,000)
max_cost_per_run_centsOptional per-run spend ceiling
activeToggle without deleting

Managing schedules

EndpointPurpose
GET /v1/enrichment/schedulesList active schedules
POST /v1/enrichment/schedulesCreate a schedule
PATCH /v1/enrichment/schedules/{id}Update cadence, caps, or active
bash
curl -X POST https://api.pact.place/v1/enrichment/schedules \
  -H "Authorization: Bearer $PACT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Weekly refresh — active pipeline",
    "target_query": {"segment": "active_pipeline"},
    "level": "L2",
    "cron_expr": "0 9 * * 1",
    "next_run_at": "2026-07-28T09:00:00",
    "max_targets_per_run": 1000,
    "max_cost_per_run_cents": 5000
  }'

Definitions are live; the tenant-wide execution loop is not yet wired

The enrichment_schedules table and its CRUD API are fully implemented — you can create, list, and manage schedule definitions today. What is not yet wired is a background worker that ticks due enrichment_schedules rows and launches runs from them, so a stored schedule does not yet fire on its own. Pact's shipping recurring-enrichment loop runs on a different surface: per-record live subscriptions (enrichment_live_subscriptions, driven by core.enrichment.live_subscriptions pick_due / run_pending, wired to a real worker in api/worker_bootstrap.py), which refresh individual records on a cadence with auto-pause on repeated failure. Treat schedule definitions as roadmap plumbing for tenant-wide sweeps until the tick worker lands; use live subscriptions for automated refresh you can rely on now.