About the Shopping API

Overview

The Shopping API lets platforms browse GoDaddy products, create checkout sessions for buyers, and retrieve completed orders.

How the API is structured

Three resource groups cover the full purchase flow:

A typical integration searches the catalog, creates a checkout, selects payment, accepts required agreements, completes the checkout to place an order, and retrieves the order.

Authentication

Every request needs an Authorization header. Generate a Personal Access Token (PAT) with the scopes you need.

Go to How to authenticate for PAT generation and storage.

Required headers

Every Shopping API request requires these headers in addition to Authorization:

The following example sends the common headers:

Authorization: Bearer $GODADDY_PAT
Request-Id: $(uuidgen)

Checkout state machine

A checkout session uses these states during a successful purchase:

After completion, GET /orders/{id} might return 404 order_not_found while the order read model updates. Retry the order read with bounded backoff.

GET /checkout-sessions/{id} might return 404 checkout_not_found after completion as completed sessions might be cleared. Use the completion response's order.id as the purchase confirmation.

Error responses

The API usually uses HTTP status codes for broad error categories and messages[].code for specific conditions. A 2xx response can also contain an error envelope:

Error responses use the error_response envelope:

{
  "ucp": { "version": "2026-04-08", "status": "error" },
  "messages": [
    {
      "type": "error",
      "code": "invalid_request",
      "content_type": "plain",
      "content": "line_items[0].item.id is required."
    }
  ]
}

Successful responses can omit ucp.status. Error responses set it to error. Check the HTTP status and ucp.status on every response, then match messages[].code; do not match the human-readable content.

Go to Handle errors for GoDaddy's standard error handling guidance.

Last updated on