Webflow organizes two broad domains you will use most: site-scoped resources (sites, pages, assets, scripts, redirects, webhooks, ecommerce orders/products/users/forms) and collection-scoped CMS resources (collections, fields, items, locales). Many operations require an ID from one of those domains before you can act on related resources; getting those IDs is the first step in nearly every workflow.

Key entities and relationships

• Site: root scope for hosting, pages, assets, scripts, webhooks, redirects, ecommerce products and orders. Most ecommerce, page, and asset endpoints require a site_id.
• Collection: a CMS collection belongs to a Site. To work with CMS entries you need the collection_id. Collections expose a schema of fields used in item fieldData.
• Item (collection item): belongs to a collection_id. Items have id, fieldData (including required name and slug), and flags isDraft/isArchived. There is a clear distinction between draft/staged items and live items: operations exist for both staging (create-item, update-item, list-collection-items) and live content (create-item-live, update-item-live, list-collection-items-live, get-item-live). Publishing is separate (publish-item).
• Product / SKU / Inventory: products are site-scoped. A product object contains product-level fieldData and an array of SKUs. SKUs have their own id and fieldData (price, slug, sku-values). Inventory is per-SKU and addressed with sku_collection_id and sku_id.
• Asset / Asset Folder: assets live under a Site and are referenced by asset_id. create-asset returns upload metadata (see Gotchas). Asset IDs are what you reference in item or SKU image fields.
• Page / Component: pages and components expose DOM-like content via get-static-content / get-component-content and can be updated with update-static-content / update-component-content. Page and component operations often accept a localeId and a branchId when branching/localized editing is used.
• Webhook, User, Form, Order, Redirect: each has its own ID type (e.g., webhook_id, user_id, form_submission_id, order_id, redirect_id) and are usually site-scoped or workspace-scoped per the operation signature.

Knowing which ID you need and where to get it is the most important practical step. For example, collection operations almost always require collection_id; product/sku and order operations require site_id plus the specific product_id, sku_id, or order_id.

Typical entry points — what to call first

• Get list of Sites: use list-sites to retrieve site.id values. Many workflows start from the Site.
• For CMS work: call list-collections with the site_id to find collection_id and inspect the collection schema via collection-details to learn field slugs and required fields.
• To find items: use list-collection-items (or list-collection-items-live for published items) to get item id and current fieldData (including slug and name).
• For ecommerce: call list-products to get product IDs and nested SKUs, or get-product for a single product + SKUs. Use list-orders to scan recent orders and get-order to inspect a specific order.
• For assets: call list-assets or list-asset-folders for existing assets; use create-asset to start an upload and get-asset to inspect the metadata after upload.
• For pages/components: call list-pages or get-page-metadata to obtain page_id; then get-static-content to read DOM nodes; update with update-static-content (requires localeId).
• For forms: use list-forms to find a form's id, then get-form-schema and list-submissions or get-form-submission for responses.

Common tasks and the operation sequences to accomplish them

The guidance below describes the minimal sequences that produce the IDs or effects you need. Reference the operation names when assembling requests.

Create a CMS item (staged) and publish it

• Find site_id -> list-collections -> pick collection_id.
• Inspect required fields with collection-details to build fieldData (must include name and slug where required).
• Create the item with create-item (or create-items for a batch). Note the skipInvalidFiles query (default true) controls whether invalid file references fail the whole request.
• If you created a draft/staged item and need it published, call publish-item for that collection_id and item(s). Alternatively use create-item-live to create directly on the live site.

Create or update an asset and reference it in CMS fields or SKU images

• Use create-asset with site_id. The response may include either an uploadUrl or a set of uploadDetails (S3/presigned fields). Provide those upload instructions to whoever will upload the binary. The API’s asset metadata is created when you call create-asset; the binary upload may be a separate step outside this API.
• After upload, confirm with get-asset (returns hostedUrl, variants, altText). Use the asset.id in fieldData (or the hostedUrl in image fields) depending on the collection/schema.

Create products and SKUs, then manage inventory

• Create a product with create-product (pass site_id). The response contains the product object and optionally created SKUs.
• To add SKUs separately, call create-skus with site_id and product_id.
• Update SKU details with update-sku (site_id, product_id, sku_id) and adjust inventory with update-inventory (requires sku_collection_id and sku_id). Use list-products or get-product to discover product_id and SKU id values.

Process and manage orders

• Use list-orders to find recent orderId values (supply site_id). Inspect a single order with get-order.
• Transition order state using fulfill-order and unfulfill-order (both require site_id + order_id). Issue refunds with refund-order.

Pages and component content edits

• Get a page's page_id via list-pages or get-page-metadata.
• Read content nodes with get-static-content (or get-component-content for components). These responses include node UUIDs and types (text, image, component-instance, etc.).
• To update, call update-static-content (page-level) or update-component-content. For pages you must supply the localeId in the query (it's required by update-static-content). If the site uses branching, include branchId to scope edits to a branch.

Forms and submissions

• Discover a form with list-forms, get its schema with get-form-schema.
• Review responses using list-submissions (form-scoped) or list-submissions-by-site (site-scoped); inspect individual responses with get-form-submission or get-form-submission-by-site.
• Modify or delete form submissions with modify-form-submission / delete-form-submission (note there are both form-scoped and site-scoped variants).

User management and access groups

• List site users with list-users. Invite a new user to a site with invite-user (supply site_id) and update or remove with update-user / delete-user.
• To check access groups available to assign, call list-access-groups with site_id.

Webhooks and scripts

• Register webhooks with create-webhook, inspect them with list-webhooks / get-webhook, and remove with remove-webhook (use the webhook_id).
• Manage custom scripts and blocks via get-scripts, post-hosted-script / post-inline-scripts, and apply them through add-custom-code-tosite or add-custom-code-to-page (use site_id or page_id). get-site-custom-code and get-page-custom-code show scripts applied at those scopes.

Localization and locales

• The API exposes two locale identifiers: site-level locale metadata (returned under a Site’s locales) and CMS cmsLocaleId. When endpoints accept cmsLocaleId (or localeId) they refer to the CMS locale UID listed in the Sites response under locales.primary.cmsLocaleId / locales.secondary[].cmsLocaleId. Those CMS locale IDs are the values to pass when you need content for a specific translation. They are not interchangeable with the page localeId in unrelated responses—inspect the Site response to map locale IDs.

Non-obvious behaviors and gotchas

• Slug changes break links. Updating an item or product slug will change URLs and can break any external links referencing the old slug. If preserving URLs matters, avoid changing slug or create redirects.
• Draft vs live content is explicit. The API separates staged/draft operations from live ones. create-item / update-item operate on staged content; create-item-live / update-item-live and the *-live list/get endpoints operate on published content. Use publish-item to push staged items live when you need a two-step workflow.
• skipInvalidFiles controls file validation for item batch operations. For batch create/update of items, the default is true (invalid file references are skipped). Setting it to false will cause the entire request to fail if any file is invalid—useful when you need all-or-nothing semantics.
• Asset uploads often involve presigned fields. create-asset frequently returns either an uploadUrl or uploadDetails (S3-style fields). The binary upload step may be outside the Data API; return these details to the requester so they can upload the file to the provided URL or using the provided fields. After the binary is uploaded, check get-asset to confirm hostedUrl and variants are present.
• Script registration vs application. Registering a script (inline or hosted) and applying it to a site or page are separate operations: create the script first (register), then apply via add-custom-code-tosite / add-custom-code-to-page or by placing it into a custom code block.
• Many list endpoints return nested objects (products with SKUs, items with fieldData). When you need an ID that appears inside another resource, call the parent list/get endpoint first and extract the nested id (for example, list-products returns each product and its skus array—use those id values for SKU updates).
• Page/component updates require locale context. update-static-content requires a localeId in the query. If the site uses branching, include branchId when you intend to update a branch instead of the primary branch.
• Several operations exist in both site-scoped and workspace-scoped variants (for webhooks, form submissions, and users). Pick the operation whose path parameters match the scope you intend to operate in (site vs workspace).

Error-relevant observations you can act on

• A 200 response for create endpoints often returns the created object with its new IDs—capture these IDs for follow-up operations (publish, update, link references).
• Create operations for assets/products/items commonly return nested metadata required for the next step (upload details, SKU arrays). Don’t assume the creation is complete until you see the ID(s) or hosted URL(s) you need.

Quick operational checklist

• Need a site_id? Call list-sites.
• Need a collection_id? Call list-collections with site_id.
• Need an item id? Call list-collection-items (or list-collection-items-live for published items) with collection_id.
• Upload a file? Call create-asset with site_id and pass the returned upload instructions to the uploader; confirm with get-asset.
• Create product + SKUs? create-product (site) → create-skus (site + product_id) → update-sku / update-inventory as needed.
• Manage orders? list-orders → get-order → fulfill-order / unfulfill-order / refund-order.

Use these patterns to assemble minimal, deterministic sequences: discover the correct parent ID first, inspect the returned schema or nested objects for the child IDs you need, then call the modifying operation that requires those IDs.