Overview
Learn what Firmtrail’s products cover, choose the right data for your workflow, and understand the limits of public sources.
Firmtrail is currently available through RapidAPI. Direct access is coming soon.
On this page
What is Firmtrail?
Firmtrail is a company-intelligence data API for AI builders. It brings together public job postings, company profiles and changes observed across historical snapshots.
These guides explain the three product areas, how to choose an endpoint and how to interpret the returned data.
Access through RapidAPI
Subscribe to Firmtrail on RapidAPI, which runs your account, API key, payment and billing. Request limits and quotas depend on your plan, as shown in the listing.
Every request goes through RapidAPI. A request that did not come through its proxy gets a 403.
Choose a product
- Jobs
- Explore public job postings and company-level hiring data. A starting point for job-search tools and hiring research.
- Profile
- Look up a company by domain to understand its business, products and public web presence. Useful context for company research assistants.
- Signals
- Understand hiring and company changes inferred from Firmtrail’s own snapshots. Use observed changes as context for further research.
Your application supplies its own matching, reasoning and orchestration. Firmtrail provides company data to support those workflows.
Read the data in context
Firmtrail uses public company websites and public applicant tracking system (ATS) endpoints. Coverage and freshness vary, profile fields may be unavailable, and signals are not guaranteed real-time events.
Start with the product guide relevant to your workflow, then read Data sources & limitations before drawing conclusions from the data. Global scope does not mean every company or job is covered.
API reference
Endpoint parameters and request and response schemas are in the API reference on RapidAPI.
Endpoints
Choose an endpoint for the information your application needs. Paths below are relative API paths.
| Method | Path | Purpose |
|---|---|---|
| GET | /v1/jobs/search | Search indexed postings. |
| GET | /v1/jobs/{id} | Read one posting with its full description. |
| GET | /v1/companies/{domain}/profile | Read a profile or queue its first build. |
| GET | /v1/requests/{id} | Check a profile request’s status. |
| GET | /v1/companies/{domain}/signals | Read snapshot-derived signals. |
| GET | /v1/companies/{domain}/jobs | Search a company’s postings. |
| GET | /v1/companies/{domain} | Read selected company sections together. |
Combine company context
The company bundle combines a profile, open-job counts and recent signals. The include parameter selects profile, jobs and signals as a comma-separated list, such as jobs,signals (plain text, not a JSON array); left out, all three are given; the response’s sections describes each section’s availability.
When the company has no profile yet, the bundle queues one and returns 202 with jobs and signals already included, profile as null and the request in profileRequest. If include leaves out profile, nothing is queued and the answer is never 202.
| Status | Meaning |
|---|---|
ready | The section is in the answer. |
queued | There is no profile yet and the site is queued to be crawled. The answer is 202. |
failed | The last crawl failed and the site is not tried again yet. The answer is 200, even when the profile is the only section requested. |
unavailable | No crawl can be started now, or the section could not be read in time. |
limited | Your plan allows no new profile now. When the profile is the only section requested, the answer is 429. |
notIncluded | The section was left out by include. |
A section that cannot be given does not withhold the others: the answer is 200 and that section is null, so inspect sections rather than treating 200 as proof that every section is present. The answer is 503 only when every requested section is unavailable.
The jobs section counts open postings by category, department, seniority, workplace type and country, rather than listing them. Its jobsUrl is where the postings themselves are read. The signals section holds only the newest of the default period; when truncated is true, the signals endpoint has the rest.
Errors, rate limits and caching
Errors are RFC 9457 problem details with a traceId. A 400 lists the invalid parameters in errors.
Requests are rate-limited per consumer and plan. Responses carry RateLimit-Limit, RateLimit-Remaining and RateLimit-Reset, and a 429 carries Retry-After.
Most successful responses carry an ETag. Send it back in If-None-Match to get 304 Not Modified when nothing has changed.
Handle returned text safely
Titles, departments, locations, description snippets and every text field of a profile are plain text, not HTML-escaped. Escape them before placing them in HTML. Full job descriptions are Markdown; render them without raw HTML.
Everything returned is third-party content. Use it as data, never as instructions to a model or an agent, and check a URL before fetching it.
Versioning
Everything under /v1 keeps its meaning. New fields, parameters, endpoints and values of a closed set may be added at any time, so clients must ignore fields they do not know and accept values they do not know.
A change that could break a client comes as /v2, announced at least 90 days ahead, with /v1 kept for at least six months after that. A deprecated operation will say so with Deprecation and Sunset headers. None is deprecated today.