DEV Community: Felix Yang

Every careers page has a public JSON API — you just never noticed

Felix Yang — Mon, 12 Oct 2026 07:10:14 +0000

Most people who need job-posting data reach for a headless browser. They point Playwright at a careers page, hope the React app has hydrated, and write selectors that will break the next time marketing ships a redesign.

You usually don't need any of that.

The three ATS platforms that most startups use — Greenhouse, Ashby and Lever — already serve every job board as plain JSON. They have to. That's how the "embed our jobs on your own website" widget works.

These endpoints are public. No login, no API key, no browser. Here are all three, with real numbers I pulled while writing this.

The three endpoints

Provider	Endpoint	Shape
Greenhouse	`https://boards-api.greenhouse.io/v1/boards/{slug}/jobs`	`{"jobs": [...]}`
Ashby	`https://api.ashbyhq.com/posting-api/job-board/{slug}`	`{"jobs": [...]}`
Lever	`https://api.lever.co/v0/postings/{slug}?mode=json`	bare `[...]`

Two of them wrap the array; Lever returns a naked one. That alone will make you write three normalizers, so plan for it.

Live counts, pulled on 2026-10-12:

Greenhouse  stripe    → 727 jobs
Greenhouse  gitlab    → 221 jobs
Ashby       openai    → 811 jobs
Ashby       ramp      → 165 jobs
Lever       leverdemo →  10 jobs

That's 1,934 postings from five requests. No browser, no proxies, well under a second each.

Working out which ATS a company uses

Don't guess — read the careers URL. All three vendors use predictable hosts:

job-boards.greenhouse.io/stripe   → greenhouse, slug "stripe"
boards.greenhouse.io/gitlab       → greenhouse, slug "gitlab"
jobs.ashbyhq.com/openai           → ashby,       slug "openai"
jobs.lever.co/leverdemo           → lever,       slug "leverdemo"

The slug is whatever sits between the host and the next slash. On a company's own domain the path is usually similar — /careers redirects, or the embed URL leaks the slug in a query parameter.

The smallest thing that works

slug=stripe
curl -s "https://boards-api.greenhouse.io/v1/boards/$slug/jobs" \
  | jq -r '.jobs[] | [.title, .location.name, .absolute_url] | @tsv' \
  | head -20

And in Python, normalizing all three into one shape:

import httpx

def fetch(provider: str, slug: str) -> list[dict]:
    if provider == "greenhouse":
        url = f"https://boards-api.greenhouse.io/v1/boards/{slug}/jobs"
        raw = httpx.get(url, timeout=20).json()["jobs"]
        return [{"title": j["title"], "url": j["absolute_url"],
                 "location": (j.get("location") or {}).get("name"),
                 "updatedAt": j.get("updated_at")} for j in raw]

    if provider == "ashby":
        url = f"https://api.ashbyhq.com/posting-api/job-board/{slug}"
        raw = httpx.get(url, timeout=20).json()["jobs"]
        return [{"title": j["title"], "url": j["jobUrl"],
                 "location": j.get("location"),
                 "updatedAt": j.get("publishedAt")} for j in raw]

    if provider == "lever":
        url = f"https://api.lever.co/v0/postings/{slug}?mode=json"
        raw = httpx.get(url, timeout=20).json()   # bare array
        return [{"title": j["text"], "url": j["hostedUrl"],
                 "location": j.get("categories", {}).get("location"),
                 "updatedAt": j.get("createdAt")} for j in raw]

    raise ValueError(provider)

The traps nobody mentions

The slug is not the company name. gitlab works. So does a lot of near-misses that don't — which is why you need to distinguish "wrong slug" from "no openings right now". A board that exists but has zero jobs still returns a valid empty result. Test for a 200 with an empty array, not a 404. Otherwise you'll spend an afternoon renaming a company that was never hiring.

Timestamps are three different formats. Greenhouse gives you ISO-8601 strings, Ashby gives ISO-8601, Lever gives epoch milliseconds as an integer. If you sort a mixed array without normalizing, you get silent nonsense.

Descriptions can blow up your payload. Greenhouse's ?content=true and Ashby's ?includeCompensation=true pull the full HTML job description — routinely 10–20 KB per posting. On a board with 800 openings that's tens of megabytes for data most pipelines throw away. Fetch titles first, then enrich only the rows you actually need.

Be a good citizen. These are public endpoints, but they're not yours. Space your requests, don't run a hundred boards in parallel, and cache. I use a 250 ms delay between boards and four-way concurrency, which is enough to feel instant and rude to nobody.

Check the terms before you redistribute. The endpoints are public; the postings aren't necessarily yours to republish. Personal data and contact details inside postings deserve particular care, especially if you're in a jurisdiction with data-protection law.

If you'd rather not maintain this

All of the above is maybe 120 lines of code. I wrote it out and put it here — standard library only, no dependencies, MIT:

github.com/yff124/apify-actors/blob/main/ats_normalizers.py

python3 ats_normalizers.py stripe                           # bare slug, auto-detects the provider
python3 ats_normalizers.py https://jobs.ashbyhq.com/openai  # or hand it a careers URL

It accepts a company name, an explicit provider:slug, or a full careers URL, auto-detects which of the three platforms answers, and returns one schema — the same three public endpoints described above, with the slug guessing, the timestamp normalizing and the politeness handled for you.

If you'd rather not run anything locally, the same thing is also packaged as a hosted Actor — paste a company or a careers URL, it runs in the cloud and hands you a dataset: ATS Job Board Aggregator. It covers Workday too, which needs a separate endpoint and a paging quirk the script above leaves out.

Run 5 companies or 500. If you only ever need one company, the curl command at the top of this post is genuinely all you need — I'd rather you knew how it works than treated it as magic.

Written with AI assistance and verified by hand — every endpoint and job count in this post was pulled live on 2026-10-12.

CJK line breaking in Canvas, and what the browser will not do for you

Felix Yang — Sun, 11 Oct 2026 08:42:47 +0000

CSS has been quietly good at CJK line breaking for years. word-break: normal plus line-break: strict plus the browser's default break-opportunity table gets you typographically sane paragraphs without writing a line of logic.

Canvas does not. <canvas> gives you measureText() — a width per string — and nothing else. If you build anything that composes text into an image (a share card, a certificate, a dynamic cover, a mini-program poster), you are writing your own line breaker. And the naive one is wrong in a way that is easy not to notice if you do not read Chinese.

The naive implementation, and exactly how it fails

accumulate characters until measureText(line + ch).width > maxWidth
then push the line and start a new one

For Latin text this is roughly acceptable, because the breaks almost always land near spaces. For CJK there are no spaces, so the break lands wherever the width runs out:

本产品支持批量导出
图片并自动压缩

That is fine by luck. Now shift the box 20px:

本产品支持批量导
出图片并自动压缩

导出 has been split. A Chinese reader does not read this as a slightly awkward break, they read it as a typo. The same code, two different results, and only one of them is acceptable.

Three rules that fix most of it

1. Prefer a break at punctuation. Before accepting a width-driven break, scan back up to ~12 characters for the nearest closing punctuation — ，。、：；！？）」』】—… — and break there instead. This single rule accounts for the majority of natural break points in running prose.

2. Keep numbers and their units together. If the break would leave 20 at the end of one line and + or 项 at the start of the next, pull the number down. Readers parse 20 / + 项 as two separate values.

3. Never start a line with closing punctuation. A full stop, comma, or closing bracket at the start of a line is the single most visible CJK typographic error, and it is also the easiest to check for.

const CLOSERS = "，。、：；！？）」』】—…";
const OPENERS = "（「『【";

function breakBefore(ctx, text, i, font, maxWidth, indent = 12) {
  // try punctuation within `indent` characters, walking backwards
  for (let k = 1; k <= indent && i - k > 0; k++) {
    if (CLOSERS.includes(text[i - k])) return i - k + 1; // break AFTER the closer
  }
  // fall back: never leave a closer stranded at line start
  if (CLOSERS.includes(text[i])) return i + 1;
  return i;
}

Two implementation details that are easy to get wrong:

Measure with the same font object you draw with. ctx.measureText() after changing ctx.font reflects the new font. Cache the width of each character once per (font, size) pair; measuring per character per frame is the usual reason a text layout janks.
Let CJK characters wrap individually but keep Latin words intact. A run of [A-Za-z0-9]+ should be treated as one indivisible unit. Mixing the two scripts in one paragraph is the normal case in Chinese product copy, and it is where most homegrown wrappers fall apart.

If you can, do not write this at all

Modern browsers ship Intl.Segmenter with granularity: "word", which gives you the same break-opportunity data the CSS engine uses:

const seg = new Intl.Segmenter("zh-Hans", { granularity: "word" });
[...seg.segment("本产品支持批量导出图片并自动压缩")].map(s => s.segment);

Support is now broad enough to use directly, with a character-by-character fallback. If you are on the web and only need to lay out HTML, prefer CSS and stop reading. Canvas is the case where you have no choice.

The part that only shows up in production

Canvas fails differently from Python: there is no missing-glyph exception, silently, the same way. If a font fallback chain resolves to a face without the needed glyph, you get tofu boxes or blanks inside your drawn text. In a headless renderer (server-side, or a mini-program's offscreen canvas) you often do not see it until a user screenshots the result.

So after layout, run a cheap audit over the union of every character you intend to draw, and assert the chosen font actually covers it. Which characters break is always domain-specific — the rare surname on a certificate, the technical term on a data card — so audit your real strings, not lorem ipsum.

The rule set above, a wrapped-measureText layout pass, and the fallback chain is roughly what cjk-text-render does on the Python side. Writing the browser version is an afternoon; getting the break rules right is the part people skip.

Your CJK text is silently broken, and Pillow will not tell you

Felix Yang — Sun, 11 Oct 2026 08:42:20 +0000

If you generate images with Chinese, Japanese, or Korean text in Python, there is a category of bug you have almost certainly shipped: the text rendered, nothing threw, and the output is wrong.

Not "wrong" as in a stack trace. Wrong as in a user looks at the poster and says "something feels off" without being able to name it. Or worse: a character is simply missing from the image and nobody notices until print.

I collected the three that bite hardest while building cjk-text-render, a single-file helper for drawing CJK text with Pillow. All three are silent by construction.

Trap 1: `PingFang.ttc` index 0 is not "Regular"

On macOS, /System/Library/Fonts/PingFang.ttc is a TrueType Collection. The order of faces inside it is not weight order. It is region order:

index	face	notes
0	PingFang HK Regular	Hong Kong Traditional, the one people accidentally use
1	PingFang TC Regular	Taiwan Traditional
2	PingFang SC Regular	Simplified Chinese, the one you want
3 / 4 / 5	HK / TC / SC Medium
6 / 7 / 8	HK / TC / SC Semibold	use 8 for bold Simplified
9 / 10 / 11	HK / TC / SC Light

Because index defaults to 0, the idiomatic-looking call is the wrong one:

# WRONG: renders everything in Hong Kong Traditional glyph forms
font = ImageFont.truetype("/System/Library/Fonts/PingFang.ttc", 40)

# RIGHT: Simplified Chinese Regular
font = ImageFont.truetype("/System/Library/Fonts/PingFang.ttc", 40, index=2)

Two things go wrong when you use index 0. First, every character is drawn in the Hong Kong Traditional glyph variant. Simplified Chinese and Traditional Chinese share a large number of codepoints but not their shapes, so you get characters that are recognisably the wrong form while still being the right codepoint. Second, and much nastier: some Simplified characters are absent from the HK face. 稳 is a common example. Pillow draws a blank space. No exception, no warning, no log line.

If you want to check what you actually loaded, inspect the face rather than trusting the index:

from PIL import ImageFont
f = ImageFont.truetype("/System/Library/Fonts/PingFang.ttc", 40, index=2)
print(f.getname())   # -> ('PingFang SC', 'Regular')

Print getname() in CI. It is a one-line assertion that catches an entire class of platform-dependent regressions before they reach a human.

Trap 2: missing glyphs are drawn as blank, not raised

This is the one that should be an exception and is not.

font = ImageFont.truetype("NotoSansCJK-Regular.ttc", 40)
draw.text((0, 0), "文字と漢字の混在", font=font, fill="black")

If the loaded face does not contain one of those characters, Pillow does not raise KeyError, does not log, and does not fall back to another face. It draws nothing for that character. You get a gap in the middle of a word.

The fix is an explicit audit before you render. Pillow exposes what you need through font.getmask, but the ergonomic version is a helper that raises on the first missing codepoint:

from cjk_render import audit

audit(["all the text you are about to draw"])   # raises RuntimeError on any missing glyph

The design decision here matters: make it crash. A script that explodes at build time is strictly better than a delivered image with a hole in it. The failure mode you cannot afford is the one that ships.

Run audit() on your real strings, not on sample text. The characters that go missing are always the domain-specific ones — a rare surname on a certificate, a technical term on a data card.

Trap 3: line-breaking CJK by width instead of by punctuation

CJK has no spaces, so the obvious wrapping implementation — accumulate characters until the line exceeds max_width, then break — produces this:

知道你在打
杂

The word 打字 has been cut in half. Readers notice immediately. Latin line-breaking intuition simply does not transfer.

There are three rules worth encoding:

Prefer punctuation. Look back up to ~12 characters from the overflow point for the nearest of ，。、：；！？）」』】—… and break there if one exists.
Never split numeric units. If breaking would put 20 on one line and + on the next, the reader parses two numbers instead of one quantity.
No orphaned closing punctuation. A full stop or comma must never begin a line.

from cjk_render import wrap

lines = wrap(draw, "一段很长的中文正文……", font, max_w=900)

A short list of things that are not traps but will bite anyway

Once the three silent failures are handled, a few loud-but-annoying ones remain:

Save PNG, not JPEG. Dense CJK strokes at small sizes pick up chromatic noise from JPEG compression. If you must use JPEG, keep quality >= 95.
Auto-fit functions have an off-by-one that inverts them. In a while size > min_size shrink loop, if min_size is not strictly below the smallest starting size you call it with, the loop body never executes and your "shrink to fit" silently leaves the text at its original size, overflowing the canvas.
Cap the hierarchy at three levels. On a 1080x1080 thumbnail, a fourth text level is decoration, not information.

Why this is worth caring about

AI image generation still mangles CJK text, so any design with a lot of it — posters, data cards, marketing images, before/after comparisons — has to be drawn in code. That makes these three traps load-bearing: they are on the critical path of an entire category of work, and all three are silent.

The library is a single file with no dependencies beyond Pillow. Take it, or take the three checks and port them into whatever renderer you already have. Just do not rely on the renderer to tell you it failed. It will not.

Repo: github.com/yff124/cjk-text-render (MIT)