Choose the contract first
Read authentication, dataset filters and error guidance before building the interface. Use the documented client version rather than guessing method names or response fields.
All use cases
REWALTO / FOR DEVELOPERS
Give your application data it can explain.
Developers use Rewalto to feed an application with India data it can explain: set explicit filters, keep the source and collection time with each result, and see the cost of every paid request before you approve it. The core API guide and the MCP server (preview) are the places to start.
THE DECISION COMES FIRST
Which records does this feature need, and what should happen when they are unavailable?
Start with a bounded question rather than a broad promise to your users. Check the catalogue for a Live entry, inspect its supported fields and confirm that its coverage fits your feature. API, CLI and MCP are access choices around the same data contract. They do not turn a Preview entry into available data. Design the empty state and cost confirmation alongside the successful response.
PLAN THE QUESTION
Try a workflow that fits your day.
Choose an example and the fields you need. This planner outlines a request without running it or spending credits.
Your workflow planner
Planning onlyNo credits used
Can we compare the same product across the sources and locations our user selected?
- Identify the exact product and pack size before comparing prices.
- Check that the chosen entry supports the required source, location and time filters.
- Keep source and collection time beside each returned price; show an explicit gap when a match is missing.
Choose the fields your question needs
A title match alone does not prove that two listings represent the same product.
REQUEST STRUCTURE / NO DATA LOADED
Make the scope easy to review.
| Product identifier | Pack size | Source | Pin code | Price | Collection time |
|---|---|---|---|---|---|
| No records loaded. Check catalogue coverage before requesting data. | |||||
Begin with public catalogue metadata. Use a server-held session or scoped key for a separate authenticated read.
Read API guidanceReview the planning brief
{
"audience": "For Developers",
"question": "Can we compare the same product across the sources and locations our user selected?",
"scope": [
{
"label": "Product scope",
"value": "One exact product and pack size"
},
{
"label": "Location",
"value": "Only supported pin codes chosen by the user"
}
],
"requestedFields": [
"Product identifier",
"Pack size",
"Source",
"Pin code",
"Price",
"Collection time"
]
}Changing this layout does not run research, collect data or create a watch.
FROM SCOPE TO DECISION
Make the work repeatable.
A useful result starts with a consistent scope and ends with a conclusion the data can support.
Keep access private
Keep API keys on your server. Give credentials only the permissions the feature needs. Show the published rate before a paid read; where no rate exists, show the quote and wait for approval.
Make uncertainty visible
Treat unavailable data, an empty result and a failed request as different states. Autonomous Finder research remains Coming soon until its connected capability is available.
CHECK BEFORE YOU START
Current data, current limits.
Availability, coverage and rates come from the catalogue. A planning example does not establish that the requested records are held.
Checking the published catalogue…
Coverage and prices are not substituted with example values. Review the catalogue before making a data request.
FOLLOW THE QUESTION
Useful next steps.
BEFORE YOU GET STARTED
Questions worth asking.
Do I see the cost before I pay?
Yes. A published rate is visible before a paid read, and a request without a published rate needs a quote and your approval. Connecting an agent does not start a paid run. The developer docs cover quotes and credits.
Does each result keep its source?
Yes. The source and collection time stay with each result, so your application can show where a value came from.
Is there an MCP server?
Yes, in preview. AI agents can connect to Rewalto's MCP server at mcp.rewalto.com/mcp, with the same data, credentials and credit rules as the API. The developer docs show how to connect.
Should I choose API, CLI or MCP?
Use the API for an application integration, the CLI for a documented command-line workflow and MCP for a supported agent connection. Check the current documentation for each; coverage and paid-data rules still apply.
Can I test with the examples on this page?
These are planning examples, not returned records or working credentials. Use them to define your inputs and error states, then inspect a Live catalogue entry before making a real request.
FROM A QUESTION TO USEFUL DATA