V2 web intelligence

EnConvert V2 is a web intelligence layer that sits alongside the V1 conversion API: six endpoints that perceive, discover, search, extract, ingest, and monitor the web. They share one headless-Chrome render pipeline, your existing API keys, and the same allowed-endpoints allowlist as V1 — and they are metered on their own quota counters, so a V2 call never touches a single V1 conversion.

Here is the smallest useful call. Send a URL to /v2/perceive, get clean Markdown and the page's structured metadata back:

curl -X POST https://api.enconvert.com/v2/perceive \
  -H "X-API-Key: sk_live_your_private_key" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com/pricing",
    "outputs": ["markdown", "structured"]
  }'

The response carries a pre-signed download URL for the Markdown and the structured block inline:

{
    "operation_id": "per_3f9a2c1b8e7d4a6f90b1c2d3e4f5a6b7",
    "status": "completed",
    "url_final": "https://example.com/pricing",
    "render_quality": 0.93,
    "outputs": {
        "markdown": {
            "url": "https://spaces.example.com/...signed...",
            "size_bytes": 8421,
            "expires_in": 900
        }
    },
    "structured": {
        "metadata": {"title": "Pricing"}
    }
}

That is the shape every V2 endpoint shares: send JSON, get back a result inline or a short-lived signed URL to an artifact. The six endpoints differ in what they do with the render, not in how you reach them.

The six endpoints

Each endpoint collapses a stack of separate tools into one call against api.enconvert.com.

If you have used Firecrawl, the mapping is direct: /v2/lookup answers /search, /v2/distill answers /extract, and /v2/ingest answers /crawl.

How V2 relates to V1

V2 is purely additive. The V1 conversion endpoints — html-to-pdf, url-to-pdf, image conversions, document conversions — are unchanged and unaffected by any of this. You do not migrate to V2; you add it next to V1 when you need it.

The two halves share the parts that matter for integration:

• Same authentication. A sk_live_ private key in the X-API-Key header, or a pk_ public key exchanged for a JWT bearer token, works across V1 and V2 identically. See the authentication guide for the full flow, including domain locking and token refresh.
• Same key allowlist. Each API key carries an allowed-endpoints list. A V2 path that is not on the key's list is rejected with 403, exactly as a V1 path would be.

What they do not share is the meter. V2 endpoints are billed on their own counters, fully separate from V1's conversions_used:

A V2 call never decrements conversions_used, and V1-only conversion plans include zero V2 quota — a V2-inclusive plan is what carries these counters. Two endpoints are gated by a plan limit rather than a per-operation counter: /v2/discover is HTTP-only and stores nothing, so it rides a discover_enabled plan flag; /v2/watch is bounded by max_watchers — the cap on how many active watchers a project holds at once — together with the hourly minimum check cadence. Per-tier allowances for every counter and limit live on the pricing page.

Shared design choices across V2

The six endpoints are built on the same primitives, so a decision you learn once holds across all of them.

One render through a shared singleton. Every endpoint that needs a real browser — perceive, lookup's auto-perceive, distill, ingest, watch — renders through the same headless Chrome singleton and the same capture pipeline behind the V1 url-to-pdf endpoint. Cookie banners are dismissed, the page is scrolled to trigger lazy content, and images are given time to load. Discover is the deliberate exception: it never touches the browser at all.

Pre-signed download URLs. Binary and text artifacts (Markdown, HTML, screenshots, PDFs, the JSONL from ingest) are uploaded to storage and returned as a pre-signed URL — a short-lived, signed link to object storage that needs no separate auth to download. Every signed URL expires after 15 minutes (expires_in: 900). Re-fetch the operation or job to mint a fresh set; re-signing re-renders nothing and costs no quota.

SSRF protection on every URL. Before any fetch or render, each URL is screened — scheme, embedded credentials, blocked hostnames, and the resolved IP. A URL that resolves to a private, loopback, link-local, or cloud-metadata address is rejected with 400. This applies to seeds, crawled links, distill targets, and watch targets alike.

Render-quality scoring. Every render carries a render_quality score from 0.0 to 1.0. A low score flags a page that looks blocked by anti-bot protection or hidden behind a login wall, so you can tell a real capture from a challenge page. Watch goes further: a render below the 0.4 quality floor is recorded as audit-only and never becomes a diff baseline, so a one-off block does not fire a false change alert.

Credential-free where it counts. Perceive and distill accept auth, cookies, and custom headers for pages behind a login. Ingest and watch deliberately do not — their jobs are durable and recurring, so nothing secret is ever persisted to disk for a resume or a re-check. Need credentials for one page in an ingest set? Render it through the perceive endpoint instead.

Honest "reserved, not yet live" handling. Where a parameter is accepted by the schema but not yet wired up, V2 tells you so rather than silently ignoring it. Perceive's proxy_url, geolocation, and action_chain return 422 today; its prices, contacts, and technologies extract names land in warnings and are dropped. You always know which knob is not ready.

Beta. V2 is in beta. Pin your integration to the documented field names and status codes, read warnings on every response, and expect response fields to gain shape — though not break — before V2 leaves beta. New fields may appear; documented ones will not silently change meaning.

What's next

To be straight about it, V2 is not finished. Three capabilities are on the roadmap and not available yet — do not build against them:

• Browser automation — a /v2/pilot and /v2/conduct pair for multi-step interaction (click, type, navigate) rather than the single-shot render the current endpoints do. The request and response shapes are not settled, so they are not documented here.
• Extraction feedback — an endpoint to correct a distill result and feed the correction back into future extractions. Named, not shipped.

When these land they get their own reference pages, the same way the six endpoints above do. Until then, the current six are the whole surface — anything you read here about pilot, conduct, or feedback is a roadmap note, not a contract.

Quickstart

Reach for the right endpoint by the shape of the job:

• Render one page → start at the perceive endpoint.
• Map a site's URLs → start at the discover endpoint.
• Search the web → start at the lookup endpoint.
• Pull structured fields → start at the distill endpoint.
• Build a RAG corpus → start at the ingest endpoint.
• Monitor for changes → start at the watch endpoint.

If you have not made a first call yet, the quick-start guide walks through getting a key and running one request end to end. Every endpoint page opens with its own smallest useful curl call, so you can paste one and have a real response back inside a minute.