Today we're introducing Answers, a new Context.dev API that turns a question or research task into structured JSON with source URLs.
If you've built a feature that needs information from the web, you know how quickly a simple request becomes a workflow. A user asks which plans a company offers, whether a product supports a particular integration, or how two services compare. Your application has to find the right pages, read them, identify the relevant details, and turn what it learned into something the rest of your software can use.
Answers puts that research behind one endpoint: POST /v1/web/answers. You describe the task, optionally provide an example of the response you want, and choose a research mode. Context.dev searches the web, reads relevant pages, and assembles the answer.
That gives developers a direct way to add research to agents, internal tools, and customer-facing products. The result can become fields in a company record, rows in a comparison table, or context for the next step in a workflow.
Start with a specific question
A useful research request begins with a clear description of the information you need. For a pricing lookup, that could mean finding a company's pricing page and collecting the names of its publicly listed plans. For a product evaluation, it could mean checking whether the documentation describes a particular integration.
Include a domain or page URL in your task when you have a starting point. Then describe the desired output with json_format. Here is a complete request, with your API key stored in CONTEXT_DEV_API_KEY on your server:
curl https://api.context.dev/v1/web/answers \
--request POST \
--header "Authorization: Bearer $CONTEXT_DEV_API_KEY" \
--header "Content-Type: application/json" \
--data '{
"mode": "fast",
"task": "Find the pricing page and the names of the publicly listed plans for context.dev.",
"json_format": {
"pricing_url": "",
"plans": [{ "name": "" }]
}
}'The response places those requested fields inside json_content and returns contributing URLs in sources. Your application can read json_content.pricing_url and json_content.plans, then keep the source links alongside the result. The plan names come from the research, so your code does not need to hardcode them.
JSON that fits the next step
json_format is an example object. Its keys and placeholder values describe the structure you want back. In the request above, the empty string represents a text field, and the array describes plan entries with a name field. You can also describe numbers, booleans, nested objects, and other arrays. If you omit the example, Answers uses the default {"result": ""} shape. See the API reference for the full contract.
Choose fields around what your application will do with the answer. A comparison screen might need product names, supported integrations, and short explanations. An internal company record might need a product summary and a link to the company's documentation. Starting with that destination helps you keep the research focused.
Unknown values may be returned as null. Your application should preserve that distinction. A missing price and a price of zero mean different things; an unknown feature status should have its own display state. Treating those cases explicitly makes the output more useful to the person or system consuming it.
Fast for lookups, Ultra for deeper research
Answers offers two modes through the same endpoint:
| Mode | Best fit | Credits per successful answer | Research budget |
|---|---|---|---|
fast | Focused factual lookups | 10 | 30 seconds |
ultra | Deeper questions, comparisons, and multiple sources | 100 | 50 seconds |
Set mode explicitly in the request body so the choice is visible in your integration. The default is ultra. Fast is a useful starting point for a narrow lookup, such as locating a pricing page. Ultra gives a broader question more room for research, such as comparing the details of several offerings.
Successful answers consume the selected mode's credits, including answers that contain unknown values. Validation, research, and timeout failures are not charged. You can inspect the X-Credits-Used response header for the actual charge. The Answers guide explains mode selection and billing behavior.
Put research inside your workflow
Company research. An internal account tool could ask what a company sells, which audiences its website describes, and where to find its product documentation. Return those details in separate fields, attach the sources, and give your team a starting point for review. Keeping the request narrow also makes it easier to spot a missing or ambiguous answer before someone relies on it.
Product and pricing comparisons. A purchasing tool could research a small set of products and collect plan names, published pricing terms, and relevant feature descriptions. Define the same output fields for each product so the results can populate a consistent comparison view. Where pricing depends on billing period, usage, or a sales conversation, ask for that context explicitly and preserve unknown values.
Developer tools and support assistants. An assistant could research whether a service documents a particular capability and return a short explanation with relevant links. Your application can present that information for review or use it to guide a follow-up question. This is especially useful when finding the right documentation page is itself part of the task.
These workflows all benefit from a clear boundary around each request. Ask for the few facts needed to complete the next step. You can expand the research after inspecting an initial result, and your interface can make that progression visible to the user.
Keep the evidence with the answer
The sources array gives your application URLs that contributed to the research. Store those links with the answer and make them available wherever someone reviews the result. A company profile becomes easier to inspect when a reader can open its supporting pages directly.
A source URL can contribute a search snippet without its full page being read, and the source list does not assign a citation to each individual output field. Page reads request fresh content, while search snippets can reflect indexed material. Those details matter when your workflow depends on information that changes, such as pricing or feature availability.
For example, a comparison tool could show the research date and source links beside each result, then let a reviewer check a detail before accepting it. That gives users a practical way to follow the evidence and keeps the research understandable after it leaves the API response.
Choose how long to wait
Research also needs to fit your application's time budget. Answers supports timeoutOpts, which lets you set a deadline and choose whether usable partial work is acceptable. Add this object to a request body when you want to accept a partial result:
{
"timeoutOpts": {
"milliseconds": 30000,
"behavior": "return-partial"
}
}A successful partial answer follows the requested JSON shape and includes partial: true. It uses the evidence collected before research stopped and costs the selected mode's credits. Preserve that marker when saving or displaying the result so your application can explain that the research ended early. If no usable answer can be produced, the request fails without a charge.
The default behavior is fail. A caller deadline can shorten the mode's research budget; it cannot extend Fast beyond 30 seconds or Ultra beyond 50 seconds. Your HTTP client's timeout is a separate setting, so allow time for the response to arrive. The timeouts guide covers these controls in more detail.
How Answers fits into Context.dev
Answers is useful when your starting point is a question and discovering relevant information is part of the work. You describe the research task and the output you need, and the service chooses its research steps.
For extraction from a known starting URL with an explicit JSON Schema and controlled crawl scope, use Extract. That gives you a different set of controls for a workflow where you already know the source and need to collect defined fields from it.
The two can fit into the same application. You might use Answers to investigate a company and locate useful pages, then use Extract for a recurring operation against a selected source. Choose each step around the information you already have and the result your application needs next.
Make your first research request
Grab an API key from the dashboard, choose one question from your actual workflow, and start with a small output object. Run the request from your server, inspect the returned fields, and open the sources. Check how your application handles missing values before expanding the task.
The useful test is whether the result helps someone take the next step: review a company, compare a product, answer a support question, or decide what to investigate further. Shape the task around that action, then build from what you learn.
Answers is available now. Follow the guide to make your first request, or explore the endpoint reference for the request and response details.