Potential candidates — dev harness
CRUD harness for the PC1 schema + PC3 refresh-schedule management. Use this to test the region gate (any state ≠ TAS/VIC/NSW → 400), the upsert + overlay-preservation flow, the per-row staleness pill, and the daily refresh scheduler.
You need to sign in as an administrator to view this page.
Bright Data sample mode (e2e / dev)
When ON, the BD3/BD4 fetch lambdas short-circuit to synthesised records (no live Bright Data call, no cost). Leave OFF in prod.
{}Add by URL (BD4 scraper)
POSTs to /api/admin/potential-candidates/from-url.
In sample mode, a synthesised record is upserted to PC1 using
the URL's slug as linkedin_id.
{}Save (upsert)
{}Fetch one (GET by linkedin_id)
{}Source-of-data audit (CO1)
{}List by state (GET /?state=)
{}PC3 — refresh schedule + staleness (per row)
Lists the PCs returned by the most-recent "List by state" call. Each row shows a
staleness pill derived from lastSeenAt, plus a dropdown to PATCH the
refreshSchedule field (None / Weekly / Monthly). Use "Refresh now" to
kick the PC3 scheduler lambda synchronously (test-only path).
{}| linkedin_id | name | lastSeenAt | Staleness | Refresh schedule | nextRefreshDue |
|---|
Soft-delete (CO2 right-to-delete)
{}Opt-out / permanent delete (SF6 right-to-be-forgotten)
A persistent opt-out stub will be retained to prevent re-import. No personal data will be kept.
{}