You import ten companies into a hiring research spreadsheet and get hundreds of job rows back. Someone counts the rows and reports hundreds of prospects. Someone else filters out records without a job title and accidentally deletes the companies that still need research.

Both mistakes start with the same data model: treating a company lookup and a job posting as the same kind of record. A company can have many postings, no observed postings, or an incomplete lookup. Your working tables need to represent all three without duplicating account counts or losing research tasks.

My Careers Page Scraper takes company domains and attempts to find their job boards. Here is how I would organize its export into a company table and a job table, then update them without overwriting useful evidence.

Give it domains first

Start with a short company list:

{ "domains": ["figma.com", "datadoghq.com"], "maxConcurrency": 2, "maxJobsPerCompany": 20 }

This is a valid example input based on the local input schema. It is not a claim about how many roles those companies have today. The Actor looks for ATS links on a company's careers pages and has documented fallback resolution for supported providers. A guessed board name is evidence to verify, not an identity you should trust because its endpoint returned HTTP 200.

The depth setting also needs interpretation. In the documented implementation, it controls paginated providers; some other providers return a board in one response. Do not treat maxJobsPerCompany as a universal hard cap on every possible output. Inspect the current Actor documentation when you need a strict downstream row budget.

For the first test, choose companies whose careers pages you can inspect yourself. Compare the resolved source with the company's own link. This gives you a concrete way to check the integration before you run a larger prospect or employer list through it.

Preserve the source identity

This reduced historical example comes from the product README. It describes an August 2026 observation, not a currently verified opening:

{ "companyDomain": "figma.com", "provider": "greenhouse", "providerSlug": "figma", "jobId": "5615966004", "title": "Enterprise Solutions Consultant (Bengaluru, India)", "location": "Bengaluru, India", "url": "https://boards.greenhouse.io/figma/jobs/5615966004?gh_jid=5615966004", "resolvedVia": "careers-page", "found": true, "scrapedAt": "2026-08-04T11:12:33.399Z" }

Keep companyDomain, the provider, the job identifier, and the source URL together. The domain tells you which company you asked about. The provider and identifier tell you which posting was observed. The URL lets a reviewer check the evidence without repeating the resolution process.

A useful downstream key can combine the company domain, provider, and job ID, provided you handle missing values explicitly. Retain the original URL too. ATS migrations can change identifiers and links, so even a carefully chosen key does not eliminate the need for occasional reconciliation.

Keep one row per company observation

In your company table, keep the requested domain, a collection identifier you assign, the observation time, the resolved provider, and the observed outcome. Derive that outcome from the actual source fields and diagnostic rows. The collection identifier is your own pipeline field, not an extra Actor input or a promised output field.

This table is where unresolved companies stay visible. Someone may need to inspect a careers link or check provider support. A confirmed empty board gets a different status, with its observation time preserved. Neither outcome needs a fake job row in your working job table.

A source failure belongs in the same company observation history and in an operational review queue. Avoid replacing yesterday's useful observation with a zero. If collection was partial, attach the coverage notice to that collection. A job count without its coverage state is easy to misread.

Finally, check attribution when the resolver used a guessed slug. Similar names can belong to different companies. The documented product includes attribution fields and billing safeguards, but your workflow should still preserve that evidence. A real vacancy at the wrong company is a bad match for your original question.

Keep jobs and decisions in their own tables

Only actual job rows belong in the job table. Link them back to the company domain and your collection identifier. Keep title, location, source URL, and source timestamps as imported evidence. Put candidate fit, account priority, and the next action in fields your team owns, so another import cannot erase a decision.

For candidate research, filter jobs by role and location, then check the employer's current page before applying. For account research, count distinct companies in the company table. An engineering vacancy is evidence of a published role; it does not establish a purchasing budget or prove that your service is needed.

Price the delivered jobs

The November 10, 2026 Store snapshot lists Free-plan event rates of $0.01 per Actor-start event and $0.004 per delivered job. Start-event count depends on Actor memory, with a minimum of one. Assuming one start event, 25 delivered jobs produce an event subtotal of $0.11; 100 jobs produce $0.41.

The snapshot describes confirmed empty boards, unresolved companies, unreachable sources, and coverage notices as free result rows. The separate start fee still applies. Check current Store pricing and your plan for the full billing context. These dated calculations do not promise a particular result count or a free run.

Update observations without rewriting history

Save the raw export before transforming it. On the next collection, append company observations and reconcile job identities separately. Compare counts only where the source identity and coverage are comparable. A posting absent from a partial collection should enter review without automatically being marked closed.

Start with the Careers Page Scraper, two domains, and a manual check of the resolved links. Before expanding the list, confirm that one company with several jobs still counts as one company in your report.

Disclosure: I maintain this Actor. This draft was generated with AI assistance from product documentation and a dated Store snapshot; no new live collection was performed for this article.