# Polymer Jobs API > Query jobs from Polymer boards through one API with ?source=polymer — plus why every request needs a browser fingerprint, and what that costs. Source: https://hyperjobs.io/ats/polymer Polymer is a small ATS used mostly by startups and VC portfolio companies, with boards at `jobs.polymer.co/`. It is a Rails app rendered server-side, which is good news: the board page is the board, with no JSON API to reverse and no JavaScript to run. The bad news is that you cannot reach it with an ordinary HTTP client. ## Every request needs a browser fingerprint Polymer sits behind Cloudflare, and the wall is not selective. A plain client gets a `403` and a "Just a moment" interstitial on **every** request, list and detail alike. A residential proxy does not help — it is not an IP-reputation check, it's a fingerprint check. That makes Polymer one of only a couple of platforms here where the browser-fingerprint tier is **mandatory rather than an escalation**. [Breezy](/ats/breezy) has a cheap rung to try first and escalates on a 403. Polymer has none: every request would 403, so the ladder is pure waste and you go straight to the impersonating client. It's the same pattern as Y Combinator's Work at a Startup board, where a plain client is also refused outright and the fingerprinted one is served normally. The practical consequence is that with the tier switched off, the correct behaviour is to **fail loudly**. Returning "no jobs" would be a lie with expensive consequences, for the reason below. ```bash # list → cards https://jobs.polymer.co/ # detail → JobPosting JSON-LD, which is where the body lives https://jobs.polymer.co// ``` There is no pagination. The board root is the whole board — `?page=2` and `?per_page` return page one byte-identically, no board carries pagination markup, and a sweep of 387 known tenants found a smooth 1-to-16-job distribution with no pile-up at any round number. A paging cap would show as a spike. There isn't one. ## What bites you This is the most dangerous trap on the platform. Bursting a single known-good board returned 8 of 24 as `404` at concurrency 8, and 12 of 60 at concurrency 20, while concurrency 4 and below was clean. The board was fine the whole time. Read that 404 as "board is gone" and you hand your pipeline an empty live set for a perfectly healthy board — which expires every job on it. The two 404s are cleanly separable, but not by status code. A rate-limit 404 has an **empty body**, 0 bytes. A genuinely dead tenant gets Rails' real 2,608-byte "The page you were looking for doesn't exist" page. One backs off and retries; the other means the tenant is really gone. **A 200 with zero jobs is usually a real empty board.** The page says so in words: "We don't have any active job posts right now." Only 99 of 368 live tenants had any jobs at all, so this is the common case rather than an error. **The JSON-LD cannot express hybrid.** `jobLocationType` is `TELECOMMUTE` for remote, for "remote friendly", and for hybrid alike — 17 hybrid jobs, all TELECOMMUTE. The real three-way value is on the **list** page, in the globe trait beside each card, and it is strictly more reliable: two postings showed a globe value while the detail page omitted `jobLocationType` entirely. So the arrangement has to come from the list and be carried into the detail mapper. **`applicantLocationRequirements` is not a location.** On a remote posting it is a list of **234 countries** — every country on earth, which is how Polymer spells "remote anywhere". Map it and you write 234 locations per job. Only `jobLocation` is real. **The platform publishes no compensation at all.** Zero of 61 postings had a `baseSalary`, and the detail page has no salary markup or prose either. There is nothing to parse and nothing to infer a period from. **The list's date is relative and useless** ("5h", "3d"). The detail page's `datePosted` is absolute but not ISO: `2026-07-15 08:44:33 UTC`. It does carry an explicit zone, which is the part that matters. ## Or use ours Descriptions and country both come back at 100% on the tenants measured, and `hiringOrganization` carries the employer's real domain and logo on every posting, which makes the [company join](/docs/objects/company) cheap here. You get the fingerprint tier on every request rather than a ladder that would 403 on its first rung, the empty-bodied 404 backed off and retried instead of reaped as a dead tenant, the arrangement carried from the list's globe trait because the detail's `jobLocationType` can't spell hybrid, `jobLocation` read and `applicantLocationRequirements` ignored, and the relative list date dropped in favour of the detail's zoned `datePosted`. No compensation, because the platform publishes none. The economics are the honest problem. Boards are tiny — 315 jobs across 387 tenants, averaging 3.2 on a board that has any — and every single request needs the fingerprint tier, so it works out to roughly two impersonated requests per job. That is the worst cost-per-job of anything in this pool, and it is why Polymer sits in the heavy tier rather than the fast one. Query it with `?source=polymer`. [`/v1/meta`](/docs/api-reference/meta) → `sources` is the live vocabulary with counts, and it's the only list worth coding against. See [all platforms](/ats) · [coverage](/docs/reference/coverage)