Connect CleanJobData to Make.com to automate job data workflows without writing code.
Add CleanJobData as an HTTP module in Make.com.
Configure the HTTP module to fetch job listings.
URL: https://api.cleanjobdata.com/jobs
Method: GET
Headers: { X-API-Key: {{apiKey}} }Connect to apps like Slack, Google Sheets, or Airtable.
Real-world patterns beyond the basic setup.
A complete four-module scenario, module by module — set this up exactly as listed and it runs unattended.
1. Schedule trigger — every 15 minutes
2. HTTP > Make a request
URL: https://api.cleanjobdata.com/jobs
Method: GET
Headers: X-API-Key: {{your CleanJobData key}}
Query string: title=engineer; remote=true; created_max_age=15m
3. Iterator
Array: {{2.data}}
4. Slack > Create a Message
Channel: #new-jobs
Text: New listing: {{3.title}} at {{3.company.name}} — {{3.application_url}}Yes — set the scenario's schedule (every 15 minutes up to daily) and add `created_max_age` to the HTTP request so each run only pulls jobs ingested since the last one, e.g. `created_max_age=1h` on an hourly scenario. That filters on CleanJobData's ingestion time rather than the employer's posted date, so it won't miss listings that arrived late from a slow-crawling source.
2000+ apps. Once the HTTP module pulls jobs from CleanJobData, use the Iterator module to loop over the `data` array and route each listing wherever you need it — Google Sheets or Airtable for a spreadsheet feed, Slack for new-listing alerts, Notion for a curated board, or a webhook into your own database.
Add a Data Store module before the Slack step: check whether the job's `id` already exists in a Make Data Store, skip if it does, and add it if it doesn't (a Router with a filter on the lookup result does this in two branches). This matters more than it looks — without it, a scenario running every 15 minutes with an overlapping `created_max_age` window will re-post the same jobs it already alerted on.
Make's HTTP module surfaces the CleanJobData response as-is, including a 429 status and the `Retry-After` header. Add an Error Handler on the HTTP module with a Resume directive and a short Sleep step reading `Retry-After` from the failed bundle — this keeps a scheduled scenario from silently failing a whole run over a transient rate limit.