FBI Wanted Scraper: Public Notices & Rewards
Pricing
Pay per usage
Go to Apify Store
FBI Wanted Scraper: Public Notices & Rewards
Pull public FBI Wanted and Seeking Information notices via the official FBI API: subject, field office, reward and publication date. No login, no proxy, no browser.
Pricing
Pay per usage
Rating
0.0
(0)
Developer
Naimur Hasan
Maintained by CommunityActor stats
0
Bookmarked
2
Total users
1
Monthly active users
a day ago
Last modified
Categories
Share
FBI Wanted Scraper
Pulls public Wanted and Seeking Information notices from the FBI's official public API. No login, no proxy, no browser.
Input
| Field | Type | Notes |
|---|---|---|
titleContains | string | Filter by notice title. Omit to walk the most recent notices. |
fieldOffice | string | Filter by field office, lowercase, e.g. baltimore. Omit for all. |
maxItems | integer | Cap on notices returned. Default 20. |
Output
One row per notice: uid, title, description, subjects,
fieldOffices, personClassification, posterClassification, status,
rewardText, caution, nationality, publication, modified,
imageCount, url.
Notes
- This is the FBI's own published open data, intended for public redistribution; every record links back to its canonical fbi.gov page.
- Most fields are nullable and frequently null — a "Seeking Information" notice about a victim carries none of the physical description fields a wanted-fugitive notice does. That is the shape of the source, not a mapping gap.
- Descriptions embed literal
\r\nruns; they are collapsed to single spaces so the text is usable in a table or CSV. imagesupstream is an array of image objects, reduced here to animageCount— the full array is rarely wanted in a row.- Two separate things make this endpoint 403 from Node, and both are handled:
requests with no
User-Agentare rejected outright (Node'sfetchsends none by default, while curl does — which makes it easy to misdiagnose), and even with one set, the first request on a fresh connection is challenged and answered 403 before later requests succeed. Since every Actor run is a fresh container, that first-request 403 would otherwise fail every single run, so retryable statuses are retried with a short backoff.
