List Shopify Webhook Routes
webhook_routes_listLists the Shopify webhook topics routed to an app and the path each is
forwarded to, plus forward_host, the base URL the platform delivers
to. Use this to check that a topic the app expects is actually routed,
and that its forward_path matches the route the app's code handles.
Each route reports topic, forward_path (null means the platform
default path) and a registration summary (registered_shops,
failed_shops and last_error) describing whether Shopify accepted
the per-store subscription. A topic with failed_shops above zero is
configured but not actually delivering, which is the usual cause of a
handler that never runs. A store Meridian could not reach at all (its
token revoked or not renewable, or Shopify refusing the request) counts
as failed on every topic it has not registered, with a last_error
that starts with Could not reach and names the store. A store that
uninstalled the app drops out of these counts at the next save of the
topic set.
reconcile_available says whether Meridian can reach the stores that
already installed the app, which needs the app deployed on Meridian
with a ready production database. When it is true, a null registration
means Meridian has not attempted that topic yet, and sign_in is null.
When it is false, Meridian cannot register topics on those stores at
all: the SDK registers the app's topic set on each store when that
store authenticates. Managed topics (app/uninstalled and the billing
topics) are in that set from install on, so every installed store has
them and their sign_in is null. A developer route reaches a store
only at the store's first sign-in after the route was added, so each
such route carries sign_in: installed_shops and awaiting_shops,
the installed stores that have not signed in since (a sign-in within
five minutes of the route being added still counts as awaiting, since
the SDK caches the topic set that long). With awaiting_shops above
zero, say the topic registers on those stores at their next sign-in,
not that it is registered and idle. At zero, every installed store has
signed in since, which is the best evidence available: the SDK does
not report whether Shopify accepted each subscription.
forward_host is resolved by the same code as the live router, and is
the exact origin the platform posts to, not a branded alias assumed to
reach it. forward_host_source names the rung it came from: external
(a verified host declared by an app hosted outside Meridian), then
environment (the app's Meridian deployment, so its raw Cloud Run
base URL), then platform. Both are null when nothing is routed at
all, which for an app hosted on Meridian means nothing is deployed.
A platform source is Meridian's own receiver, the last-resort target
for an app with no runtime of its own: forwarded events stop there and
never reach the app. It routes by app identifier, so forward_url
then carries the single URL every forwarded event goes to. A topic
still needs a forward_path to be forwarded at all, but that path
plays no part in the destination. Say so plainly rather than composing
forward_host + forward_path into an endpoint nothing posts to.
forward_url is null for every other source.
Takes the app_id from apps_list. See webhook_deliveries_list for
individual delivery attempts.
Tool call template
Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.
{
"id": 1,
"jsonrpc": "2.0",
"method": "tools/call",
"params": {
"arguments": {
"app_id": "<app_id>"
},
"name": "webhook_routes_list"
}
}Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| app_id | Yes | The app uuid returned by `apps_list`. | |
| organization_id | No | An organisation uuid or slug. When supplied, `app_id` is resolved within that organisation and may be a slug instead of a uuid, mirroring the Meridian web app. |