Skip to content
littleworksdocs

Explore the documentation

Meet LittleworksA little backend for what you’re building on Shopify.Littleworks or your own appWhat it takes to give a Shopify feature a backend: with Littleworks, or with a custom app you build and run yourself.Connect to LittleworksChoose the CLI, a plugin, or a remote MCP connection.CLIConnect from your terminal with Shopify approval and no manual tokens.Claude pluginThe Littleworks MCP connection and agent guidance in one package.OpenAI pluginThe Littleworks MCP connection and agent guidance in one package.MCP with OAuthConnect a compatible client directly, without a marketplace plugin.Build with an agentThe operating guide for agents building on Shopify with Littleworks.Write a workA JavaScript handler, a small manifest, and a version you test and then publish.Keep secretsEncrypted credentials, shared across your store’s works.Call external servicesMake public HTTPS API requests from a work using http.fetch().Store dataDocument collections with a small API, scoped automatically to the work that uses them.Call ShopifyCall Shopify’s Admin and Storefront GraphQL APIs with credentials held by Littleworks.Store filesKeep uploads such as artwork and photos in the merchant’s Shopify Files, uploaded by the browser straight to Shopify.Expose an endpointConnect an existing frontend to a work through a small JSON API.Customer access and invitationsRequire a signed-in shopper or a narrow, expiring invitation before a work runs.RecipesUseful things to build for your store, with the backend already taken care of.Product reviewsCollect customer reviews, verify purchases, and publish approved content directly into your Shopify theme.Customer wishlistsGive signed-in customers a persistent list of products they can revisit across devices.Customer quote requestsCollect a customer’s products, quantities, and requirements without turning a request into an order.Back-in-stock alertsCollect confirmed signups on sold-out variants, email them through your own provider when stock returns, and see every signup and send in your admin.Transactional emailSend email from your works through your own provider, never twice for the same thing, and see what was sent and what failed.Build a merchant pageDescribe your records and what merchants do with them; Littleworks renders a native Shopify admin page.Run works on their ownRun a work when something happens in the store, on a schedule, or from a Shopify Flow workflow.Run background jobsQueue runs for later or in the background: fan out to thousands of customers, import in pages, follow up days later, and retry what fails.MCP tool referenceTools to inspect, deploy, run, and organize the backend for a connected store.Usage and allowancesSee what your works use, how much capacity remains, and when allowances reset.Inspect and troubleshootFind the relevant run, understand the failure, and make the next change deliberately.Limits and securityThe current runtime boundaries, data isolation model, and execution allowances.
Shopify admin
Browse documentation
Build
Markdown

Call external services

Make public HTTPS API requests from a work using http.fetch().

Works can call any public HTTPS API, such as an email provider, a CRM, an ERP or a webhook, on every plan. There is no monthly allowance: each run can make up to 50 requests. Keep API keys in secrets and send them in whatever header the service expects, such as Authorization or X-Postmark-Server-Token.

Make a request

Call an API
export default async ({ input, http, secrets }) => {
  const response = await http.fetch("https://api.example.com/messages", {
    method: "POST",
    headers: {
      Authorization: `Bearer ${await secrets.get("EMAIL_API_KEY")}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({ message: input.message }),
  });
  if (!response.ok) {
    throw new Error(`Message service returned ${response.status}`);
  }
  const result = await response.json();
  return { id: result.id };
};

The example URL is illustrative; use the documented endpoint of the merchant’s provider. All works can call public HTTPS hostnames without an allowlist or manifest permission. Use http.fetch, since direct fetch and other network transports remain blocked by the sandbox.

Fetch-style interface

http.fetch(url, options) accepts a URL string or URL object. Options are method, headers, body, redirect, and timeoutMs. Methods are GET, HEAD, POST, PUT, PATCH, DELETE, and OPTIONS. Headers accept a plain object, pairs, or Headers. Bodies accept strings or URLSearchParams; set Content-Type for JSON. GET and HEAD cannot include a body. Other options are rejected, including signal; use timeoutMs to set a shorter deadline.

The promise resolves to a buffered Response with status, ok, headers, url, redirected, .json(), .text(), and .arrayBuffer(). HTTP 4xx and 5xx responses do not throw. Network failures, timeouts, and policy limits do. No cookies are stored or set automatically. Set-Cookie and transport-only response headers are removed. Request streams, FormData, file uploads, and streaming responses are not supported.

Built-in limits

ResourceLimit
Requests50 per run, including every redirect hop, shared across parallel calls
Request body64 KiB
Response body256 KiB after decompression
Headers16 KiB per request or response; at most 64 request headers
Deadline5 seconds per call including redirects and reading the response, within the 10-second run deadline
RedirectsUp to 3 same-origin redirects per call

timeoutMs can shorten the deadline to 1–5000 ms. A timeout cannot undo an external operation that already happened. A failed request is never retried automatically. Use the service’s idempotency mechanism when available and inspect effects before retrying.

Destinations and redirects

Only HTTPS hostnames are accepted. Local/internal destinations, literal IP addresses, credentials embedded in URLs, and proxy/routing headers such as Host are rejected. The provider’s public-network transport blocks private addresses at connection time, including after DNS resolution. No Shopify tokens, inbound request headers, or platform credentials are attached to external requests.

Keep requests that contain a secret pointed at a fixed provider origin, or validate the destination against an allowlist owned by your build. A public caller must never choose the destination that receives a store credential. Validate caller identity and authorization before performing external actions.

The default redirect: "follow" follows same-origin redirects only. Cross-origin redirects fail rather than forwarding a credential or body to another service; use that service’s documented final URL directly. redirect: "manual" returns a redirect response; redirect: "error" rejects redirects. Every followed target must pass the destination checks.

Inspect a request

Run details and get_run include a separate external-request list with destination hostname, method, response status, duration, and error code. These records are kept for seven days. Request and response bodies, headers, and URL paths and query values are not recorded automatically. Never log credentials or full third-party response payloads.