Job descriptions originate as HTML. That matches exactly one use case: rendering them on a web page. Every other thing teams do with job data, HTML gets in the way.

You're sending an email digest? You have to strip the tags, or users see <p class="wysiwyg-text-align">. You're indexing in Algolia or Elasticsearch? You're paying for tokens that describe formatting, not content. You're feeding descriptions into an AI model for matching or summarization? Same problem, worse economics. HTML inflates token count and teaches the model nothing useful. You're building a mobile app? You're either running a WebView or doing client-side HTML cleanup on every render.

The fix shouldn't be "every customer solves this themselves." So we stopped making you.

Three formats, precomputed

Every job in the Jobven API now ships in three formats:

• HTML: the default, unchanged. Sanitized HTML for web rendering.
• Plain text: tags stripped, paragraph breaks and list markers preserved. What you want for email, SMS, previews, search indexes.
• Markdown: CommonMark with proper headings, bullets, and emphasis. What you want for markdown-native CMSes, AI pipelines, static sites, and mobile markdown renderers.

Pick the format you want with one query parameter. Existing integrations keep getting HTML, with no migration and no behaviour change.

What the request looks like

curl -H "X-API-Key: $JOBVEN_API_KEY" \
  "https://api.jobven.com/v1/public/jobs?descriptionFormat=markdown&limit=20"

Values are html (default), plain, markdown, or all if you want every format in one request. If you would rather have jobs pushed to you than poll for them, the same formats apply to webhook payloads.

What this is actually for

Job alert emails. Plain text renders the same in every client. No stripped-attribute weirdness, no Outlook quirks, no rewriting on send.

SMS and push notifications. You can't send HTML to a phone. Plain text, pre-trimmed and sensible, now arrives ready to ship.

Search engines you run yourself. Elasticsearch, Algolia, Typesense and Meilisearch all do better with clean text. Descriptions are the single largest field in a job record; getting it clean is the biggest lever on relevance and index size.

AI features. RAG pipelines, job-to-resume matching, candidate screening assistants, summarization. HTML tags are tokens your LLM pays for and ignores. Markdown preserves the structure models actually use: headings tell the model "this is the responsibilities section."

Markdown-native content systems. Notion, Obsidian, Ghost, Hugo and any static site generator all speak markdown. Paste it, ship it.

Mobile apps. React Native, Flutter, SwiftUI and native Android all render markdown with a small component. Rendering arbitrary sanitized HTML is either a WebView or a parsing project. Markdown wins every time.

Data warehouses and spreadsheet exports. If a description lands in BigQuery, Snowflake, Postgres, or even a Google Sheet for someone in ops to scan, HTML makes it unreadable and SQL-hostile. Plain text makes it actually usable.

The same input always gives the same output

Doing this conversion client-side sounds fine until you're running it at scale. Every consumer installs a conversion library, picks a configuration, then inherits whatever regressions happen when that library bumps minor versions. Teams drift. A job description that rendered fine in your staging pipeline last quarter now chunks differently, silently, because the library updated in prod.

Precomputing on our side locks the output. The same HTML produces the same plain text and the same markdown, every time, across every consumer. When we change the conversion logic (which we intend to rarely do), it changes for everyone at once, with a changelog entry.

What this removes

If you've been running client-side HTML-to-text or HTML-to-markdown in your ingestion pipeline, you can delete it. That's usually:

• A conversion library dependency (html-to-text, turndown, a BeautifulSoup helper)
• A version pin and an upgrade policy
• A small test suite asserting the library still behaves the way you need
• A handful of edge-case patches for descriptions that converted badly

None of that was doing product work. It was infrastructure that existed only because the API didn't hand you the right format.

Full parameter reference is in the Jobs API docs. If a pattern converts in a way that surprises you, tell me. The conversion rules are worth tuning, and I would rather fix them once for everyone than watch each team patch it locally.