Version 0.1.0-beta.10

TL;DR: Data hub item collections can now hold multiple item types, each with its own schema, fields, and destinations — create, update, and delete them independently of the collection they live in. Search tools gain staging environment support: pass environment to target staging instead of production, and every response now names which environment was actually queried. Account listings show which environments each account supports.

Manage multiple item types per Data hub collection

Add, update, or remove item types on an item collection with create_item_type, update_item_type, and delete_item_type, and list or fetch one with search_item_types. A collection is no longer limited to a single implicit product type — hold a store, a review, or any other custom type alongside it, each with its own schema and destinations.
An item type's item_class is product, which may define variant relationships, or custom, a flat type with no relationships. The name, class, and relationships are fixed at creation — delete and recreate the type to change them.
Every schema, field, record, and item tool now takes an optional item_type, so you can target a specific type instead of always reading the product type. Omit it, and nothing changes for existing integrations.
create_item_collection gains a types parameter that replaces the older item_types shape, letting you set a type's class and destinations at creation time. update_item_collection_metadata no longer touches item types at all — use create_item_type and delete_item_type for that instead.

Deleting a collection now requires deleting its item types first: delete_item_collection is blocked while any remain, and the error names them. Destinations reported by configuration tools are now grouped by platform (engagement and discovery) rather than returned as a flat list.

Work against Search staging environments

Pass environment (production or staging) to Search merchandising, catalog, analytics, Pixel Health, and navigation tools to target staging instead of production. Every response now includes environment_used, naming the environment actually queried — this matters because a staging-only account always resolves to staging even if you asked for production.
list_discovery_accounts now returns which environments each account supports, so you can find your staging-only accounts before working against them, rather than discovering the mismatch from an error.
An invalid environment value is rejected immediately with a clear error, rather than failing deeper in the call.

Bug fixes

A site lookup on a staging-only account no longer crashes the tool with an unhandled exception when the site exists only in the other environment. It now returns a clear, structured error naming the checked environment.