Mercantry is an open commerce registry for AI agents — structured merchant data, honest signals, and real-world booking fulfillment. This page states what data the service holds, where it comes from, and what happens to it. It is written for both humans and agents.
Draft — pending legal review. This page describes the service accurately as built, but it has not yet been reviewed by counsel and is not offered as a final legal notice. It is marked noindex until that review completes.
Mercantry serves a registry of merchant records to AI agents over MCP and REST. Reads are free — anonymously, or with a self-serve API key. Booking fulfillment, where live, places a real reservation with a merchant on a caller's behalf. There is nothing to buy and no payment data is ever collected.
Merchant data (the registry itself)
No release has been imported into this deployment yet, so this is the set of sources the ingestion pipeline is licensed to use (declared in code); the served list appears here once a release is imported:
fehd_hk Hong Kong FEHD list of licensed general restaurants
data.gov.hk Terms of Use (free re-use with attribution)
la_open_data City of Los Angeles — Listing of Active Businesses (NAICS 7225*)
CC0/Public Domain (data.lacity.org open data terms)
tokyo_opendata Tokyo ward + TMG food-business licence ledgers via catalog.data.metro.tokyo.lg.jp CKAN search
CC-BY-4.0 (東京都オープンデータカタログ; per-dataset terms verified at ingest)
wikidata Wikidata labels/aliases (local-language names), restaurant-family items via WDQS
CC0-1.0
Every field carries per-field provenance. The registry adds no scraped reviews, no scraped social content, and no data from platforms whose terms forbid it.
Records may contain business contact details — a listed phone number, for instance — which can be personal data for a sole proprietor. Source data is served as the source publishes it; corrections come from direct phone contact with the merchant.
Merchant opt-out is immediate and permanent: ask via https://github.com/mercantry/registry/issues or tell the operator on any call. An opted-out record is retained but excluded from every read, search, export and booking path, and imports never re-list it.
Records are never deleted by an import — a merchant that disappears from a source keeps its row, so provenance stays auditable.
Data about API users
Keys are optional; reads work without one. Minting a key (POST /v1/keys) stores exactly these columns:
Column
What it holds
key_id
an opaque identifier for the key (this is what a booking is attributed to)
api_key
the key value itself, stored as issued so a presented key can be matched — treat it as a secret
developer_name
the name you supply when minting the key
contact
the contact you supply when minting the key (an email or URL; personal if you supply a personal one)
webhook_url
the optional webhook URL you supply
no_show_count
a counter of bookings this key did not honor
throttled
whether the key is currently throttled for abuse
created_at
when the key was issued
created_ip
the IP address the mint request came from, used to enforce the per-IP minting cap
No request log is written. The service runs no HTTP access logger: requests are not recorded per-caller, and read queries are not retained.
Rate-limit counters live in memory only, keyed by API key or client IP, and expire within a minute of their window. They are never written to the database.
Unhandled server errors are printed to the host's process log, which can include the request path and the error text.
No cookies, no analytics, no third-party trackers, no advertising, and no sale or sharing of user data. Keys exist for rate limiting and abuse control, not profiling.
Booking data
A booking row stores what fulfillment needs: the merchant, requested time and window, party size, the reservation name, an optional contact for confirmation relay, optional special requests, an optional callback_url, an optional client_reference_id you supply, an optional sandbox_outcome (a test-only instruction, never personal data), and the key the booking was made with. Every state transition is timestamped in an append-only event log, and call attempts store the operator, the disposition and the call's transcript lines.
Reservation names and contacts are used only to place and follow up that booking. They are never exposed through any read tool, never included in search results, and never part of any export or dataset release.
Real-merchant fulfillment is not live yet — place_booking against a real merchant returns fulfillment_not_live, so no reservation details reach any real merchant today. Sandbox bookings are simulated end-to-end and never dial anyone.
Calls are not recorded. The service captures no audio anywhere. Transcript rows hold text lines — today only from simulated sandbox calls — and human calls record a disposition and the operator's notes.
If you supply a callback_url, booking state changes are sent to that URL — you choose that recipient.
Operator notifications are not enabled on this deployment. When they are, a real booking needing a human call posts the merchant details, requested time, party size and your special_requests text as an issue in a private repository on GitHub — the reservation name is deliberately excluded and stays in the authenticated console.
Feedback is accepted only against a confirmed booking, once, within 14 days, and concerns the transaction rather than any individual.
Retention: booking rows, their event log and issued keys are kept indefinitely — the service runs no automatic deletion job, so the honest statement is that nothing expires on its own. Deletion on request is covered below.
Sharing, and where this runs
Bulk export of merchant records is a feature, not a leak: the corpus is openly licensed and downloadable by design (/v1/export/merchants.ndjson). Key data and booking data are never part of any export or dataset release.
Infrastructure: the service runs on Fly.io (region sjc); source code and the issue tracker are on GitHub. Outbound data flows are only the ones named above: your own callback_url, and operator-notification issues when that is enabled.
The registry serves records from more than one jurisdiction, and its cross-border posture is part of a pending legal review. Nothing in the calling specification operates until that review completes; this page will be updated with the outcome rather than quietly revised.
Your choices
Merchants: opt out permanently, or ask for a correction, via https://github.com/mercantry/registry/issues. Opt-out is applied by end of business day and honored on every future import.
API users: stop using a key and request its deletion via https://github.com/mercantry/registry/issues; deleting a key removes the contact details you supplied with it. Ask the same way for deletion of a booking's reservation name and contact.
Anyone: this policy's history is public in the repository — changes are visible as diffs, not silent edits.