DEV Community: agenticemail.dev

Job postings are the earliest buying signal your GTM stack ignores

agenticemail.dev — Mon, 13 Jul 2026 06:07:20 +0000

A company's marketing site tells you what it wants you to believe. Its job postings tell you what is actually true. Nobody writes "experience with Kafka, Snowflake, and dbt required" into a job ad as branding; they write it because a hiring manager needs someone who can operate the stack they really run.

That makes job postings one of the best technographic and intent data sources available, and it is almost entirely ignored by the standard GTM stack. This post covers what you can extract from hiring data, where the extraction goes wrong, and how to build a pipeline for it.

What a job post leaks

The current stack. Requirements sections enumerate the production stack more honestly than any tech-detection crawler. Website-based technographics tools (BuiltWith, Wappalyzer, and their alternatives) see what ships to the browser: the analytics snippet, the framework, the CDN. They cannot see Datadog, Terraform, Snowflake, Airflow, or anything else that lives behind the firewall. Job posts name those tools constantly.

The next stack. "Nice to have" sections and phrases like "help us migrate to" leak roadmaps. A company posting three roles mentioning Kubernetes when its current infra jobs say ECS is telling you about a migration before any analyst report does.

Initiatives before announcements. The first "Head of AI" posting, the first security engineer, the first hire in a new country. Each is a strategic decision that became public the moment someone needed to staff it.

Timing. This is the part sales teams care about. Content-based intent providers (Bombora, 6sense, ZoomInfo) detect an account researching a category, which happens when the evaluation is already underway. Hiring for a role that will use your product happens earlier: the budget exists, the initiative is committed, and the person who will run the evaluation has not been hired yet. Hiring signals typically fire one to two quarters before content intent lights up on the same account.

Where naive extraction goes wrong

If you grep descriptions for tool names, you will poison your data in three ways I know from experience:

Negation and direction. "Migrating away from Oracle" is a churn signal for Oracle and a buy signal for its competitors. A keyword match reads it as Oracle usage. You need at least phrase-level context around every hit.

Ambiguous tokens. "Go", "R", "Ray", "Spring", "Flow". Short names need co-occurrence rules ("Go" plus "goroutines" or "Golang") or you will conclude that every logistics company runs Golang because their ads say "go the extra mile".

Comparison mentions. "Experience with Datadog or similar observability tools" confirms the category, not the vendor. Treat "or similar" and "such as" lists as category-level evidence, weaker than a bare "we use Datadog".

The unit of belief should be company-level with decay, not posting-level: a tool mentioned across five postings over six months is stack; a tool mentioned once in one ad might be one manager's wishlist.

Building the pipeline

You need two inputs: a stream of job postings you can filter by description text, and a way to check the visible web stack of the same companies so the two signals corroborate each other.

For the postings side, I work on JobsPipe, which aggregates 30+ ATS feeds and job boards into one normalized search endpoint. Finding every company that posted a job mentioning your target technology in the last two weeks is one call:

curl -X POST "https://api.jobspipe.dev/v1/jobs/search" \
  -H "Authorization: Bearer jp_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "description_or": ["Kubernetes", "EKS", "GKE"],
    "posted_at_max_age_days": 14,
    "include_total_results": true,
    "limit": 50
  }'

Each result is a normalized posting with company, job_title, country_code, date_posted, and final_url, so the output drops straight into an enrichment table keyed by company.

For the website side, the same API has a stack scanner that fetches a domain and returns detected technologies:

curl -X POST "https://api.jobspipe.dev/v1/stack/scan" \
  -H "Authorization: Bearer jp_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"domain": "stripe.com"}'

The interesting analysis lives in the difference between the two views. A company whose website scan shows Segment while its job posts mention Snowflake and dbt has a modern data stack that no page-source crawler would ever report. A company hiring "our first data engineer" with no warehouse mentioned anywhere is a greenfield account for every vendor in that category.

A concrete scoring sketch

For a vendor selling, say, observability tooling, a workable v1 score per account:

Category hire in the last 90 days (SRE, platform engineer, DevOps): strong, this person will run the evaluation.
Competitor named in "we use" context: medium, displacement play with a known incumbent.
Competitor named in "or similar" context: weak, category confirmed, vendor open.
Stack scan shows the category is absent from their visible tooling: greenfield modifier.
Three or more engineering postings in 30 days: growth modifier, budget is moving.

None of this needs ML to start. It needs clean, deduplicated, fresh postings data with searchable descriptions, which is the part that is genuinely painful to build yourself (I wrote up the per-ATS details in a separate post on public ATS feeds).

JobsPipe has a free tier at jobspipe.dev (100 requests/month), docs here, and an open-source CLI if you want to pipe results into a spreadsheet before writing any code. If you are building sales-intel, recruiting tools, or market research on top of hiring data, I would genuinely like to hear what signals you wish existed.

Every major ATS has a public job feed. Here is how to read them all.

agenticemail.dev — Mon, 13 Jul 2026 06:04:40 +0000

Most job-board data products are built on scraping HTML. That is the hard way. Nearly every applicant tracking system that powers a company careers page also exposes a public JSON or XML feed, because the career page itself is just a client of that feed. If you know where the feeds live, you can read most of the world's job postings without parsing a single div.

I have spent the last year building integrations against these feeds for JobsPipe, and this post is the field guide I wish had existed when I started: the actual endpoints, the quirks of each, and the parts that stay hard even after you know the URLs.

The endpoints

All of these are public and unauthenticated. They exist so that companies can embed job widgets on their own sites, which means they are stable, documented (sometimes), and legal to read.

ATS	Endpoint pattern	Format
Greenhouse	`boards-api.greenhouse.io/v1/boards/{token}/jobs`	JSON
Lever	`api.lever.co/v0/postings/{slug}?mode=json`	JSON
Ashby	`api.ashbyhq.com/posting-api/job-board/{name}`	JSON
SmartRecruiters	`api.smartrecruiters.com/v1/companies/{id}/postings`	JSON
Workable	`apply.workable.com/api/v1/widget/accounts/{account}`	JSON
Recruitee	`{company}.recruitee.com/api/offers/`	JSON
Personio	`{company}.jobs.personio.de/xml`	XML
BambooHR	`{company}.bamboohr.com/careers/list`	JSON
Workday	`{tenant}.myworkdayjobs.com/wday/cxs/{tenant}/{site}/jobs`	JSON, POST

A few worked examples.

Greenhouse is the friendliest. One GET per board, and content=true inlines the full HTML description:

curl "https://boards-api.greenhouse.io/v1/boards/stripe/jobs?content=true"

Lever returns a flat array with the description split into structured lists:

curl "https://api.lever.co/v0/postings/netflix?mode=json"

Ashby will even give you structured compensation if the company opted in:

curl "https://api.ashbyhq.com/posting-api/job-board/openai?includeCompensation=true"

Workday is the strange one. There is no documented public API, but every Workday career site is a single-page app talking to a JSON endpoint you can call directly:

curl -X POST "https://{tenant}.wd5.myworkdayjobs.com/wday/cxs/{tenant}/{site}/jobs" \
  -H "Content-Type: application/json" \
  -d '{"limit": 20, "offset": 0, "searchText": ""}'

The quirks

Every feed has at least one.

Dates lie in different ways. Lever gives you createdAt in epoch milliseconds. Greenhouse gives you updated_at, which changes when anything about the post is edited, not when it was published. Workday gives you postedOn as a human string like "Posted 3 Days Ago", so your freshness logic ends up parsing English.

Pagination is five different ideas. Greenhouse returns everything in one response. SmartRecruiters uses limit and offset. Workable's newer endpoint uses an opaque continuation token. Workday uses offset paging but silently caps how deep you can go on some tenants. Personio is one big XML document.

Location is unstructured almost everywhere. You will see "Remote - US", "New York / London / Remote", "EMEA", and my favorite, an empty string on a posting that is very much in San Francisco. If you need country-level filtering you are building a location resolver, not reading a field.

Compensation is in the description. Outside of Ashby's opt-in field and pay-transparency jurisdictions that force structure, salary lives in free text: "up to $185k", "£70,000 - £90,000 DOE", "competitive". Extracting it reliably is an NLP problem, not a regex.

The part that stays hard

Knowing the endpoints gets you one company's jobs. The actual work is everything above that:

Tenant discovery. The endpoint needs a board token or slug, and there is no directory of them. You find tenants by noticing that careers links point at boards.greenhouse.io/{token} or jobs.lever.co/{slug}, by crawling sitemaps, and by watching for companies that migrate ATSs (they do, constantly, and their old feed keeps serving stale jobs).

Normalization. Nine sources means nine schemas for title, location, department, employment type, and date. A "Senior Backend Engineer (m/f/d)" in a Personio XML feed and a "Sr. Backend Engineer" in a Greenhouse JSON feed need to become the same shape before your queries mean anything.

Deduplication. The same role appears on the company's ATS feed, on Indeed, on LinkedIn, and on three regional boards. If you count postings without cross-source dedup, your "who is hiring" numbers are fiction.

Freshness. Feeds do not push. You are polling tens of thousands of tenants on a schedule, diffing results, and deciding what "closed" means when a job just disappears.

If you would rather not maintain all this

This is exactly the layer JobsPipe sells. We crawl the public feeds of 30+ ATSs and job boards (all of the above plus iCIMS, Taleo, SuccessFactors, Teamtailor, ZipRecruiter, and others), normalize everything to one schema with resolved countries and parsed salary ranges, dedupe across sources, and serve it as a single REST endpoint:

curl -X POST "https://api.jobspipe.dev/v1/jobs/search" \
  -H "Authorization: Bearer jp_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "job_title_or": ["data engineer"],
    "job_country_code_or": ["US"],
    "remote": true,
    "posted_at_max_age_days": 7,
    "limit": 20
  }'

Every result comes back in the same shape regardless of whether it started life in a Workday tenant or a Lever board: job_title, company, location, country_code, remote, seniority, date_posted, final_url.

There is a free tier (100 requests/month, no code required beyond the curl above), API docs here, an open-source CLI and agent skill on GitHub, and an MCP server at jobspipe.dev/mcp if you want your coding agent to query it directly.

And if you would rather build the crawler yourself: the table above is a real starting point, and honestly, it is a fun problem for about the first six ATSs. It is the 25th one that gets you.

Give your AI agent a real inbox

agenticemail.dev — Mon, 06 Jul 2026 06:44:59 +0000

Your agent can reason, call tools, and hold a conversation. Then you ask it to handle email, and everything gets awkward. Email was built for a human sitting in front of a mail client, not for software. To make an agent "do email" today, most teams reach for one of two bad options: screen-scrape a Gmail account a human set up by hand, or bolt SMTP for sending onto IMAP for receiving and hope the OAuth tokens survive the night.

This post first appeared on the AgenticEmail blog.

The problem: email was built for humans, not agents

The moment you need two-way email - an agent that emails a customer and then reads the reply - you are wiring together three protocols that were never meant to be glued: SMTP to send, IMAP to poll, and OAuth to keep a borrowed human account alive.

That stack breaks in predictable ways. OAuth tokens expire and a refresh fails at 3am. IMAP is pull-based, so your agent sits in a polling loop diffing message lists instead of reacting to events. Inbound mail arrives as raw MIME - nested multipart bodies, quoted-printable encoding, base64 attachments - so your agent needs a MIME parser before it can read a single sentence. And because everything hangs off one shared mailbox, you cannot give each agent, or each of your users' agents, its own address without provisioning real mailbox seats.

None of this is the interesting part of your product. It is undifferentiated plumbing standing between your agent and the thing you actually want it to do.

The fix: an inbox is an API resource

AgenticEmail treats an inbox the way you already treat a database row. You create one with an API call, it has a stable id, and you send and receive through plain REST. No mail server to run, no IMAP loop, no OAuth dance. Inbound mail arrives already parsed into JSON, threaded into conversations, and pushed to you over a webhook or a WebSocket - or exposed to your model directly through a hosted MCP server.

Here is the whole loop.

1. Create an inbox

One POST gives your agent a live, addressable inbox:

curl -X POST https://api.agenticemail.dev/v1/inboxes \
  -H "Authorization: Bearer $AGENTICEMAIL_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "username": "billing-agent" }'

The response carries an id and a working address like billing-agent@inbox.agenticemail.dev. On paid plans you attach your own domain and it becomes billing-agent@yourcompany.com. Because provisioning is a single call, you can mint an inbox per agent, per user, or per task at runtime. Identity stops being a bottleneck.

2. Send

Sending is one call against the inbox. Pass recipients and a body; threading headers are handled for you:

curl -X POST https://api.agenticemail.dev/v1/inboxes/ibx_123/messages/send \
  -H "Authorization: Bearer $AGENTICEMAIL_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "to": ["customer@example.com"],
    "subject": "Your July invoice",
    "text": "Hi - your invoice for July is attached. Reply here with any questions."
  }'

3. Receive parsed, threaded JSON

When someone replies, you never touch MIME. List the inbox and every message comes back as a flat object with from, to, subject, text, html, and attachments, already grouped into threads:

curl https://api.agenticemail.dev/v1/inboxes/ibx_123/messages \
  -H "Authorization: Bearer $AGENTICEMAIL_API_KEY"

{
  "data": [
    {
      "id": "msg_456",
      "thread_id": "thr_789",
      "direction": "inbound",
      "from": "customer@example.com",
      "subject": "Re: Your July invoice",
      "text": "Got it, thanks. Can you resend with the PO number?",
      "created_at": "2026-07-05T12:00:00Z"
    }
  ],
  "next_page_token": null
}

The thread_id ties the reply back to what you sent, so your agent gets the whole conversation as structured context - not a screenshot, not a raw .eml file it has to decode.

4. React over a webhook or an MCP tool call

Polling is optional. Register a webhook once and every inbound message is delivered to your endpoint as a signed JSON payload the instant it lands:

curl -X POST https://api.agenticemail.dev/v1/webhooks \
  -H "Authorization: Bearer $AGENTICEMAIL_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "url": "https://your-app.com/hooks/email", "event_types": ["message.received"] }'

If your agent has no public URL - a local script, a serverless job, a notebook - subscribe to the WebSocket stream at wss://api.agenticemail.dev/v1/events instead and get the same payloads pushed to an outbound connection. Both paths are covered in the email webhook guide.

Or skip the plumbing entirely and let the model drive. The hosted MCP server exposes the whole API as native tools:

{
  "mcpServers": {
    "agenticemail": {
      "url": "https://api.agenticemail.dev/mcp",
      "headers": { "Authorization": "Bearer ${AGENTICEMAIL_API_KEY}" }
    }
  }
}

With that in place, your agent calls create_inbox, send_message, get_thread, and reply_to_message the same way it calls any other tool. "Create an inbox for onboarding, email new@example.com a welcome, and reply when they respond" becomes a single turn.

Scoped keys keep the blast radius small

An agent should never hold god-mode credentials. AgenticEmail keys are scoped: you can pin a key to a single inbox and a specific set of permissions, so a key that leaks - through a prompt injection, a logged header, a compromised dependency - can at worst read and send from its own inbox. It cannot touch your other inboxes or your account. Give each agent its own inbox and its own scoped key, and a bad day stays contained to one address.

Works with any MCP client

Because the integration is REST plus a standard MCP server, it is framework-agnostic. Claude, Cursor, and any other MCP-compatible client pick up the tools from the config above. In agent frameworks like LangChain, use the official SDKs or call the REST endpoints directly. There is nothing email-specific for your stack to support - it is just HTTP and a tool list.

Give your agent a real inbox

Two-way email should not be the hardest part of shipping an agent. Create an inbox with one call, send and receive as parsed JSON, react over a webhook or an MCP tool call, and scope the key so a leak is a shrug instead of an incident.

Start free at agenticemail.dev, connect the MCP server from the MCP docs, or read the full endpoint reference in the docs.