The short answer
JobSpy is a job-listing scraper. Plan separately for data quality, source failures, candidate identity, and any employer submission your product offers.
Run a small discovery sample first
The official JobSpy repository documents installation as python-jobspy and a scrape_jobs function that returns a dataframe. Start with a small query, inspect the result and source URL fields, and record which version and options you used. Follow the source sites' applicable access rules.
Do not interpret an empty dataframe as proof that no openings exist. The library's documentation describes source errors, ignored options, and blocked requests. Capture those diagnostics alongside the result so a product can distinguish no matches from a failed source.
# pip install -U python-jobspy
from jobspy import scrape_jobs
jobs = scrape_jobs(
site_name=["indeed"],
search_term="software engineer",
location="Chicago, IL",
results_wanted=10,
country_indeed="USA",
)
print(jobs.head())
print(jobs.attrs.get("errors", {}))
print(jobs.attrs.get("warnings", {}))Normalize records without losing the source
Store the source URL, direct employer URL when available, title, company, location, and retrieval time. Keep raw source identity separate from your own normalized job ID. A company can legitimately advertise similar roles in several locations, so deduplication needs more than title equality.
Treat absent salary values as unknown. If data is parsed from a description, keep that provenance distinct from an explicit employer field. Do not make your matching system silently turn missing pay into zero or a remote flag into permission to work from any country.
Compare a scraper and a hosted API fairly
A local scraper gives you code-level control and may suit experimentation. You also own its runtime, updates, failure handling, and observation of source behavior. A hosted API moves some operations to a provider but introduces its own coverage, pricing, and rate-limit contract.
Compare on a representative sample of the locations and roles you need. Measure useful, current, unique records rather than raw row counts. Test pagination and failed-source behavior before assuming a small successful request represents production reliability.
Connect discovery to an application workflow
A discovered URL is not a submitted application. If you use Apply Guy, verify the actual employer URL, its supported ATS, and US scope. Create or select the authorized candidate, choose documents for this application, and run preflight before creating a submission.
Keep the application ID and original discovery record together. Expose queued, running, answer-required, and terminal outcomes accurately in your UI. If a target is unsupported, offer the employer's direct application path instead of claiming that a scraper result guarantees submission support.
Sources and further reading
Provider and employer requirements can change. Follow the instructions for the particular application or integration.