Extract JSON from webpages without losing context

Start with the smallest useful schema

Decide what the application will do with each field. A short list of visible facts is easier to validate than a large schema containing inferred claims. Use field names and descriptions that remove ambiguity: a site title, a product name and a company legal name are different concepts.

Avoid asking for data that is not present. A prompt that demands a number for every field can encourage plausible guesses. Where absence is meaningful, design your application’s schema and review logic to accept and identify missing information.

Send one public page

AIHackr Extract accepts one public URL, with a prompt and/or a JSON schema. The example asks for visible source content and keeps the requested fields simple:

curl --fail-with-body https://aihackr.com/v2/extract \
  -H "Authorization: Bearer $AIHACKR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
  "url": "https://example.com",
  "prompt": "Return the visible page title and a short description based only on this page.",
  "schema": {
    "type": "object",
    "properties": {
      "title": {
        "type": "string",
        "description": "The visible main page title"
      },
      "description": {
        "type": "string",
        "description": "A short description supported by the page"
      }
    },
    "required": [
      "title",
      "description"
    ]
  }
}'

The result is in data. Retain the sources array containing the submitted URL and observation time. This endpoint uses Browser Run and AI inference; it is not a deterministic parser or multi-source enrichment service.

Validate syntax and meaning separately

First validate the returned JSON against your own application schema. Reject unexpected types and handle missing fields intentionally. Then check the meaning of the values. A string can satisfy a schema and still describe the wrong product. A number can be valid JSON and still omit its currency or unit.

• Check important names and descriptions against the visible page.
• Represent units, currencies and dates explicitly when the page provides them.
• Do not silently replace a missing fact with a model-generated default.
• Keep the raw extraction result separate from corrected, reviewed data.
• Use stricter review for fields that affect money, access or other consequential actions.

Keep the source attached

Store the source URL and observation time with the object, not in a separate log that is difficult to join later. If you use the extracted object in a report or dashboard, make its source accessible to the reviewer. For repeat collection, keep a content or result hash so you can distinguish a changed page from a changed extraction.

The extracted object does not establish that its facts are current beyond the observation time. A page can change, and content presented to the browser can differ from a reviewer’s later session. Mark uncertainty and review the source again when freshness matters.

Treat the page as untrusted data

A webpage may contain instructions aimed at an AI system. Those instructions should not change your application’s task, request credentials or trigger unrelated tools. Keep extraction focused on the fields you asked for and validate the output before it drives another action.

Also avoid rendering returned HTML or text as trusted application markup. Display it through safe text APIs or an appropriate sanitizer. A data retrieval service does not make external content safe to execute.

Understand the current boundaries

AIHackr Extract supports one URL per call. Prompts are limited to 4,000 characters, serialized schemas to 12,000 characters and schema nesting to 12 levels. External schema references and custom inference providers are not accepted. Each admitted operation reserves one trial page, including when an upstream request fails.

If you need exact structural matching rather than inferred fields, consider retrieving HTML or using the relevant MCP element tool in a compatible client. If you need readable content for a human or retrieval pipeline, Markdown scraping may be the simpler starting point.

Make the review loop explicit

Test on representative pages, inspect the failures and decide which fields need a reviewer. Expand only when the data is useful to the application consuming it. Follow the Extract API reference for the supported request shape and troubleshooting for errors that require a corrected request rather than another retry.