Power job alert emails and notifications with a continuously updated job feed
Job alerts are one of the highest-value features on any job board or career product — users who set alerts are far more engaged than those who don't. Building them well means pulling only new listings since the last notification run, filtering precisely to match user preferences, and doing it efficiently at scale. CleanJobData's created_max_age filter is built for exactly this: run your alert job every hour or every day with created_max_age set to your interval (created_max_age=1h for an hourly job, created_max_age=1d for daily), match the results against user preferences, and send. How soon a new job can reach an alert depends on your plan: on Pro and Enterprise, it's available as soon as we index it; on Starter, it's available 24 hours after indexing, so Starter suits daily digests better than hourly alerts.
Run real queries in the playground without a key, or start a 14-day free trial with 300 requests a day. No card required.
There are two freshness fields: published is when the employer originally posted the role, and the ingestion time is when CleanJobData indexed it — a job can have an older published date but only just have finished processing and appeared in the index. For alerts, filter on the ingestion side with created_max_age, sized to your run interval: created_max_age=1d for a daily job, created_max_age=1h for hourly. That way a listing lands in your alert on the first run where it's visible to you, regardless of its published date. Dedupe by job id against what you've already sent, since the window can overlap slightly between runs. /guides/syncing-job-data-in-depth explains the difference in detail.
On Trial, Pro and Enterprise, new jobs are visible as soon as we index them. On Starter, they appear 24 hours after we index them. After that, it's as fast as your schedule: an hourly job on Pro picks a new listing up within the hour after we index it. On Starter, plan for daily alerts and expect each job to arrive about a day after we first indexed it.
Yes — each query can combine any set of filters. For large user bases, group users with identical preferences and run one query per group rather than one per user. That keeps your request volume manageable without sacrificing precision. /guides/choosing-filters-for-your-use-case covers which filters to use for alerts.
Every listing has a stable ID. Store the IDs you've already notified users about and check incoming results against that set before sending — this matters more than it might seem, since a created_max_age window sized with a safety margin will overlap slightly with your previous run and re-return a few listings you already sent. For duplicates across different sources, see /articles/deduplicating-job-listings-across-sources.
Yes — the salary min, max, and currency fields are returned on every listing where the employer provides them, in the employer's own currency. You can filter to only alert users when a role includes salary data above a threshold, or include the salary in the alert when available.
