APIEase Public API

The APIEase public API is the HTTP interface behind apiease-cli and other external automation.

Use it when you want to:

manage saved APIEase resources from code or scripts
keep request, widget, variable, and function definitions under source control
execute an existing APIEase request from outside Shopify

Most developer workflows should use the public API through apiease-cli from an apiease-template repository, but the underlying HTTP interface is available when you need direct integration.

What the public API covers

Today, the public API has two main jobs:

CRUD operations for saved resources under /api/v1/resources
Remote execution of an existing saved request through /api/remote/caller/call

This is important because the public API is not a generic one-off proxy for arbitrary outbound calls. You first create and store APIEase resources, then APIEase manages execution using those saved definitions.

Authentication

Public API requests are authenticated with two headers:

x-apiease-api-key: your APIEase API key
x-shop-myshopify-domain: the target shop domain, for example yourstore.myshopify.com

When you send JSON bodies, also include:

content-type: application/json

Example:

curl -X GET 'https://app-admin.apiease.com/api/v1/resources/requests' \
  -H 'x-apiease-api-key: your-apiease-api-key' \
  -H 'x-shop-myshopify-domain: yourstore.myshopify.com'

APIEase resolves the shop from the x-shop-myshopify-domain header. Do not rely on shop-identifying fields in the JSON body.

Resource routes

The current resource base path is /api/v1/resources.

Resource	Collection route	Item route
Requests	`/api/v1/resources/requests`	`/api/v1/resources/requests/{handle}`
Functions	`/api/v1/resources/functions`	`/api/v1/resources/functions/{handle}`
Variables	`/api/v1/resources/variables`	`/api/v1/resources/variables/{handle}`
Widgets	`/api/v1/resources/widgets`	`/api/v1/resources/widgets/{handle}`

Collection routes support:

GET to list resources
POST to create a resource

Item routes support:

GET to read one resource
PUT to update one resource
DELETE to delete one resource

In practice, apiease-cli is a thin wrapper around these routes.

Resource identity

Use handles as the public identifiers for saved resources:

request resources use handle
function resources use handle
variable resources use handle
widget resources use handle

APIEase still returns server-owned ids in some responses, such as id. Treat those values as APIEase metadata. Do not store them in source-controlled resource definition files, and do not use them for new public API automation. Older widget responses or examples may use widgetId; use id when you need to inspect server-owned widget metadata.

Handles must be lowercase slug values using letters, numbers, and single hyphens between words, such as product-details-proxy or support-api-key.

For a fuller explanation, see Resource handles.

Request conventions

If you are working with request resources, keep these conventions in mind:

type is required and currently supports http, flow, liquid, and system
method and address are required for http requests
liquid is required for liquid requests
parameters are optional for many requests but required for system requests
triggers are optional and describe how a saved request can run later
For liquid requests, include saved Liquid parameters only for saved values, sensitive values, or {parameterName} substitution.
Add a storefrontAppProxy trigger only to requests that should be called directly through Shopify's app proxy. Do not add it to Liquid helper requests that are only called by other APIEase requests.

The public API accepts the same request concepts already documented in the Requests section. Use those pages as the source of truth for detailed behavior instead of duplicating that material here:

Create a request

This example matches the request shape used by the template examples and the current public request contract:

curl -X POST 'https://app-admin.apiease.com/api/v1/resources/requests' \
  -H 'content-type: application/json' \
  -H 'x-apiease-api-key: your-apiease-api-key' \
  -H 'x-shop-myshopify-domain: yourstore.myshopify.com' \
  -d '{
    "handle": "product-details-proxy",
    "name": "Product Details Proxy",
    "type": "http",
    "method": "POST",
    "address": "https://api.example.com/products/{productHandle}/details",
    "parameters": [
      {
        "type": "header",
        "name": "Accept",
        "value": "application/json"
      },
      {
        "type": "header",
        "name": "Authorization",
        "value": "Bearer {external_api_token}",
        "sensitive": true
      },
      {
        "type": "path",
        "name": "productHandle",
        "value": "sample-product"
      }
    ],
    "triggers": [
      {
        "type": "proxyEndpoint",
        "proxyEndpoint": {
          "path": "product-details",
          "method": "GET",
          "authenticated": true
        }
      }
    ]
  }'

When creating or updating a request:

send only the fields that belong to the resource itself
use handle as the stable source-owned identifier
do not send server-owned or shop-owned metadata such as id, shop, shopId, shopDomain, or myshopifyDomain
mark confidential parameter values as sensitive: true

Other resource payloads

The other saved resource types follow the same handle-first identity model.

Variable example:

{
  "handle": "support-api-key",
  "name": "Support API Key",
  "value": "replace-with-real-secret",
  "sensitive": true
}

Function example:

{
  "handle": "format-price",
  "name": "format_price",
  "description": "Format a numeric amount for display.",
  "type": "liquid",
  "liquid": "{{ amount }} {{ currency }}",
  "parameters": [
    { "name": "amount", "type": "number" },
    { "name": "currency", "type": "string" }
  ]
}

Widget example:

{
  "handle": "promo-banner",
  "name": "Promo Banner",
  "liquid": "<section>Sale now live</section>",
  "javascript": "",
  "externalJavascriptUrls": [],
  "disableJavascript": false
}

For widgets, handle is the stable public identifier and name is display text. Older widget payloads or examples may use widgetHandle, widgetId, or widgetName; use handle, id, and name for new public API automation.

Read, update, and delete

Use the collection route to list resources:

curl -X GET 'https://app-admin.apiease.com/api/v1/resources/requests' \
  -H 'x-apiease-api-key: your-apiease-api-key' \
  -H 'x-shop-myshopify-domain: yourstore.myshopify.com'

Use the item route to read, update, or delete one resource:

curl -X GET 'https://app-admin.apiease.com/api/v1/resources/requests/product-details-proxy' \
  -H 'x-apiease-api-key: your-apiease-api-key' \
  -H 'x-shop-myshopify-domain: yourstore.myshopify.com'

curl -X PUT 'https://app-admin.apiease.com/api/v1/resources/requests/product-details-proxy' \
  -H 'content-type: application/json' \
  -H 'x-apiease-api-key: your-apiease-api-key' \
  -H 'x-shop-myshopify-domain: yourstore.myshopify.com' \
  -d '{
    "name": "Product Details Proxy Updated",
    "type": "http",
    "method": "GET",
    "address": "https://api.example.com/products/{productHandle}/details"
  }'

curl -X DELETE 'https://app-admin.apiease.com/api/v1/resources/requests/product-details-proxy' \
  -H 'x-apiease-api-key: your-apiease-api-key' \
  -H 'x-shop-myshopify-domain: yourstore.myshopify.com'

The same CRUD pattern also applies to functions, variables, and widgets with their respective handle-based item routes.

Execute a saved request remotely

The public API also exposes a remote execution route for saved requests:

curl -X POST 'https://app-admin.apiease.com/api/remote/caller/call?requestId=product-details-proxy' \
  -H 'x-apiease-api-key: your-apiease-api-key' \
  -H 'x-shop-myshopify-domain: yourstore.myshopify.com'

Use that route when the request definition already exists in APIEase and you want to trigger it from another system. The query parameter is still named requestId, but pass the request handle as the value for new integrations. For more detail, see Calling APIEase Requests Remotely.

Response shape

Successful responses follow a simple pattern:

collection reads return { ok: true, shopDomain, <resourcePlural> }
single-resource reads and writes return { ok: true, shopDomain, <resourceSingular> }

Structured failures use this pattern:

{
  "ok": false,
  "errorCode": "INVALID_REQUEST_CREATE_CONTRACT",
  "message": "Unable to create request",
  "fieldErrors": []
}

Common status codes across the public API include:

400 for invalid JSON, invalid shop context, or resource-specific bad input
401 for failed authentication
404 for missing resources on item routes
405 for unsupported methods
415 for non-JSON create or update bodies
422 for contract validation failures
500 for unexpected server failures

Recommended workflow

For most teams, the practical workflow is:

keep resource definitions in a repository
manage them through apiease-cli
let the CLI call the public API using your configured base URL, API key, and shop domain In most cases, that base URL should be https://app-admin.apiease.com.
use direct HTTP calls only when you need custom automation outside the CLI

That keeps your APIEase resources versioned in git while still using the same public API contract that powers the CLI.

What the public API covers​

Authentication​

Resource routes​

Resource identity​

Request conventions​

Create a request​

Other resource payloads​

Read, update, and delete​

Execute a saved request remotely​

Response shape​

Recommended workflow​