Querying AI companies' ATS APIs to find real Forward Deployed Engineer roles

Forward Deployed Engineer reqs are everywhere right now, and a lot of them are not what they look like. I got tired of guessing, so I stopped reading job aggregators and started querying the companies' own applicant tracking systems directly.

Most companies hiring for this role run Ashby or Greenhouse, and both expose a public posting API with no authentication and no rate pain:

https://api.ashbyhq.com/posting-api/job-board/<org>
https://boards-api.greenhouse.io/v1/boards/<org>/jobs?content=true

That returns three fields scraping does not reliably give you: isListed, which tells you whether the req is actually live rather than merely indexed by a search engine; publishedAt, the real posting date; and the full description text, so you can quote a req exactly instead of paraphrasing a snippet.

All figures below were pulled on 2026-08-03 and re-verified on 2026-08-04. Job boards move daily, so re-run the queries rather than trusting these numbers. One board in this dataset grew by fourteen reqs in the twenty-four hours I was looking at it.

The obvious rule does not work

The first thing I tried was the intuitive one. An aggregator posting on behalf of dozens of third parties should have a huge board with enormous title diversity, and a real employer should have a small focused one. So: flag big boards.

That rule is wrong, and it is wrong in the direction that matters.

board	jobs	distinct titles	titles per job
Harvey	362	214	0.59
Clera	313	217	0.69
OpenAI	736	689	0.94
Sierra	175	138	0.79
Ramp	124	124	1.00

Harvey is a real company with a bigger board and lower title diversity than the board I was suspicious of. OpenAI is nearly twice the size of both. Size tells you how much money a company raised. It does not tell you whether a posting is real, and neither does the title diversity ratio.

The rule that does work

The signal is not duplication. It is duplication of a title whose meaning forbids duplication.

Count the reqs whose title begins with the word "Founding".

board	jobs	"Founding"-titled reqs	distinct founding titles	most duplicated
Clera	313	116	52	19
Glean	108	3	1	3
Dryft	5	3	3	1
Avallon	3	3	3	1
OpenAI	736	2	2	1
Harvey	362	1	1	1
Decagon	121	1	1	1
Anthropic	399	0	0	0
Sierra	175	0	0	0
Ramp	124	0	0	0

Read the fourth column. Every single-employer board in this set carries between zero and three *distinct* founding titles. One board carries fifty-two, including nineteen identical reqs titled "Founding Engineer", fourteen titled "Founding Engineer ($3M pre-seed)", and nine titled "Founding Engineer, SF Hackerhouse (Visa sponsored; $3M pre-seed)".

A company is founded once, so it has a handful of distinct founding roles. An aggregator accumulates founding roles from many companies, so its count of distinct founding titles grows without bound. Fifty-two against a ceiling of three is not a threshold I tuned; it is a gap with nothing in it.

The reason this works is semantic rather than statistical. A founding engineer is by definition the first one. You cannot have nineteen of them. Compare that with Sierra running eight reqs titled "Software Engineer, Agent" across eight different cities, which is completely ordinary and which a naive duplicate-detector would flag.

This rule is the third one I tried, and the first two are still in this post

I have now had two versions of this rule falsified by companies named in my own tables. Both are left standing below, because a filter you can check is worth more than one you have to trust.

Version one: count the founding reqs. I claimed a real employer has at most two. Dryft has three on a five-job board, Avallon has three on a three-job board.

board	jobs	founding reqs	the actual titles
Dryft	5	3	Founding Design Engineer, Founding Forward Deployed Engineer, Founding Full-Stack Engineer
Avallon	3	3	Founding Forward Deployed Engineer, Founding Software Engineer, Founding Account Executive

Both are exactly what a seed-stage company looks like. Three *different* founding roles is normal and is arguably the strongest signal that a company is real and early.

Version two: no real employer repeats one founding title. That survived until I read Glean's board, which is on Greenhouse rather than Ashby:

company	title	locations
Glean	Founding Forward Deployed Engineer	Mountain View CA, New York NY, Remote US

Three identical titles, one real company, and the exact job title this post is about. It is one search posted in three metros, which is the same ordinary thing Sierra does with eight "Software Engineer, Agent" reqs across eight cities. Duplication alone was never the signal, and I had already published Sierra as the control proving it before building a rule on duplication anyway.

What survives both is the count of *distinct* founding titles. Glean has one. Dryft and Avallon have three. The aggregator has fifty-two.

None of this is visible on the individual posting. The board I am describing surfaces eleven Forward Deployed Engineer reqs, one of which is titled "Founding Forward Deployed Engineer" and reads exactly like the real ones.

Two other things the APIs hand you free

isListed catches roles that are dead but still indexed. Three founding-FDE postings I had bookmarked from search results were gone from the live boards when I checked. The companies still exist and their boards are up, with two, four, and nine jobs respectively. The reqs simply closed, and the search results did not. Anyone working from a search page alone would have applied to three closed roles.

publishedAt tells you how long a company has been failing to fill a role. Among boards small enough to belong to a single employer, every live founding-FDE req and its posting date:

company	title	posted	days live
Dryft	Founding Forward Deployed Engineer	2025-08-01	367
Avallon	Founding Forward Deployed Engineer	2026-03-06	150
E2B	Forward Deployed Engineer	2026-03-25	131
Hyperscale Systems	Founding Forward Deployed Engineer	2026-03-26	130
Denari	Founding Forward Deployed Engineer	2026-07-22	12

A founding req that has been open for a year is telling you something, though not necessarily what you would guess. It can mean the bar is genuinely high, it can mean the comp is wrong, or it can mean nobody has been given ownership of the search. Worth asking about in a first call rather than assuming.

For scale on the other end: OpenAI alone had 37 Forward Deployed Engineer shaped reqs live on a 736-job board.

A methods note that cost me ten minutes

My first sweep returned HTTP 403 for all twenty-one boards, including three I had successfully queried by hand sixty seconds earlier. A uniform failure across every org, including known-good ones, is a fact about your client and not about the servers. Ashby blocks Python's default urllib user agent. Curl works, and so does urllib with a real user agent set.

The general version: when a check fails for every subject at once, carry a known-good control through the identical path before you write anything down. If the control also fails, you have measured your instrument.

Related, and it cost me more than ten minutes: Anthropic and Glean have no Ashby board at those slugs. That means unverified, not absent. Both are on Greenhouse, and Glean's board is the one that falsified the second version of my rule, so the company I had filed as unreadable was the single most informative board in the set. Recording a lookup failure as a negative result is the same error as reading the 403s as closed boards.

What I would actually do with this

Before applying to any req that calls itself founding or first:

1. Pull the company's board from the ATS API and count the total jobs.
2. Count the distinct titles beginning with "Founding". Zero to three is an ordinary company. Dozens means the board is a catalogue of other people's founding teams. Neither the raw number of founding reqs nor the repetition of any one title is the signal: a seed-stage company can carry three different founding roles, and a real company can post one founding role in three cities.
3. Check isListed on the specific req rather than trusting the search result that sent you there.
4. Read publishedAt. If it is old, ask about the search in your first conversation.
5. Read the full description text from the API rather than the aggregator's summary, which is frequently truncated in the middle of the requirements.

Limits

The negative side is well tested. The positive side is one board. I have now checked 35 boards that belong to a single employer, across both Ashby and Greenhouse, and every one carries between zero and three distinct founding titles. That set includes companies I do not track and had no prior view on (Notion, Linear, Vercel, Replit, Modal, LangChain, Fireworks, Mercor, Anthropic, Scale AI), plus several venture firms' boards, which turn out to be ordinary small internal boards rather than portfolio aggregators.

Against those 35 I have exactly one board on the other side of the rule. That is the real weakness here, and I would rather say it than have you find it. A filter validated on one positive example is a description of that example until someone breaks it.

I went looking for a second aggregator and failed, which is itself informative: portfolio and talent-collective job boards mostly do not live on Ashby or Greenhouse at all. They run on Getro, Consider and similar platforms that expose no comparable public API. The class of board this rule exists to catch is largely invisible to the method the rule is built on. If you find another, I want to hear about it. An eighth, Glean, I originally recorded as unreadable after its Ashby slug returned nothing. That was a fact about which API I tried: Glean is on Greenhouse, its board reads fine, and it is what broke the second version of the rule. An unreadable verdict is scoped to the instrument you pointed at the thing. It also only covers Ashby and Greenhouse, so companies on Lever, Workable, or a homegrown board are outside it entirely. The rule is a cheap first filter, not a verdict, and everything here is checkable by re-running the two URLs at the top.