Product updates

You can now filter jobs by workplace type: On-site, Hybrid, or Remote.

The new filter uses the structured workplace_types data already included with every job, so you no longer need to treat remote work as a separate yes-or-no condition. You can also select multiple values when a search should include more than one arrangement.

In the app

Open Job Search, click + Add Filter, and select Workplace type. Choose one or more of On-site, Hybrid, and Remote. The same workplace type filter is available for the jobs inside Company Search.

In the API

Use workplace_types_or in the Jobs API. The request returns jobs containing any of the selected workplace types:

{
  "workplace_types_or": ["hybrid", "remote"],
  "posted_at_max_age_days": 30,
  "limit": 10
}

The accepted values are on_site, hybrid, and remote. on_site returns jobs where both hybrid and remote are false. In the Company Search API, pass the same field inside job_filters.

The previous remote boolean is now deprecated. Existing requests and saved searches that use it continue to work, but new integrations should use workplace_types_or: replace "remote": true with "workplace_types_or": ["remote"]. Note that "remote": false meant “does not contain remote,” which is not the same as specifically selecting on-site jobs; use "workplace_types_or": ["on_site"] when that is what you need.

If you use TheirStack with a keyboard, a screen reader, or a browser zoomed well past 100%, parts of the app used to be awkward and a few were simply closed to you. We went through it criterion by criterion against WCAG 2.2 Level A and AA and fixed what we found — and we have published exactly where we stand on each criterion.

You can now navigate the whole app with a keyboard. That was the biggest gap, and it's the change most people will feel first.

The rest of what you're likely to notice:

• Tab reaches everything. Controls that were clickable divs — and so invisible to Tab and to the Enter key — are real buttons. Every page starts with a "Skip to main content" link, so you no longer tab through the whole sidebar to get to the table.
• Focus is visible. Every focusable control draws a focus ring, and dialogs and sticky headers no longer sit on top of the control you just moved to.
• Text is darker. Secondary text, placeholders, error messages, and invoice and request statuses were between 2.2:1 and 3.9:1 against white. They now clear the 4.5:1 that Level AA asks for.
• Icon-only buttons say what they do. Roughly forty of them announced as "button" and nothing else. They have names now.
• The page has a shape. Headings form a real outline with no skipped levels, and landmarks are labelled, so jumping by heading or by region actually works.
• It reflows. Every page fits in a 320px-wide viewport without horizontal scrolling, and survives the line and letter spacing that reader extensions apply.

One find worth calling out: the page title was rendered inside a container hidden below the md breakpoint. On a phone, no page in the app had a heading at all — a screen reader had nothing to announce the page by. That is fixed everywhere at once.

Where we stand

Every page of the app now passes the Level A and AA checks a machine can decide, and passes them again on every change we ship, so this doesn't quietly regress.

What's left is the part no tool decides: whether an alt text describes the right thing, whether the reading order makes sense non-visually, whether a screen reader announces a change in a way you can follow. That's a pass with a real screen reader, and it's the next thing on this list rather than something we're going to claim early.

So instead of a badge, we publish the detail: our Accessibility Statement lists every success criterion we verify automatically, every one we've reviewed by hand, and the ones we haven't assessed yet. If you're working through a procurement questionnaire, that's the page you want — and if it doesn't cover the criterion you need, ask us rather than infer it.

LinkedIn identifies a company page two ways: by its vanity slug (linkedin.com/company/deloitte) and by its numeric company ID (linkedin.com/company/1038). Both open the same page, and which one you end up storing depends on where you collected it.

Until now company_linkedin_url_or only ever compared the URL against our stored slug. A URL built on the numeric ID was compared against slugs like deloitte, so it could never match — and it failed quietly: the request succeeded, returned zero results, and consumed no credits. It looked like we simply did not have the company.

That is fixed, in the same filter. All of these now find Deloitte, in both Company Search and Job Search:

{ "company_linkedin_url_or": ["https://www.linkedin.com/company/1038"] }
{ "company_linkedin_url_or": ["https://www.linkedin.com/company/deloitte"] }
{ "company_linkedin_url_or": ["1038"] }
{ "company_linkedin_url_or": ["deloitte"] }

If your calls already send numeric-ID URLs, they start matching on their own — there is nothing to change on your side, and no new filter to migrate to. A value that is entirely digits is matched against both the company's LinkedIn ID and its slug, so you never have to work out which of the two you are holding. Some companies genuinely have a numeric vanity slug, and this way both resolve.

In the app the same filter covers all of it: Linkedin URL, under Company in Company Search and Job Search, accepts a full URL, a bare slug or a numeric ID, one per line.

A note on coverage

The numeric LinkedIn ID is our least complete company identifier: we have one for about 14% of companies, against 26% with a LinkedIn slug and 29% with a domain. This change removes a failure that was total and silent, but it does not make every LinkedIn lookup resolve — an identifier we do not store still returns no results.

If you have the company's domain, company_domain_or remains the identifier that matches most often.

The Technographics dataset now includes the company identifiers needed to use it on its own:

• company_name
• domain
• linkedin_url

Previously, identifying a company by its domain or LinkedIn URL required joining the Technographics dataset with the separate Companies dataset. That meant ingesting and joining two large files even when you only needed technology adoption signals. These identifiers now come directly from the same canonical company record used across TheirStack.

The new columns are available in Technographics v2.1 across CSV and Parquet deliveries, including downloadable sample files. Version 2.1 is a backward-compatible additive update: existing columns and their meanings are unchanged. See the Technographics data dictionary for the complete schema.

Until now, response times could climb sharply when you raised the result limit and asked for more companies or jobs in each query. We have optimized our backend so that requesting more results has a much smaller impact, and response times now stay much closer to constant as limits grow.

The improvement applies to searches in the app and through the API, and is especially visible at higher limits. Searches were about 3x faster overall, and the slowest company searches are now up to 9x faster.

Average response times by requested result limit:

• Limit 25: 4.08s before -> 1.99s after, about 2.0x faster.
• Limit 100: 7.76s before -> 2.62s after, about 3.0x faster.
• Limit 200: 12.27s before -> 3.25s after, about 3.8x faster.
• Limit 500: 34.68s before -> 5.25s after, about 6.6x faster across the company-search queries measured at this limit.

How we measured it

The figures shown summarize 160 end-to-end requests: 64 company-search requests and 96 job-search requests. We tested four company-search types across limits 25, 100, 200, and 500, plus eight job-search types across limits 25, 100, and 200.

For every search type and limit, we sent four requests: two to our production deployment and two to a preview deployment running the optimized code. The order alternated between preview -> production -> production -> preview and production -> preview -> preview -> production, so both deployments appeared at the beginning and end of a run. This reduces the influence of hot-versus-cold queries and other order effects. Each before value is the average of the two production requests, and each after value is the average of the two preview requests.

Both deployments connected to the same production database, so they used the same underlying data and normal live workload rather than isolated copies.

Each measurement covers the complete HTTP request and response, not only the database query. Exact response times can still be higher or lower at different moments as database load changes, so the figures are benchmark averages rather than latency guarantees.

Why higher limits benefit more

Finding the matching rows in our database is only part of the request. The API still has to fetch, join, and build the response object for every company or job it returns.

The optimized search path reduces the work needed to fetch and prepare each response. That matters most when the response contains hundreds of rows: the fixed request overhead stays similar, but the per-row savings compound.

Company searches

For company searches, the after run was faster or equal in all 16/16 measured rows. The largest gains appear at the higher limits, where the before numbers scaled up sharply and the after numbers stayed much flatter.

The benchmark covers common company search shapes: country filters, technology filters, job filters, and combined technology + job filters, measured at limits 25, 100, 200, and 500.

Each cell shows before -> after and the speedup for that limit. ✅ means the after run was faster or equal. Open a query to try the same measured filter shape in the app.

Job searches

Job searches were faster or equal in all 24/24 measured rows across limits 25, 100, and 200.

We measured title filters, keyword filters, description filters, recent-posting filters, and the same query shapes with 30-day posting windows.

Each cell shows before -> after and the speedup for that limit. ✅ means the after run was faster or equal. Open a query to try the same filter shape in the app.

What you need to do

Nothing. The improvements apply automatically in the app and through the API, with no workflow or integration changes required.

We made two seniority improvements:

1. Internship and co-op roles are classified more accurately as junior, especially when the title also contains senior-sounding words.
2. Job detail pages now show seniority as its own chip, separate from employment status chips such as Internship.

Previously, titles like Senior Marketing Intern, Product Management Intern, Member of Technical Staff Intern, or Intern - Office of the CEO could be classified as senior, staff, or C-level because those signals were checked before the internship signal. Those now correctly resolve to junior.

We also expanded matching for common internship variants such as internship, externship, co-op, co op, and titles with separators like Intern_Engineering or Co-op_Fall 2026.

Here are a few examples from the labeled set we used to validate the change:

This table refers to the seniority value shown in the new seniority chip, used by filters, exports, the API, webhooks, and the MCP server.

The classification improvement applies anywhere job seniority is used: job detail pages, Job Search, exports, the API, webhooks, and the MCP server.

We just shipped the first set of Agent Skills for the TheirStack MCP. A skill is a ready-made playbook you drop into Claude Code (or any MCP client): you give it a product website or a handful of customers, and it does the GTM research for you — grounded in real TheirStack data, not guesses. Every result comes back as a live company count that links straight into a pre-filtered search.

Three skills are available today:

• Find the sales signals for any product or service — Give it a product or service URL. It reads what the offering does and the problems it solves, then maps them to the TheirStack signals a GTM team should run for outbound (technographics, hiring, buying intent), grouped by the offering each one pitches.
• Find look-alike companies from your won customers — Give it 4–5 closed-won customers. It profiles each one on TheirStack — what they run, hire for, and mention — extracts the customer fingerprint they share, and finds new companies that look just like them, saved as ready-to-use searches.
• Keyword research for job-description search — Give it a product or service URL. It derives the pains a buyer would describe in a job post, then iterates against real job postings — reading actual descriptions to learn the exact words companies use — and hands back keyword groups, each tied to a feature with a live job count.

All three run on the TheirStack MCP. Sizing every search is free; you only spend credits if you pull the actual companies. Copy any of them into your own setup and point it at a product URL.

Company Search now returns results noticeably faster. Across the searches we measured in production, queries run roughly 2-3x faster than before — so finding the companies you care about feels quicker, whether you're filtering by the technologies a company uses or by the jobs they're hiring for.

This applies everywhere Company Search runs: in the app, in your saved searches, in exports, and through the API. You don't need to change anything to benefit from it.

We also made the default ordering smarter. Results now come back sorted by relevance automatically, so the most relevant companies show up first:

• Filtering by technology → companies we're most confident use it come first.
• Filtering by jobs → companies hiring the most for what you searched come first.
• Both → most confident technology match first, then by hiring volume.
• Neither → larger companies first.

This new default applies automatically to existing API clients and saved searches too — no changes needed on your side. If you set your own sort order, that still takes priority.

When you look up a location, you no longer have to type it exactly the way our catalog stores it. Common variations — missing punctuation, dropped apostrophes, and plain typos — now resolve to the right city instead of coming back empty.

Before, small differences would return 0 results even when the city clearly existed. Now they just work:

• St Petersburg (no period) → resolves to St. Petersburg
• St. Petersburg, FL → ranks St. Petersburg, Florida first, ahead of the more populous Saint Petersburg in Russia
• coeur dalene (missing apostrophe) → resolves to the right city in Idaho
• los angelos, manchster, san fransico (typos) → resolve to Los Angeles, Manchester, and San Francisco

Adding a state also helps us pick the right match: when two cities share a name, the qualifier you type guides which one comes first.

This applies everywhere location lookup happens — autocomplete in the app, the /v0/catalog/locations API endpoint, and the MCP server. Exact and partial inputs are unchanged; we only step in to catch the variants that used to fall through.

Company Search can already filter companies by their job postings (title, location, posted date, technologies…). You can now also require that those jobs have specific fields set — most notably a hiring team.

This mirrors the property_exists filters we have in Jobs Search, but nested inside job_filters so it applies to the jobs a company is hiring for.

API

Pass property_exists_or (any of) or property_exists_and (all of) inside job_filters. Supported values: hiring_team, final_url, employment_statuses.

{
    "job_filters": {
        "job_title_pattern_or": ["Software Developer"],
        "posted_at_max_age_days": 15,
        "property_exists_or": ["hiring_team"]
    }
}

This returns only companies that have at least one matching job with a hiring team — perfect for finding accounts where you already know who to reach out to.

App

In Company Search add the Job property not empty filter (under Job Posting) and select Hiring Team.

You can now filter job searches by whether a posting is still open or has been closed.

When TheirStack detects a job is no longer live at its source, it records the date it went offline. The Job Closed filter lets you act on that date — show only closed roles, only open ones, or narrow to jobs closed in a specific window.

In the app

Open Job Search, click + Add Filter, and select Job Closed. Toggle between open and closed, or switch to a date range to find roles that went offline between two specific dates. The same filter is available in Company Search.

Try it: closed jobs in the last 15 days

In the API

Use is_closed, closed_at_gte, and closed_at_lte in the Jobs API:

curl -X POST https://api.theirstack.com/v1/jobs/search \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "is_closed": true,
    "closed_at_gte": "2026-05-01",
    "closed_at_lte": "2026-05-31",
    "posted_at_max_age_days": 30,
    "limit": 10
  }'

Available now in Job Search, Company Search, and the Jobs API.

There's a new dataset for closed job postings. Each record includes the job's standard fields plus closed_at — the date TheirStack detected the posting was no longer live at its source.

Files follow the same Parquet format and API as the existing jobs datasets, partitioned by the day the job closed. Request a specific date, a date range, or pull an incremental feed of jobs that closed today.

• closed_at — the day TheirStack first detected the posting was offline.
• Full job record — same schema as the daily jobs dataset: title, company, location, description, and more.
• Daily and hourly partitions — scope the download to exactly the window you need.

Learn more about how datasets work or how to access them.

You already get a webhook ping when a job matching your search is posted. Now you can get one when it closes.

Add job.closed to any job-search webhook alongside job.new. When a previously matched job goes offline, TheirStack sends a notification with the job ID and the date it closed — use the ID to pull the full job and company details whenever you need them.

More on how webhooks work in the webhooks documentation or see the job.closed reference.