---
title: "Shortlist Urgency Tick"
method: POST
path: "/api/internal/cron/shortlist-urgency-tick"
tags: ["Internal Cron"]
---

# Shortlist Urgency Tick

`POST /api/internal/cron/shortlist-urgency-tick`

## Request

- Base URL: `https://api.ruzora.com` (the document declares no server; this is the origin it was published from)
- URL: `https://api.ruzora.com/api/internal/cron/shortlist-urgency-tick`
- Auth: none declared

Two TRUE urgency signals the system already knew (Epic 5.5).

1. **Availability change.** An engineer on a live, already-viewed
   shortlist moved from an available state to a departed one. The
   comparison is against the status SNAPSHOTTED when the card was
   published, so the email is about an observed transition, never
   about a state we merely noticed for the first time.
2. **Expiry renewal.** A parent token dies within three days. Day 11
   of 14: trivially true, and the buyer can verify it on day 15.

**The wave doc bans fabricated scarcity.** Nothing here counts down,
invents viewers, or names a competing offer. If neither condition
holds, the tick sends nothing, which is the common case.

Idempotent: both notices stamp their dedupe column BEFORE the send, so
a Resend outage costs one email instead of causing a re-send storm.

External GitHub Actions cron (shortlist-lifecycle-cron.yml), NOT
in-process APScheduler — interval jobs starve on ephemeral Railway
replicas (enrollment incident 2026-08-18).

## Headers

- `x-cron-token` string, nullable

## Response `200`

Successful Response

- unknown

## Other responses

- `422`: Validation Error

---

[API](https://skmtc.dev/ruzora/apis/ruzora-candidate-crm-api.md) · [All operations](https://skmtc.dev/ruzora/apis/ruzora-candidate-crm-api/llms.txt) · [OpenAPI document](https://skmtc.dev/ruzora/apis/ruzora-candidate-crm-api/revisions/f9b8223f3ac4?raw)