Skip to main content
Glama

update_webhook

Update an existing webhook subscription's callback URL, payload format, include fields, or metafield namespaces. Topic cannot be changed. Use for endpoint migration, format switch, or payload optimization.

Instructions

Modify an existing webhook subscription's callback URL, payload format, includeFields filter, or metafield-namespace filter. Topic cannot be changed — to switch event types, delete and recreate the subscription. Use when migrating an endpoint to a new domain, switching from JSON to XML, or tightening payload size by adding includeFields. Omitted parameters are left unchanged.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesWebhook subscription GID to update.
callbackUrlNo
formatNo
includeFieldsNo
metafieldNamespacesNo

Implementation Reference

  • The handler function for the 'update_webhook' tool. It builds a webhookSubscription payload from optional args (callbackUrl, format, includeFields, metafieldNamespaces), calls the Shopify webhookSubscriptionUpdate mutation, throws on user errors, and returns a summary of the updated webhook.
      async (args) => {
        const webhookSubscription: Record<string, unknown> = {};
        if (args.callbackUrl !== undefined) {
          webhookSubscription.callbackUrl = args.callbackUrl;
        }
        if (args.format !== undefined) webhookSubscription.format = args.format;
        if (args.includeFields !== undefined) {
          webhookSubscription.includeFields = args.includeFields;
        }
        if (args.metafieldNamespaces !== undefined) {
          webhookSubscription.metafieldNamespaces = args.metafieldNamespaces;
        }
    
        const data = await client.graphql<{
          webhookSubscriptionUpdate: {
            webhookSubscription: WebhookSubscriptionNode | null;
            userErrors: ShopifyUserError[];
          };
        }>(WEBHOOK_UPDATE_MUTATION, {
          id: args.id,
          webhookSubscription,
        });
        throwIfUserErrors(
          data.webhookSubscriptionUpdate.userErrors,
          "webhookSubscriptionUpdate",
        );
        const w = data.webhookSubscriptionUpdate.webhookSubscription;
        return {
          content: [
            {
              type: "text" as const,
              text: w
                ? `Updated webhook ${w.topic} → ${w.endpoint.callbackUrl ?? "(endpoint)"} — ${w.id}`
                : `Updated webhook ${args.id}.`,
            },
          ],
        };
      },
    );
  • Zod schema for the update_webhook tool input. Defines 'id' (required GID), and optional fields: callbackUrl, format (JSON/XML), includeFields, and metafieldNamespaces.
    const updateWebhookSchema = {
      id: z.string().describe("Webhook subscription GID to update."),
      callbackUrl: z.string().url().optional(),
      format: z.enum(["JSON", "XML"]).optional(),
      includeFields: z.array(z.string()).optional(),
      metafieldNamespaces: z.array(z.string()).optional(),
    };
  • Registration of 'update_webhook' via server.tool() inside the registerWebhookTools function. The tool is registered with name 'update_webhook', a descriptive string, the updateWebhookSchema, and the async handler.
    server.tool(
      "update_webhook",
      "Modify an existing webhook subscription's callback URL, payload format, includeFields filter, or metafield-namespace filter. Topic cannot be changed — to switch event types, delete and recreate the subscription. Use when migrating an endpoint to a new domain, switching from JSON to XML, or tightening payload size by adding includeFields. Omitted parameters are left unchanged.",
      updateWebhookSchema,
      async (args) => {
        const webhookSubscription: Record<string, unknown> = {};
        if (args.callbackUrl !== undefined) {
          webhookSubscription.callbackUrl = args.callbackUrl;
        }
        if (args.format !== undefined) webhookSubscription.format = args.format;
        if (args.includeFields !== undefined) {
          webhookSubscription.includeFields = args.includeFields;
        }
        if (args.metafieldNamespaces !== undefined) {
          webhookSubscription.metafieldNamespaces = args.metafieldNamespaces;
        }
    
        const data = await client.graphql<{
          webhookSubscriptionUpdate: {
            webhookSubscription: WebhookSubscriptionNode | null;
            userErrors: ShopifyUserError[];
          };
        }>(WEBHOOK_UPDATE_MUTATION, {
          id: args.id,
          webhookSubscription,
        });
        throwIfUserErrors(
          data.webhookSubscriptionUpdate.userErrors,
          "webhookSubscriptionUpdate",
        );
        const w = data.webhookSubscriptionUpdate.webhookSubscription;
        return {
          content: [
            {
              type: "text" as const,
              text: w
                ? `Updated webhook ${w.topic} → ${w.endpoint.callbackUrl ?? "(endpoint)"} — ${w.id}`
                : `Updated webhook ${args.id}.`,
            },
          ],
        };
      },
    );
  • The GraphQL mutation (WEBHOOK_UPDATE_MUTATION) used by the handler to call Shopify's webhookSubscriptionUpdate API.
    const WEBHOOK_UPDATE_MUTATION = /* GraphQL */ `
      mutation WebhookUpdate($id: ID!, $webhookSubscription: WebhookSubscriptionInput!) {
        webhookSubscriptionUpdate(id: $id, webhookSubscription: $webhookSubscription) {
          webhookSubscription {
            id
            topic
            format
            endpoint {
              __typename
              ... on WebhookHttpEndpoint { callbackUrl }
            }
          }
          userErrors { field message }
        }
      }
    `;
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It discloses that omitted parameters remain unchanged (partial update behavior) and that the topic is immutable. However, it lacks details on authorization, rate limits, or the side effects of updating an active webhook, which slightly reduces transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise paragraph with clear sentences. Every sentence adds value: stating what can be changed, what cannot, use cases, and the effect of omitted parameters. It is appropriately front-loaded and avoids redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and moderate parameter count, the description provides sufficient context for an agent to correctly invoke the tool. It covers constraints (topic immutable), partial update semantics, and typical use cases. Lacks mention of return value or error handling, but overall complete for an update operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 20% (only id described). The description compensates by listing each modifiable parameter (callbackUrl, format, includeFields, metafieldNamespaces) and clarifying that they are optional and omitted ones are unchanged. It also explains the enum for format (JSON/XML), adding meaningful context beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly specifies the tool modifies an existing webhook subscription's callback URL, format, includeFields, or metafieldNamespaces. It distinguishes itself from the alternative of deleting and recreating a webhook when changing the topic, making its purpose distinct.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit usage scenarios are provided: migrating an endpoint, switching formats, or tightening payload size. It also states what cannot be changed (topic) and directs the agent to delete/recreate for that case, offering clear guidance on when to use this tool versus alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/miller-joe/shopify-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server