DEV Community: Mohamed Zaghloul

Companies that sponsored green cards for frontend developers in 2026 (free list from DOL PERM data)

Mohamed Zaghloul — Wed, 21 Oct 2026 16:34:08 +0000

If you're a frontend developer on a work visa, "does this company sponsor green cards?" is one of the hardest questions to answer from a job post. Most listings say nothing, and a recruiter's "we support visas" can mean H-1B only.

There's a better signal: the US Department of Labor publishes every PERM labor certification decision. PERM is the step most employer-sponsored green cards go through, so if a company filed PERM for a frontend role this year, it has actually done the paperwork before.

I went through the latest DOL PERM disclosure file (FY2026 Q3, decisions from Oct 1, 2025 to Jun 30, 2026) and pulled every case with a frontend-style job title (front end, frontend, front-end, UI developer, UI engineer, React developer). That's 151 cases at 103 employers. Here are the top 15.

Free sample: top 15 frontend green card sponsors (FY2026)

Employer	PERM cases	Certified	Median offered wage	Top worksite
ByteDance Inc.	17	16	$177,440	San Jose, CA
TikTok Inc.	5	5	$184,662	San Jose, CA
FMR LLC (Fidelity)	4	4	$161,363	Westlake, TX
U.S. Bank National Association	4	4	$142,522	Irving, TX
IBM Corporation	3	3	$153,807	San Jose, CA
Interglobe IT LLC	3	3	$105,997	Irving, TX
Milwaukee Electric Tool Corporation	3	3	$100,500	Brookfield, WI
Snap Finance, LLC.	3	3	$120,000	West Valley City, UT
TruStartIT LLC	3	3	$87,610	Richardson, TX
Advantis Global, LLC	2	2	$164,320	Mill Valley, CA
Apptegy, Inc.	2	2	$62,920	Little Rock, AR
AvidXchange, Inc.	2	2	$144,900	Charlotte, NC
Barclays Services Corp.	2	2	$175,000	Whippany, NJ
LOGIWARE, INC.	2	2	$83,325	Alpharetta, GA
Purchasing Power LLC	2	2	$142,002	Atlanta, GA

Source: DOL OFLC PERM disclosure data, FY2026 Q3. Ties at 2 cases are shown in file order; more employers have 2 cases than fit here.

👉 Get the full list free: Frontend & Software Green Card Sponsors FY2026 (pay what you want, $0 is fine). It has all 103 frontend employers plus a software developer tab with the top 1,150 sponsors, as a Google Sheet and CSV files.

How to read the columns

PERM cases: how many PERM applications DOL decided for that employer with a frontend-style title in this window. It counts applications, not people hired.
Certified: how many DOL approved (this includes "certified-expired", meaning it was approved but the next step wasn't filed in time). Across all 151 frontend cases, 146 were certified, 3 denied and 2 withdrawn.
Median offered wage: the middle of the yearly wages the employer wrote on those applications. It's what they offered for that specific role and location, not a company-wide salary band.
Top worksite: where the job actually is. This often differs from headquarters (Fidelity is based in Boston, but most of its cases here are in Westlake, TX).

The full list also has the top job titles per employer and the date of the latest decision, which tells you how recently they filed.

How to use the list in a job search

Start with your location or the places you'd move to. Filter the sheet by worksite. A company with three cases in your city is a better lead than a famous name that only sponsored in another state.
Look at the job titles. Many cases are senior, lead or principal roles. If an employer only filed for "Principal Front End Engineer", that tells you the level they're willing to sponsor.
Check their careers page. Search for frontend, UI or React openings. Past filings don't mean they're hiring now.
Ask early, and ask the right question. "Do you sponsor H-1B?" and "Do you sponsor green cards (PERM)?" are different questions. Ask both in your first recruiter call so neither of you wastes time.
Track who said what. Once you're talking to 20+ companies, it's easy to forget which one said "case by case". I keep mine in a simple sheet (Job Application Tracker), but any spreadsheet works.

If frontend roles are too narrow for you, the software developer tab is much bigger: DOL decided 25,078 PERM cases for software developers and web developers (SOC codes 15-1252 and 15-1254) at 5,188 employers in the same window. The list covers the top 1,150 of them by case count (each with 4 or more cases, 19,254 cases in total). That's not every sponsor: the other 4,038 employers, the smaller filers, aren't in it.

Limits (please read before you rely on this)

This is PERM, not H-1B. A company can file lots of H-1Bs and few or no PERM applications, or the other way around.
Small numbers. Most frontend employers here (82 of 103) had a single case. A "100% approval rate" on 1–3 cases means very little.
Title matching isn't perfect. I matched job titles, not job descriptions. Some titles are senior or managerial, and a few aren't web work at all (Milwaukee Tool's cases are for a "Senior Concept Design Engineer – Front End Innovation", which reads like a product design role). Check the titles in the full list.
Staffing and IT consulting firms appear. Some employers place workers at client sites. That's a legitimate route for some people, but it's a different job than working in-house, so look them up.
Past filings don't promise future sponsorship. Budgets, policies and headcount change.
The data lags. DOL publishes disclosure files quarterly, and this one ends on Jun 30, 2026. Cases decided since then aren't in it yet. The raw files are public on the DOL FLAG site.
Not legal advice. For your own case, talk to an immigration attorney.

I left employer tax IDs out of the list on purpose. Everything else comes straight from the public DOL file.

For developers: pull your own fresh list

If you'd rather query the data yourself, by job title, city or salary, I published the tool I used to build this list: PERM Green Card Sponsors on Apify. It reads the DOL disclosure files directly and groups cases by employer. Most job seekers won't need it; the sheet is easier.

Get the full list

The free sample above is 15 of 103 frontend sponsors. Download the full Frontend & Software Green Card Sponsors FY2026 list: pay what you want, including $0.

If you spot an employer that's mislabeled or a mistake in the numbers, tell me in the comments and I'll fix it.

How to find government RFPs in 549 city/county portals for free

Mohamed Zaghloul — Mon, 19 Oct 2026 19:42:29 +0000

If you sell to local government (IT services, construction, janitorial, consulting), you know the annoying part of the job isn't writing the proposal. It's finding the bid in time. Every city, county, school district and transit agency posts RFPs on its own portal, and paid bid-alert services that watch them for you typically run $49 to $149 a month.

A big chunk of those agencies use the same e-procurement platform, OpenGov Procurement. Right now its public agency directory lists 549 active agencies across the US (127 in California, 93 in Florida, 49 in Arizona, 44 in Texas...). So I built an independent Apify Actor that checks all of them for you: OpenGov Procurement Bids Scraper.

Try it free: open the Florida software/IT bids example and press Start. Apify's free plan includes $5 of platform usage every month and doesn't need a credit card, which covers about 2,500 bids at this Actor's price.

This post walks through two real runs I did today: what goes in, what comes out, how the "only new bids" mode works, and what it costs.

What makes it different

Scan a whole state in one run. Put "FL" in states and every active OpenGov Procurement agency in Florida is checked, using OpenGov's own agency directory. No list of portal slugs to maintain.
Only-new mode for a real alert feed. With onlyNew on, each run returns only bids you haven't received yet. If an agency posts an addendum to a bid you already have, that bid comes back once with changeType: "new_addendum".
The details you actually bid with. Buyer name, title, email and phone (as the agency published them), Q&A deadline, pre-bid meeting, UNSPSC/NIGP category codes, addenda, attachment names, timeline and evaluation criteria.
$2 per 1,000 bids, details included. Other bid Actors on the Apify Store I compared charge $3 to $20 per 1,000.

Input

This is the exact input I ran:

{
  "states": ["FL"],
  "keywords": ["software", "technology", "cybersecurity", "cloud", "IT services", "data"],
  "keywordsInTitleOnly": true,
  "onlyNew": true,
  "stateKey": "devto-demo-fl-it"
}

states scans every active OpenGov agency in those states. You can also pass agencies (portal codes like pittsburghpa or full portal URLs) instead.
keywords match the start of words, case-insensitive. keywordsInTitleOnly keeps it strict, so "cloud" doesn't match "St. Cloud" in a summary.
onlyNew remembers what you already got, under the name in stateKey.

Other useful filters: dueWithinDays, postedWithinDays, excludeKeywords, solicitationTypes (e.g. "Request for Proposal"), agencyNameContains (e.g. "school", "airport") and statuses (open by default).

What happened

Run	Agencies scanned	Open bids listed	Matches returned	Runtime
First run	93	324	4 new bids	4.6 s
Re-run right after	93	324	0 (4 skipped as already seen)	5.0 s

Both ran at 256 MB, and peak memory was about 60 MB. The four Florida matches:

Agency	Bid	Type
City of Clermont	Cloud Based Location Intelligence Foot Traffic Data Platform	Request for Proposal
City of Lakeland	Consulting Services for the Preparation of a Data Center and Large-Load Development Regulatory Framework	Request for Proposal - Standard
Jacksonville Transportation Authority	Public Engagement Web Based Software Platform	Solicitation (Attach a Document)
Putnam County School District	K-12 Master Scheduling Software, Implementation, and Support Services	Request for Proposal

That second run is the point. Schedule the same input daily and most days you get zero or a handful of records, and every one is something you haven't seen.

Output

One dataset record per bid. Here's the Clermont one, trimmed (summary shortened, 3 of 7 evaluation criteria kept):

{
  "type": "bid",
  "title": "Cloud Based Location Intelligence Foot Traffic Data Platform",
  "referenceNumber": "RFP 27-002",
  "solicitationType": "Request for Proposal",
  "status": "open",
  "agency": "City of Clermont",
  "agencyState": "FL",
  "department": "Parks and Recreation",
  "postedAt": "2026-09-10T04:00:00.000Z",
  "dueAt": "2026-11-12T19:00:00.000Z",
  "daysUntilDue": 23,
  "summary": "The City is seeking proposals from qualified firms to provide a cloud-based location intelligence and foot traffic analytics platform...",
  "url": "https://procurement.opengov.com/portal/clermontfl/projects/298812",
  "procurementContact": {
    "name": "Freddy Suarez",
    "title": "Procurement Services Director",
    "email": "fsuarez@clermontfl.org",
    "phone": "(352) 241-7350"
  },
  "preProposalMeeting": null,
  "questionsDeadline": "2026-11-04T20:00:00.000Z",
  "sealedBid": true,
  "categories": [
    { "code": "20949", "title": "Geographic Information System (GIS) Software" },
    { "code": "92005", "title": "Application, Infrastructure, Hosting and Cloud Computing Services" }
  ],
  "addendaCount": 0,
  "attachments": [
    { "title": "OpenGov Vendor Registration", "fileType": "pdf" },
    { "title": "Cost Proposal Form", "fileType": "docx" }
  ],
  "evaluationCriteria": [
    { "title": "Proposed Platform and Technical Capabilities", "weight": 30 },
    { "title": "Data Methodology and Quality", "weight": 25 },
    { "title": "Cost Proposal", "weight": 10 }
  ],
  "changeType": "new"
}

The contact shown is the buyer's published work contact on the public bid page. If an agency hides its contact, the field stays empty. The Lakeland bid in the same run came back with 5 addenda, 8 attachment names and 9 category codes. Note its deadline was the same afternoon, which is exactly why a daily check beats a weekly one.

Every run also writes a RUN_SUMMARY record (agencies scanned, bids listed, matched, skipped as already seen, errors), so you can tell "nothing new" apart from "something broke".

Turn it into a daily bid alert

Everything below is built into Apify; nothing extra to install:

Open the Actor, paste your input and click Save as a new task.
On the task, add a Schedule (for example, every weekday at 7 AM in your time zone).
Under Integrations, pick where results go: Slack, Gmail or Google Drive are native options, or use a webhook, n8n, Make or Zapier to push new bids into a CRM or a spreadsheet.

Because onlyNew is on, each scheduled run sends only new bids and new addenda, not the same list every morning. For a California construction version, see the daily CA construction alert example.

What it costs

It's pay-per-result:

$2.00 per 1,000 bids ($0.002 a bid), details included, plus a $0.00005 start fee per run
Agencies with no matching bids add nothing to the bill
A re-run with nothing new costs only the start fee

My first run above (4 bids) cost about $0.008. A daily Florida IT alert with a few new bids a week stays well under the $5 monthly credit on Apify's free plan. You can also set a max cost per run, and the Actor stops cleanly when it reaches it.

Honest limits

It's an independent tool, not made by or affiliated with OpenGov.
It covers agencies on OpenGov Procurement only. Lots of agencies use other portals (Bonfire, PlanetBids, BidNet, state systems), and those aren't in here. 549 agencies is a big slice of US local government, not all of it.
It returns notice details with a link back to each bid on the agency's portal. It doesn't download the bid documents: you get attachment titles and file types, and you download the files (and register to respond) on the agency's own page.
Keyword matching is simple word-start matching. Good keywords and excludeKeywords matter more than anything else for useful results.

Try it

Store page: OpenGov Procurement Bids Scraper
One-click example: Florida software and IT bids
Free to try on Apify's free plan ($5 of monthly credit, no credit card)

It's new, so I'd really like feedback. If a field you need when bidding is missing, or a keyword setup gives you noise, tell me in the comments or open an issue on the Actor page.

Every ID on this invoice is valid. Here's why you shouldn't pay it (MCP payee check)

Mohamed Zaghloul — Mon, 19 Oct 2026 16:30:23 +0000

Every number on this invoice is valid. You still shouldn't pay it.

Here's an invoice from a German supplier: German VAT number, German BIC, and an IBAN that passes its mod-97 checksum. A normal IBAN or VAT validator will say all three are valid. But that IBAN belongs to a Dutch bank, so the invoice is asking you to pay a German supplier into a Dutch account. That's what changed-bank-details fraud usually looks like: a real supplier, real-looking IDs, and an account that doesn't fit.

I added a tool to my invoice validator MCP server that checks for exactly this. It's called check_invoice_payee, and it returns one verdict: pay, review or hold. Here's what it gives back for that invoice. This is real output from the free demo endpoint, trimmed for length:

{
  "verdict": "hold",
  "risk_score": 90,
  "summary": "Hold payment: BIC is from DE but the IBAN is from NL: the two don't belong to the same bank account; Supplier is in DE but wants payment to a NL bank account: the classic changed-bank-details fraud pattern. Confirm by phone using a known number.",
  "reasons": [
    { "code": "bic_iban_country_mismatch", "severity": "high",
      "message": "BIC is from DE but the IBAN is from NL: the two don't belong to the same bank account" },
    { "code": "iban_country_differs_from_supplier", "severity": "high",
      "message": "Supplier is in DE but wants payment to a NL bank account: the classic changed-bank-details fraud pattern. Confirm by phone using a known number" }
  ],
  "checks": {
    "iban": { "valid": true, "country": "NL", "sepa": true, "formatted": "NL91 ABNA 0417 1643 00", "bank_code": "ABNA" },
    "bic":  { "valid": false, "country": "DE", "bank_code": "COBA", "matches_iban_country": false,
              "errors": ["country_mismatch_with_iban"] },
    "vat":  { "valid": true, "kind": "eu_vat", "country": "DE", "number": "DE136695976" }
  }
}

Look at checks.iban.valid: it's true. A per-field validator stops there. What matters is comparing the fields against each other.

Swap in a German IBAN (DE89370400440532013000) and keep everything else the same, and you get:

{"verdict":"pay","risk_score":0,"summary":"All identifiers are valid and consistent with each other. OK to pay.","reasons":[]}

What it cross-checks

You send whatever the invoice has (iban, bic, vat, ein), plus supplier_country, and optionally supplier_name, currency and live. It then checks:

IBAN vs supplier country. A German supplier asking to be paid into a Dutch or Lithuanian account gets flagged.
BIC vs IBAN. Both have to point at the same country, or they can't be the same account.
VAT ownership. With live: true, the company name EU VIES has on file is compared with supplier_name.
The smaller stuff: unregistered VAT numbers, test BICs, and EUR invoices paid into non-SEPA accounts.

Each problem comes back as a reasons[] entry with a machine-readable code and a plain-English message, so an agent can act on it and a person can read it.

What it doesn't do: it checks formats, checksums, how the IDs relate to each other, and (with live) VIES. It can't prove a bank account belongs to a particular company. Nothing short of the bank can. A hold means "call the supplier on a number you already have", not "this is fraud".

Add it to Claude Desktop or Cursor

The server is hosted (remote, Streamable HTTP), so there's nothing to install. For the free demo (10 tool calls per IP per day, no key), add this to your MCP config:

{
  "mcpServers": {
    "invoice-validator": {
      "url": "https://invoice-validator.mohamed-bahaa53000.workers.dev/demo/mcp"
    }
  }
}

In Cursor that goes in ~/.cursor/mcp.json. In Claude (desktop or web), go to Settings → Connectors → Add custom connector and paste the URL. If your client only supports stdio servers, including Claude Desktop's claude_desktop_config.json, bridge it with mcp-remote:

{
  "mcpServers": {
    "invoice-validator": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://invoice-validator.mohamed-bahaa53000.workers.dev/demo/mcp"]
    }
  }
}

Then just ask: "Check this payee before I pay it: supplier in Germany, IBAN NL91ABNA0417164300, BIC COBADEFFXXX, VAT DE136695976." The model calls check_invoice_payee and you get the verdict and the reasons.

For production use, the same server runs behind RapidAPI (the free Basic plan gives 100 requests a month):

{
  "mcpServers": {
    "invoice-validator": {
      "url": "https://invoice-payment-id-validator.p.rapidapi.com/mcp",
      "headers": {
        "X-RapidAPI-Key": "YOUR_RAPIDAPI_KEY",
        "X-RapidAPI-Host": "invoice-payment-id-validator.p.rapidapi.com"
      }
    }
  }
}

Or just call it over plain HTTP

curl -X POST https://invoice-validator.mohamed-bahaa53000.workers.dev/demo/v1/payee-check \
  -H 'content-type: application/json' \
  -d '{"supplier_country":"DE","supplier_name":"Muster GmbH","iban":"NL91ABNA0417164300","bic":"COBADEFFXXX","vat":"DE136695976","currency":"EUR"}'

The paid route is POST /v1/payee-check on the RapidAPI host. The server also has single-ID tools (validate_iban, validate_bic, validate_eu_vat, validate_gb_vat, validate_ein) for when you only need one check.

Docs and the MCP Registry manifest are at github.com/Mowaah/invoice-validator-mcp. A simple rule for an accounts-payable agent: auto-pay only on pay, send review to a person, and never pay on hold until someone has phoned the supplier.

If you'd rather click than code, there's a free IBAN & VAT checker in the browser, and I'll also set the whole invoice-triage workflow up in your n8n for $149.

I built a $3 Google Sheet that tracks every job application from Gmail automatically

Mohamed Zaghloul — Mon, 19 Oct 2026 14:31:24 +0000

If you're applying to a lot of jobs, you know the problem: by application #60 you can't remember who you applied to, who rejected you, and who just went quiet. Spreadsheets help until you stop updating them, which for me was about day three.

So I built a Google Sheet that fills itself in from Gmail.

Sample data: every company in these screenshots is fictional.

What it does

You make a copy of the sheet, click Job Tracker → Set up once, and allow Gmail access. From then on:

It reads the last 180 days of email and adds one row per application: company, role, date applied, status, and a link back to the email.
It checks again every morning on its own.
Statuses update when the next email arrives: Applied → Assessment → Interview → Offer / Rejected. Statuses only move forward, so an old "thanks for applying" never overwrites a rejection.
Anything still "Applied" after 21 days with no reply gets flagged Ghosted (you can change the number).
A Notes column the scan never touches.
Job-alert newsletters ("jobs you may like", "X is hiring") are ignored.

The dashboard

Totals by status, response rate, how many reached an assessment or interview, ghosted count, and applications per week.

How it recognises emails

It's rule-based, not AI. It knows the confirmation and status emails from Greenhouse, Lever, Workday, Ashby, SmartRecruiters, iCIMS, Workable, BambooHR, JazzHR, Breezy, Rippling, Dover, Wellfound, LinkedIn Easy Apply and Indeed, plus everyday phrases like "thank you for applying" and "we have decided to move forward with other candidates".

I tested it on a real inbox with 200+ applications. On my labelled test emails, it got the status and company name right about 9 in 10 times, and it flagged zero newsletters or alerts as applications. The misses are mostly recruiters writing in their own words; those take a quick manual edit, or you can add a phrase in Settings → Extra keywords and hit Scan now.

Privacy

Everything runs inside your own Google account as an Apps Script attached to your copy. No AI, no API keys, no outside servers, no browser extension, no subscription. Gmail access is read-only: it never sends, changes or deletes email. You can turn the daily scan off from the menu, or remove access completely at myaccount.google.com/permissions.

Setup tips (2 minutes)

Open your copy in the Google account that gets your job emails.
Click Job Tracker → Set up (run this first).
Google will say it "hasn't verified this app". That's because the script lives in your copy, not on a public server. Click Advanced → Go to Job Application Tracker.
On the permissions screen, tick Select all, then Continue.
If nothing seems to happen after allowing, click Job Tracker → Set up once more. Google sometimes only authorizes on the first click.
Big inboxes fill in chunks; the scan picks up again by itself about a minute later.

Honest limits

Gmail only, English emails only.
Rule-based, so roughly 1 in 10 emails needs a manual fix.
Recruiter emails written from scratch may not be recognised.

Get it

It's a one-time payment, pay what you want from $3 (suggested $5), with no monthly plan, unlike most tracker apps. You get the copy link right after checkout:

👉 Job Application Tracker on Gumroad

If you're in the middle of a job search, good luck out there. Questions, bugs, or an ATS it doesn't recognise? Drop a comment and I'll add it.

How to find visa sponsorship jobs automatically (Greenhouse, Lever and Workday boards)

Mohamed Zaghloul — Sun, 18 Oct 2026 22:53:46 +0000

If you're job hunting on an H-1B, OPT, STEM OPT or TN, you know the routine. You find a role that fits, read the whole posting, get excited, and then see the last paragraph: "We are unable to sponsor visas for this position." Or "Applicant must be a U.S. person under ITAR." Do that fifty times a week and it eats hours.

When a company won't sponsor, that sentence is usually right there in the job description. So I built a scraper that reads it for you. This post shows how to pull jobs straight from company job boards (Greenhouse, Lever, Workday and more), flag the work-authorization wording on every posting, and drop the dead ends automatically. All the numbers below come from real runs I did on Oct 18, 2026.

Try it free: ATS Jobs Scraper on the Apify Store. Apify's free plan includes $5 of usage credit every month, no credit card. At $0.001 per job, that's roughly 5,000 jobs a month. There's also a ready-made example for a Workday career site you can run in one click.

Why company job boards, not LinkedIn

Most tech companies post jobs through an applicant tracking system (ATS): Greenhouse, Lever, Ashby, Workable, SmartRecruiters, Recruitee or Personio. Every one of these has a public job board, and most have a public JSON feed behind it. The Actor reads those feeds directly. It needs no browser and no login, and the full description comes with every job. The full description is the part you need, because that's where the sponsorship sentence lives.

What makes this different

Other job scrapers exist, so here's the honest comparison. The only AI-based visa sponsorship filter I found on the Apify Store covers Greenhouse and Workday only. None of the five most-used ATS job scrapers there flag US citizenship, ITAR or security clearance requirements.

This one adds a workAuthorization object to every job:

sponsorship: offered, not_offered, or null (the posting doesn't say)
usCitizenshipRequired
usPersonRequired (ITAR / export rules: citizen or green card)
exportControlled
securityClearance: required, preferred, or null
evidence: the exact sentences each flag came from

And two switches, excludeNoSponsorship and excludeCitizenshipOrClearance, drop matching jobs before they're saved. Dropped jobs aren't charged.

Copy-paste input (about 10 seconds)

Open the Actor, switch the Input tab to JSON, paste this and click Start:

{
  "companies": ["affirm", "spacex", "ramp"],
  "keywords": ["software engineer"],
  "maxJobsPerCompany": 10,
  "excludeNoSponsorship": true,
  "excludeCitizenshipOrClearance": true
}

My run of exactly this took 10 seconds. It saved 19 jobs and dropped 11. All 10 SpaceX software roles it checked need US-person status under ITAR, so SpaceX returned 0.

You can give bare slugs (stripe), board URLs (https://jobs.lever.co/spotify) or careers pages (https://ramp.com/careers). Workday always needs the full career-site URL, like https://nvidia.wd5.myworkdayjobs.com/NVIDIAExternalCareerSite. Slugs don't always match company names. anduril came back BOARD_NOT_FOUND in my test, because their Greenhouse board is andurilindustries. When a slug misses, paste the board URL.

What a flagged job looks like

Two real records (trimmed):

[
  {
    "company": "Affirm",
    "ats": "greenhouse",
    "title": "Senior Software Engineer, Affirm Bank",
    "location": "Remote US",
    "workAuthorization": {
      "sponsorship": "not_offered",
      "usCitizenshipRequired": false,
      "usPersonRequired": false,
      "exportControlled": false,
      "securityClearance": null,
      "evidence": ["Please note that visa sponsorship is not available for this position."]
    },
    "applyUrl": "https://job-boards.greenhouse.io/affirm/jobs/7812982003"
  },
  {
    "company": "SpaceX",
    "ats": "greenhouse",
    "title": "AI Security Software Engineer (Starshield)",
    "location": "Hawthorne, CA",
    "workAuthorization": {
      "sponsorship": null,
      "usCitizenshipRequired": false,
      "usPersonRequired": true,
      "exportControlled": true,
      "securityClearance": "required",
      "evidence": [
        "- To conform to US Government export regulations, applicant must be a (i) US citizen or national, (ii) US lawful, permanent resident (aka green card holder), (iii) Refugee under 8 USC.",
        "- Active Top Secret, Top Secret SCI, or DOE Level Q clearance",
        "ITAR REQUIREMENTS:"
      ]
    },
    "applyUrl": "https://boards.greenhouse.io/spacex/jobs/8880556002?gh_jid=8880556002"
  }
]

Before and after the filters

The bigger test covered Affirm, Stripe, Ramp, Databricks, SpaceX and NVIDIA's Workday site (Anduril missed, as noted above). It used keywords "software engineer" and "frontend" and maxJobsPerCompany: 50. I ran it once with no filters and once with both filters on:

Board	ATS	No filters	Both filters on
Affirm	Greenhouse	50	49
Stripe	Greenhouse	50	50
Databricks	Greenhouse	50	50
SpaceX	Greenhouse	50	0
Ramp	Ashby	22	22
NVIDIA	Workday	50	50
Total		272	221 (51 dropped)

In the unfiltered run, all 50 SpaceX jobs were flagged US-person/ITAR, and 4 also needed a clearance. One Affirm job said no sponsorship, and 4 Affirm jobs said sponsorship is offered. The other 216 jobs said nothing either way.

That last number is the important lesson: most postings never mention sponsorship. Silence doesn't mean yes, so treat null as "ask the recruiter."

Keep only jobs that explicitly offer sponsorship

The filters only remove the clear "no" jobs. To keep only the clear "yes" jobs, filter the dataset on workAuthorization.sponsorship = "offered". You can do that in the dataset view, in a spreadsheet after a CSV export, or in code:

const yes = items.filter(j => j.workAuthorization?.sponsorship === "offered");

Then read the evidence. All 4 of Affirm's "offered" jobs in my run said: "We are able to offer visa sponsorship for this role, but do require that someone is based in Spain for the role." That's real sponsorship, but for Spain, not a US H-1B. The flag can't know which country you need, and the evidence sentence can.

Get new jobs every day

Two inputs turn this into a daily alert: "onlyNewJobs": true and a "stateKey" like "visa-alerts". Each run then returns, and charges for, only jobs it hasn't returned before. Save your input as a Task and add a daily Schedule in the Apify console. To get the results somewhere useful, use Apify's integrations on the Task:

Slack: get a message in a channel when the run succeeds, with a link to the results.
Email (Gmail integration): send yourself an email when the run finishes, with the dataset attached as CSV or JSON.
Google Sheets: connect through Apify's Make, Zapier or n8n integrations, which can add each job as a row.
Webhooks: POST to your own endpoint when the run finishes.

What it costs

$0.001 per job saved, plus a $0.00005 start fee per run
Jobs dropped by the work-auth filters are not charged
Error records (like a board not found) count as one item each

My unfiltered run saved 273 items (272 jobs + 1 error), about $0.27. The filtered run saved 222, about $0.22. The 51 dropped jobs cost nothing. You can set a max cost per run and the Actor stops cleanly when it hits it.

Honest limits

Rules, not AI. Flags come from wording rules ("unable to sponsor", "must be a US citizen", "TS/SCI"). Unusual phrasing can be missed, and topic mentions can trip a flag. One NVIDIA data-governance job got exportControlled: true because the description talks about export controls as a product problem. Always check evidence.
No description, no flags. Jobs without description text get workAuthorization: null and are never dropped. Keep includeDescription on (the default).
maxJobsPerCompany applies before the filters. That's why SpaceX went from 50 to 0 instead of being refilled with other jobs. Raise the cap if you filter heavily.
Workday lists about 2,000 jobs per site at most. Add keywords for huge employers.
This is not legal advice. A flag tells you what a posting says, not what you're eligible for. When it matters, ask the employer or an immigration attorney.

Try it and tell me what's wrong

Store page: ATS Jobs Scraper (free plan: $5 credit a month, no card)
One-click example: scrape a Workday career site

It's new, so I'd really like feedback, especially from people on visas. If you find a sponsorship sentence it misses or a flag that's wrong, paste the wording in the comments or open an issue on the Actor page. Those reports are the fastest way to make the rules better.

Turn any website into clean Markdown for RAG (incremental sync, llms.txt)

Mohamed Zaghloul — Sun, 18 Oct 2026 16:18:25 +0000

If you've ever fed a website into a RAG pipeline, you know the boring part isn't the embeddings. It's getting clean text. Nav menus, cookie banners, "related posts" widgets and footers all end up in your chunks, and then every time the site changes you either re-scrape everything or guess what changed.

I built a small Apify Actor for exactly this, called Sitemap to Markdown. This post walks through a real run on the htmx essays: what goes in, what comes out, how re-runs only pick up changes, and what it costs.

The idea: use the sitemap, not a crawler

Most sites already publish a list of every page and when it last changed: sitemap.xml. So instead of crawling links, the Actor:

Finds the sitemap on its own (robots.txt, /sitemap.xml, sitemap indexes, .xml.gz)
Keeps only the URLs under the path you gave it
Downloads each page with plain HTTP (no headless browser)
Strips the boilerplate and converts the main content to Markdown
Optionally splits it into RAG-sized chunks and writes llms.txt / llms-full.txt

If a site has no sitemap, it falls back to a shallow same-site link crawl.

Input

This is the exact input I ran:

{
  "startUrls": ["https://htmx.org/essays"],
  "maxPages": 0,
  "incremental": true,
  "incrementalStateKey": "devto-demo-htmx",
  "chunkSize": 400,
  "createLlmsTxt": true
}

maxPages: 0 means no limit: every essay URL in the sitemap.
incremental: true makes the Actor remember what it has seen, under the name in incrementalStateKey.
chunkSize: 400 splits each page into chunks of about 400 tokens, by heading and paragraph.

Output

You get one dataset record per page. Each page's markdown starts with YAML front matter, so it can go straight into a file-based pipeline:

---
title: "</> htmx ~ A Real World wasm to htmx Port"
url: "https://htmx.org/essays/a-real-world-wasm-to-htmx-port/"
canonical_url: "https://htmx.org/essays/a-real-world-wasm-to-htmx-port/"
lastmod: "2025-01-10"
language: "en"
word_count: 617
thin_content: false
---

# A Real World wasm to htmx Port

Joe Fioti

January 10, 2025

When I was in college, I wrote some customer service software that tied together ...

The rest of the record (trimmed):

{
  "type": "page",
  "url": "https://htmx.org/essays/a-real-world-wasm-to-htmx-port/",
  "canonicalUrl": "https://htmx.org/essays/a-real-world-wasm-to-htmx-port/",
  "lastmod": "2025-01-10",
  "changeStatus": "new",
  "contentHash": "958fdb17b6246b5bea12b422b88cc12d12204a467949cfee7522513928b8917b",
  "wordCount": 617,
  "tokenEstimate": 897,
  "chunkCount": 3,
  "chunks": [
    { "index": 0, "heading": "A Real World wasm to htmx Port", "text": "# A Real World wasm to htmx Port\n\nJoe Fioti ...", "tokenEstimate": 324 }
  ]
}

A few fields that matter for RAG:

chunks: each chunk keeps its heading, so you can store it as metadata and cite sources.
contentHash: a SHA-256 of the Markdown, handy for "only re-embed what changed".
canonicalUrl: lets you skip duplicate paths. The Actor already skips exact duplicates by default.
thin_content: pages with almost no main content (under 50 words by default) are flagged as thin_page instead of being written like a normal page. That includes JS-only pages, since there's no browser rendering. They're also left out of llms.txt, so they don't end up embedded as noise.

The run also saves llms.txt (a title + link + description index) and llms-full.txt (every page's Markdown in one file) to the key-value store. The second one is handy for uploading a whole site to ChatGPT, Claude Projects or NotebookLM. Here's the start of the generated llms.txt:

# htmx.org

> Pages from https://htmx.org/essays, converted to Markdown by the Sitemap to Markdown Actor on 2026-10-18.

## Pages

- [</> htmx ~ Architectural Sympathy](https://htmx.org/essays/architectural-sympathy/): In this essay, Carson Gross explores architectural sympathy as a software design principle ...

Incremental sync: the part I actually care about

Re-scraping a whole docs site every night to catch two edited pages is wasteful. With incremental: true, the Actor keeps a small state record in a named key-value store in your own Apify account. On each run it:

skips pages whose sitemap lastmod hasn't changed (they aren't even downloaded)
downloads the rest, compares content hashes, and only outputs pages that are new or changed
writes a CHANGES record listing new, changed, unchanged and removed URLs

Here's what happened on the last two runs of this input. Earlier runs, with a page cap, had already synced 41 of the 56 essay pages:

Run	Pages output	Runtime	CHANGES
Catch-up run	the 15 remaining pages, all `new`	7.1 s	`new: 15, unchanged: 41`
Re-run right after	0 pages	1.6 s	`new: 0, changed: 0, unchanged: 56, removed: 0`

The CHANGES record is what you wire into your vector store: upsert new and changed, delete removed. Then a nightly schedule only does real work on days the site actually changed.

Two honest caveats:

removed is only reliable when the run reads the whole sitemap: maxPages: 0 and no lastmodAfter date filter.
maxPages limits new and changed pages per run, so with a cap, a big site fills in over several runs.

What it costs

It's pay-per-result on Apify:

$0.20 per 1,000 pages saved (that's $0.0002 a page), plus a $0.00005 start fee per run
Chunks live inside the page record, so chunking costs nothing extra; llms.txt is free too
A re-run where nothing changed outputs nothing, so you pay only the start fee

The full htmx essays section (56 pages) costs under 3 cents the first time and about nothing on a quiet night. You can set a max cost per run in Apify, and the Actor stops cleanly at that limit.

When not to use it

It's plain HTTP, so it won't render JavaScript-only SPAs, log in, or get past aggressive bot protection. Pages from those sites come back flagged as thin, or as a BLOCKED error instead of silently empty. For those, a browser-based crawler like Apify's Website Content Crawler is the better (more expensive) tool. This one is aimed at docs, blogs, help centers and marketing sites, which is most of what people actually want in a RAG index.

Try it

Store page: Sitemap to Markdown
It runs from the Apify console, the API, or as a tool for AI agents through the Apify MCP server.

It's new, so I'd genuinely like feedback. If the Markdown isn't clean enough for your pipeline, or a field is missing, tell me in the comments or open an issue on the Actor page.

Validate an IBAN and VAT number before paying an invoice

Mohamed Zaghloul — Sun, 18 Oct 2026 16:17:04 +0000

A mistyped IBAN or a made-up VAT number on a supplier invoice is cheap to catch before payment and expensive to fix after. Here's a small pre-payment check you can add to any accounts-payable flow with two HTTP calls.

Just want to check one number? Use the free IBAN & VAT checker in your browser, no sign-up.

I'll use the Invoice & Payment ID Validator API on RapidAPI (I built it; there's a free plan with 100 requests a month): https://rapidapi.com/MohamedBahaa/api/invoice-payment-id-validator

1. Check the IBAN

curl --request GET \
  --url 'https://invoice-payment-id-validator.p.rapidapi.com/v1/iban?value=DE89370400440532013000' \
  --header 'x-rapidapi-host: invoice-payment-id-validator.p.rapidapi.com' \
  --header 'x-rapidapi-key: YOUR_RAPIDAPI_KEY'

Real response:

{
  "input": "DE89370400440532013000",
  "iban": "DE89370400440532013000",
  "country": "DE",
  "check_digits": "89",
  "bban": "370400440532013000",
  "valid": true,
  "country_name": "Germany",
  "bank_code": "37040044",
  "branch_code": null,
  "account_number": "0532013000",
  "formatted": "DE89 3704 0044 0532 0130 00",
  "sepa": true,
  "errors": []
}

What it checks: the country's IBAN length, the ISO 13616 mod-97 checksum, and SEPA membership. It also splits out the bank code, branch code, and account number for 20 common countries. Change one digit and you get "valid": false with "errors": ["bad_checksum"].

What it doesn't check: whether the account is open or who owns it. A valid checksum means the IBAN is well-formed, not that it belongs to your supplier. For that you still need the supplier's confirmation, or your bank's payee-verification service where one exists.

2. Check the EU VAT number, live against VIES

curl --request GET \
  --url 'https://invoice-payment-id-validator.p.rapidapi.com/v1/vat/eu?value=IE6388047V&live=true' \
  --header 'x-rapidapi-host: invoice-payment-id-validator.p.rapidapi.com' \
  --header 'x-rapidapi-key: YOUR_RAPIDAPI_KEY'

Real response (request_date trimmed):

{
  "input": "IE6388047V",
  "valid": true,
  "country": "IE",
  "number": "6388047V",
  "vat": "IE6388047V",
  "format_valid": true,
  "checksum": "not_checked",
  "errors": [],
  "vies": {
    "checked": true,
    "registered": true,
    "name": "GOOGLE IRELAND LIMITED",
    "address": "3RD FLOOR, GORDON HOUSE, BARROW STREET, DUBLIN 4",
    "error": null
  }
}

With live=true, the API asks the EU's VIES service whether the number is registered. When the member state shares it, you also get the registered name and address, which you can compare with the invoice. Without live=true, it only checks the format (fast, offline). VIES is sometimes down for individual countries. When it is, vies.error tells you, so treat that as "retry later", not "invalid".

UK VAT (/v1/vat/gb), US EIN (/v1/ein) and BIC/SWIFT (/v1/bic) work the same way with ?value=.

3. Check a whole invoice in one call

curl --request POST \
  --url 'https://invoice-payment-id-validator.p.rapidapi.com/v1/batch' \
  --header 'content-type: application/json' \
  --header 'x-rapidapi-host: invoice-payment-id-validator.p.rapidapi.com' \
  --header 'x-rapidapi-key: YOUR_RAPIDAPI_KEY' \
  --data '{"items":[{"type":"iban","value":"DE89370400440532013000"},{"type":"eu_vat","value":"IE6388047V","live":true}]}'

Up to 50 IDs per call (up to 10 of them live VIES checks).

4. A simple pay / hold rule

Hold if iban.valid is false
Hold if vies.registered is false
Flag for review if the VIES name doesn't roughly match the supplier name on the invoice
Retry later if vies.error is set
Otherwise, pass it to approval

5. Do it in n8n

If your invoices arrive by email, my free n8n template turns vendor invoice PDFs in Gmail into clean rows in Google Sheets: https://mohabaha0.gumroad.com/l/ap-invoice-triage-free

To add the checks above, put an HTTP Request node after the extraction step: use POST /v1/batch with the JSON body from step 3 and your two x-rapidapi-* headers. Then add an IF node with the pay / hold rule.

If you use AI agents, the API is also an MCP server at /mcp, so Claude or Cursor can call the validators as tools.

Questions or edge cases (odd country formats, VIES quirks)? Drop them in the comments.

Extracting invoices from Gmail with n8n and Gemini, then checking the IBAN before anyone pays it

Mohamed Zaghloul — Sun, 18 Oct 2026 08:41:33 +0000

Most invoice automations stop at extraction: an LLM pulls the vendor, total and bank details out of a PDF, and the numbers go straight into a spreadsheet or ledger. The risky part is that an LLM can read a perfectly formatted IBAN with one wrong digit, and nothing downstream notices.

This post walks through a free n8n template that handles the extraction, and a small API I built that handles the checksum part. They're separate pieces: the template doesn't call the API out of the box. I'll show how to add it.

Part 1: the free n8n template

Nodes, in order:

Gmail Trigger: polls for unread mail labelled invoices with a PDF attached.
Split PDF Attachments (Code node): one item per PDF, so an email with three invoices produces three rows.
Extract From File: reads the PDF's text layer. Scanned image-only PDFs need OCR first.
Gemini + Structured Output Parser: returns vendor, invoice number, PO number, dates, currency, subtotal, tax, total, line items and a confidence score as strict JSON. Temperature 0, retries on rate limits.
Normalize Invoice (Code node): cleans numbers and dates, checks that subtotal + tax = total, and marks low-confidence rows needs_review.
Google Sheets: appends the row. Then Gmail marks the email read so it's never processed twice.

Setup takes about 10 minutes: a Gmail label and filter, a sheet with an Invoices tab, and three credentials (Gmail, Sheets, a free Gemini key from Google AI Studio).

Two things that made it more reliable:

Strict schema over free text. The Structured Output Parser rejects anything that isn't the expected JSON, so a malformed response fails loudly instead of writing garbage.
Check the math in code, not in the prompt. Asking Gemini "does this add up?" is slower and less reliable than one line of arithmetic in the Normalize node.

Part 2: validating payment IDs with an API

Extraction confidence doesn't tell you whether an IBAN is real. The ISO 13616 mod-97 checksum does. I put that, plus a few related checks, in a Cloudflare Worker:

IBAN: country, length, mod-97 checksum, SEPA membership
BIC: format and country
EU VAT: format, plus an optional live lookup against the EU's VIES service
UK VAT: format and checksum
US EIN: format and IRS prefix (EINs have no check digit, so that's as far as honest validation goes)

Up to 50 identifiers per batch request. Here's a real response from the keyless demo endpoint:

curl "https://invoice-validator.mohamed-bahaa53000.workers.dev/demo/v1/iban?value=DE89370400440532013000"

{
  "iban": "DE89370400440532013000",
  "country": "DE",
  "check_digits": "89",
  "bban": "370400440532013000",
  "valid": true,
  "formatted": "DE89 3704 0044 0532 0130 00",
  "sepa": true,
  "errors": []
}

The demo allows 10 calls per IP per day without a key.

Why a Worker rather than an n8n Code node? Mostly reuse: the same check is useful from Make, Zapier or a backend, and it's stateless, so it runs at the edge in milliseconds. It also isolates the slow part. VIES throttles by member state, so when it's unavailable the API returns checked: false with a reason instead of a false "invalid".

Part 3: wiring them together yourself

After Normalize Invoice, add an HTTP Request node:

Method: POST, to the /v1/batch endpoint from the RapidAPI listing
Headers: X-RapidAPI-Key and X-RapidAPI-Host
Body:

{
  "items": [
    { "id": "INV-1042-iban", "type": "iban", "value": "DE89370400440532013000" },
    { "id": "INV-1042-vat", "type": "eu_vat", "value": "DE123456789", "live": true }
  ]
}

In n8n, map each value with an expression from the previous node, for example $json.invoice_number, $json.vendor_iban and $json.vendor_vat.

You'll need to add vendor_iban and vendor_vat to the Gemini schema first. Then treat valid: false as "needs review", and checked: false from VIES as "verify manually", not as a rejection. A person sees exactly why a row was flagged.

What I took away

Fail open to a human, never closed to the ledger. Anything that can time out should route to review.
Batch external checks. One call per identifier multiplies latency and quota.
Keep each piece honest about what it does. The template extracts; the API validates; you decide how strict to be.

DEV Community: Mohamed Zaghloul

Companies that sponsored green cards for frontend developers in 2026 (free list from DOL PERM data)

Free sample: top 15 frontend green card sponsors (FY2026)

How to read the columns

How to use the list in a job search

Limits (please read before you rely on this)

For developers: pull your own fresh list

Get the full list

How to find government RFPs in 549 city/county portals for free

What makes it different

Input

What happened

Output

Turn it into a daily bid alert

What it costs

Honest limits

Try it

Every ID on this invoice is valid. Here's why you shouldn't pay it (MCP payee check)

What it cross-checks

Add it to Claude Desktop or Cursor

Or just call it over plain HTTP

I built a $3 Google Sheet that tracks every job application from Gmail automatically

What it does

The dashboard

How it recognises emails

Privacy

Setup tips (2 minutes)

Honest limits

Get it

How to find visa sponsorship jobs automatically (Greenhouse, Lever and Workday boards)

Why company job boards, not LinkedIn

What makes this different

Copy-paste input (about 10 seconds)

What a flagged job looks like

Before and after the filters

Keep only jobs that explicitly offer sponsorship

Get new jobs every day

What it costs

Honest limits

Try it and tell me what's wrong

Turn any website into clean Markdown for RAG (incremental sync, llms.txt)

The idea: use the sitemap, not a crawler

Input

Output

Incremental sync: the part I actually care about

What it costs

When not to use it

Try it

Validate an IBAN and VAT number before paying an invoice

1. Check the IBAN

2. Check the EU VAT number, live against VIES

3. Check a whole invoice in one call

4. A simple pay / hold rule

5. Do it in n8n

Extracting invoices from Gmail with n8n and Gemini, then checking the IBAN before anyone pays it

Part 1: the free n8n template

Part 2: validating payment IDs with an API

Part 3: wiring them together yourself

What I took away

Links