Search the full catalog of all 178 Yandex KIT API operations by keyword. Matches operationId, URL path, tag and Russian summary/description (the API docs are in Russian, so Russian keywords like "категории" work too). Any operation found here can be executed with kit_request; use get_operation_schema to inspect its parameters and body shape first.

Get full metadata for one KIT API operation by operationId: HTTP method, path, path/query parameters, request content type, pagination info, and the fully dereferenced JSON schemas of the request body and response. Call this before kit_request or any create/update tool to learn the exact body shape.

Escape hatch that executes ANY of the 178 Yandex KIT API operations by operationId, including operations without a dedicated tool. WARNING: this performs REAL calls against the live store — write operations (create/update/delete/archive) take effect immediately and there is no sandbox. Workflow: search_operations -> get_operation_schema -> kit_request. The request body is validated against the OpenAPI schema before sending (set validate=false to skip). If a mutation returns HTTP 429, LIMIT_EXCEEDED, timeout or another uncertain result, read back the complete affected resource before considering any repeat; never blindly replay the write.

Get information about the current store (id, slug, b2c_url). b2c_url is the storefront origin a variant's relative_link_url is resolved against — list_variant_links already does that join. Operation: GetStore.

Get the user that owns the API token. Operation: GetCurrentUser.

Get permanent links to the store's catalog feeds: ICML (RetailCRM), YML (Yandex Direct) and YML_GOODS (Yandex Tovary). A feed URL never changes when the feed content updates — fetch it once and download the feed by that URL on a schedule. Operation: GetStoreFeeds.

Get the list of geographic regions (countries, regions, cities). Each region has an id, a name and a parent region id, forming a hierarchy. Operation: GetRegions.

List product records (paginated); for export requests, use this for explicit raw product-group or catalog-structure dumps. Ordinary catalog exports use list_variants: a product carries grouping and category data, not a sellable name, SKU, price or stock. format:"csv" defaults to top-level scalar fields (currently id and group_id) and does not flatten variant data. The response carries a machine-readable coverage envelope (coverage, received, total_count, pages_read); coverage:"partial" MUST be reflected in the user-facing answer and forbids claiming the listing is complete.

Get a single product by its ID, including its category bindings.

Create a new product. Requires category_ids (array of category UUIDs, at least one). Call get_operation_schema("CreateProduct") for the exact request shape.

Update an existing product (plain JSON PATCH, not merge-patch). Passing category_ids fully replaces the product's category list. Call get_operation_schema("UpdateProduct") for the exact request shape.

Get the similar-products settings of a product card: its binding_mode plus the bound objects for that mode — product_card_ids for SELECTED_CARDS, category_ids and collection_ids for SELECTED_CATEGORIES_COLLECTIONS, none for ALL_VARIANTS (up to 500 IDs each). A 404 means the card has no settings yet — create them with set_similar_cards_mode action="create". These settings are separate from the deprecated symmetric links of GetSimilarProductCardIDs — neither API sees the other's bindings. The response carries a machine-readable coverage envelope (coverage, received, total_count, pages_read); coverage:"partial" MUST be reflected in the user-facing answer and forbids claiming the listing is complete.

Create the similar-products settings of a product card (action="create"; 409 if they already exist) or change the binding mode of existing ones (action="update"; 404 if there are none — check with get_similar_cards). Changing the mode drops every bound card, category and collection, and switching back does not restore them — read them with get_similar_cards first and re-bind afterwards. After choosing SELECTED_CARDS or SELECTED_CATEGORIES_COLLECTIONS, bind the objects with manage_similar_cards_objects.

Bind objects to a product card's similar-products settings or unbind them (up to 500 per call). product_card_ids work only in SELECTED_CARDS mode, category_ids and collection_ids only in SELECTED_CATEGORIES_COLLECTIONS — send either cards or categories/collections, never both. One-directional: only this card's settings change, the listed cards get no reverse link (unlike the deprecated symmetric AddSimilarProductCards/DeleteSimilarProductCards).

Delete the similar-products settings of a product card. Cannot be undone — read them with get_similar_cards first if they may be needed again.

Primary sellable catalog/export listing: list variants (SKUs), one item per sellable SKU. Use this for ordinary catalog or «выгрузи товары в CSV» requests; use list_products only for an explicit raw product-group export. Variants support optional filters and pagination. By default the API returns variants of all statuses except ARCHIVED. format:"csv" defaults to top-level scalar fields and serializes nested pricing/stocks as JSON cells; it does not create flat price or per-warehouse stock columns. List the archive with status ["ARCHIVED"]. If the response ever holds statuses outside the requested filter, the tool fails with STATUS_FILTER_IGNORED instead of returning the wrong catalog slice. For storefront page URLs use list_variant_links — it joins each item's relative_link_url with the store's b2c_url for you. The response carries a machine-readable coverage envelope (coverage, received, total_count, pages_read); coverage:"partial" MUST be reflected in the user-facing answer and forbids claiming the listing is complete.

Get a single variant by its ID (name, SKU, pricing, stocks, media, status). relative_link_url is the variant's storefront path; prefix it with the store's b2c_url (get_store) for a full link, or use list_variant_links to get that joined for you.

Storefront page URLs of variants, ready to hand to a CMS, PIM or feed. Each variant carries a relative_link_url from the API — it already reflects the store's path settings and selects the variant (?variant=) — and this tool joins it with the store's b2c_url, so no URL rules have to be maintained on the integration side. One call instead of list_variants + get_store. Same filters as list_variants; archived variants are excluded by the API. The response carries a machine-readable coverage envelope (coverage, received, total_count, pages_read); coverage:"partial" MUST be reflected in the user-facing answer and forbids claiming the listing is complete.

Create a new variant (sellable item) under an existing product. Required: name and product_id. media holds images and at most ONE video: a video entry is accepted only when the same media list also carries at least one image, and its video_id must already be READY (upload_video / upload_video_from_url, then poll get_video). Call get_operation_schema("CreateVariant") for the exact request shape (pricing, stocks, media, ...).

Update an existing variant via JSON Merge Patch: send only the fields to change (e.g. pricing or stocks). No field of UpdateVariantRequest is nullable, so null values are rejected by validation before any call — to clear a price, use bulk_update_prices (its price/manual_discount_price accept null). media is an exception to merge-patch granularity: sending it REPLACES the whole list, so resend the existing images alongside anything you add. At most ONE video per variant, and a video is accepted only when the same list carries at least one image — sending a video alone wipes the images and fails. stocks and characteristics replace the whole list too; rebuild them from a fresh get_variant, which IS the complete current state (an empty characteristics list is genuinely empty, nothing hidden). Call get_operation_schema("UpdateVariant") for the exact request shape — but ignore its prose for stocks: upstream the spec pasted the media wording there, while the field still takes VariantStock entries (per-warehouse quantities).

Update prices of up to 5000 variants in one synchronous, atomic request — the fast path for syncing a whole catalog instead of calling update_variant per item. If a single item is invalid (variant unknown or archived, variant listed twice, price malformed, discount price above the base price) the whole request is rejected with 400 and NOTHING is applied; the response errors list names every offending variant. Both price fields are optional per item: omit a key to keep the current value, or send null to reset it (resetting price works only on unpublished variants). Changing price recomputes the promo price; promo membership is refreshed in the background afterwards.

Archive a variant (soft delete: status becomes ARCHIVED, item is hidden from the storefront but restorable) or unarchive it (status becomes HIDDEN; publish it afterwards via update_variant).

List product categories of the store (paginated). The API requires a status filter; defaults to ACTIVE when not provided. The response carries a machine-readable coverage envelope (coverage, received, total_count, pages_read); coverage:"partial" MUST be reflected in the user-facing answer and forbids claiming the listing is complete.

Get a single product category by its ID.

Create a new product category. Required: title. Optional: slug, parent_id, display_sequence, is_hidden_in_menu, file_id, seo_title, seo_description. Call get_operation_schema("CreateCategory") for the exact request shape.

Update an existing category via JSON Merge Patch: send only the fields to change. Only parent_id and file_id accept null (parent_id: null makes the category top-level, file_id: null removes the image); null on any other field is rejected by validation. Call get_operation_schema("UpdateCategory") for the exact request shape.

Archive a category (soft delete: hidden from the storefront, restorable) or unarchive it. If the category is the only one of a product with non-archived variants, archiving requires archive_variants=true.

List orders of the store (paginated), newest first by default. Each order carries customer_id (look the buyer up with get_customer) and items[].name, so a CRM can link an order to its customer card without extra calls. updated_from/updated_to filter by last-change time, which is what an incremental sync should poll on: an order that only changed status still falls inside the window, while a created-at filter would miss it. Sync recipe: updated_from=, sort_by=updated_at, sort_direction=asc, then advance the cursor to the largest updated_at seen — an order that changes mid-paging moves to the end instead of being skipped, and an all=true run cut off at 500 items resumes from that cursor. The filter is inclusive on both ends, so the boundary order comes back on the next poll — deduplicate by order ID. The response carries a machine-readable coverage envelope (coverage, received, total_count, pages_read); coverage:"partial" MUST be reflected in the user-facing answer and forbids claiming the listing is complete.

Get a single order by its ID, including line items (items[].name is the product name at order time), delivery chunks, payment and status. customer_id links the order to its buyer — read the card with get_customer. Read the delivery address from delivery_chunks[].delivery_info.address.locality/.address: they always match the chosen delivery method, while the courier_*, pickup_point_* and self_pick_up_* groups keep whatever the buyer picked earlier in checkout and are stale unless the group matches method.

Confirm an order. The order must be in the WAIT_FOR_CONFIRMATION status. No request body is required.

Cancel an order. Whether cancellation is possible depends on the order's current status. The optional owner reason is retained only in the MCP conversation/tool log; the KIT CancelOrder endpoint has no reason field, so it is not sent to or stored by the KIT API. No request body is required.

Mark the delivery of an order as fully completed. Intended for pickup and the store's own delivery when delivery automation is off — with automation on, the platform moves the order itself. No request body is required.

Write «Честный знак» (Chestny ZNAK) marking codes onto order items, or remove them. Each order item is a single unit and takes exactly one code; item IDs come from get_order under delivery_chunks[].items[].id. Pass the code in full, including the crypto tail; pass marking_code null to remove a previously written code. Atomic: if any code fails the server-side check the whole request is rejected and nothing is written.

List additional services (addons) attached to an order by the order ID.

Get the signed payment-page link for an order, to be sent to the buyer — they can pay without logging in. The link is permanent (the same value for the order every time), works in any order status, never expires and cannot be revoked (revoking the API token does not invalidate it) — hand it out deliberately. Operation: GetOrderPaymentLink.

Generate waybills (акты приёма-передачи отправлений) for order delivery chunks and return links to PDF documents. Chunks are grouped by warehouse + delivery service — one document per group. Every call asks the delivery service for a fresh document (nothing is cached), and the PDF links are signed and expire at expires_at — do not store them, re-request instead. Chunks a waybill cannot be produced for (self-pickup, delivery not created yet, no warehouse, unsupported service) come back in skipped with a reason. Chunk IDs come from get_order under delivery_chunks[].id.

Get the delivery labels (ярлыки) of an order's delivery chunks — the PDF with the address, tracking number and barcode that goes onto the parcel. The first request per chunk and format asks the delivery service for the document, later ones return the same one. The PDF links are signed and expire at expires_at — do not store them, re-request instead. Chunks with no label (self-pickup, delivery not created yet, service that does not print labels, requested format unsupported, or a failure on the service's side — reason GENERATION_FAILED, which is temporary and worth retrying) come back in skipped with a reason, while the remaining chunks still return their labels. For the handover act covering a whole warehouse + service group use generate_order_waybills instead.

List the label sizes the given delivery services can print — the values accepted by get_order_delivery_labels' label_format. Per service, mode says how it treats sizes: EXPLICIT_FORMATS (pick one of formats), PROVIDER_DEFAULT (size ignored, the service prints its own) or NOT_SUPPORTED (no labels at all, formats empty). preselected is only the size preselected in the KIT UI — it does NOT apply when label_format is omitted. Services come back in the platform's own display order, so look one up by delivery_service, not by position.

List customers of the store (paginated), by customer ID ascending by default. updated_from/updated_to filter by last-change time (updated_at) for incremental CRM sync. Sync recipe: updated_from=, sort_by=updated_at, sort_direction=asc, then advance the cursor to the largest updated_at seen — a customer that changes mid-paging moves to the end instead of being skipped, and an all=true run cut off at 500 items resumes from that cursor. Both bounds are inclusive, so the boundary customer comes back on the next poll — deduplicate by customer_id. The response carries a machine-readable coverage envelope (coverage, received, total_count, pages_read); coverage:"partial" MUST be reflected in the user-facing answer and forbids claiming the listing is complete.

Get a single customer by their ID. birth_date (date only, no year-of-birth guarantee beyond what the buyer entered) is present only when the customer supplied it, and is read-only: UpdateCustomer has no such field. It is personal data — redact:true masks it along with name, phone, email and note.

Update a customer (plain JSON PATCH). Updatable fields: note, first_name, last_name, email. phone and birth_date are read-only — the API returns them but has no field to write them, so do not try. Call get_operation_schema("UpdateCustomer") for the exact request shape.

Get the current cart of a customer — the source for abandoned-cart work: items with quantity and per-unit/line prices, plus total_price (before discounts) and total_final_price (after item and bundle discounts). An empty cart, and a customer who never had one, both return items: [] with zero totals; updated_at is absent in the never-had-one case and is the only way to tell the two apart — there is no abandoned-cart flag, so decide staleness from updated_at yourself. product_variant_id is NOT a unique key for a line: the same variant appears in several items when it is part of a bundle, was added with different addons, or was picked as a gift. quantity is what the buyer put in and may exceed stock — the API clamps it only when they reopen the cart or check out. Items whose variant was unpublished are dropped from the response. A cart promocode is NOT reflected in total_final_price (unlike Order.total_final_price), so cart totals are not a forecast of the order total.

List order IDs of a customer by their customer ID (paginated) — the purchase history. Read each order with get_order for its line items (items[].name, quantity, price). The response carries a machine-readable coverage envelope (coverage, received, total_count, pages_read); coverage:"partial" MUST be reflected in the user-facing answer and forbids claiming the listing is complete.

List gift cards of the store (paginated), with optional status and purchase-date filters. The response carries a machine-readable coverage envelope (coverage, received, total_count, pages_read); coverage:"partial" MUST be reflected in the user-facing answer and forbids claiming the listing is complete.

Get a single gift card by its ID, including status, balance and purchase info.

List discounts of the store filtered by status (paginated). The status filter is required by the API. The response carries a machine-readable coverage envelope (coverage, received, total_count, pages_read); coverage:"partial" MUST be reflected in the user-facing answer and forbids claiming the listing is complete.

Get a single discount by its ID (title, value, dates, status, binding mode).

Create a new discount. Required: title, discount_value ({value, type: PERCENT|VALUE}), discount_dates ({start_date, optional end_date}), status (ACTIVE|INACTIVE) and binding_mode (ALL_VARIANTS|SELECTED_VARIANTS). Call get_operation_schema("CreateDiscount") for the exact request shape.

Update an existing discount (plain application/json PATCH): send only the fields to change (title, discount_value, discount_dates, status, binding_mode). Call get_operation_schema("UpdateDiscount") for the exact request shape.

Archive a discount (soft delete: status becomes ARCHIVED, the discount stops applying but stays restorable) or unarchive it (returns it to a non-archived status).

Attach objects to a discount or detach them. Supported object types: product_variant_ids (variant UUIDs), category_ids (category UUIDs), collection_ids (collection UUIDs). Per request pass EITHER product_variant_ids OR categories/collections — the API does not mix variants with categories/collections.

List promocodes of the store filtered by status (paginated). The status filter is required by the API. The response carries a machine-readable coverage envelope (coverage, received, total_count, pages_read); coverage:"partial" MUST be reflected in the user-facing answer and forbids claiming the listing is complete.

Get a single promocode by its ID (code, title, discount value, dates, type, usage limits).

Create a new promocode. Required: code, title, discount_value ({value, type: PERCENT|VALUE}), promocode_dates ({start_date, optional end_date}) and type (ORDER|PRODUCTS). Optional: binding_mode, minimum_order_amount, max_usage, max_discount_amount, one_time_use, first_order_only, show_in_pdp. The live API rejects codes containing lowercase letters even though the spec documents no format constraint — use uppercase Latin letters and digits (e.g. WELCOME5). Call get_operation_schema("CreatePromocode") for the exact request shape.

Update an existing promocode (plain application/json PATCH): send only the fields to change (code, title, discount_value, promocode_dates, status, binding_mode, limits). Call get_operation_schema("UpdatePromocode") for the exact request shape.

Attach objects to a promocode or detach them. Supported object types: product_variant_ids (variant UUIDs), category_ids (category UUIDs), collection_ids (collection UUIDs). Per request pass EITHER product_variant_ids OR categories/collections — the API does not mix variants with categories/collections.

List all webhooks of the store (not paginated). Each webhook has a URL, a list of subscribed event types and a status.

Get a single webhook by its ID (URL, subscribed events, status).

Create a new webhook. The url must use HTTPS (HTTP is rejected). Allowed events: ORDER_STATUS_CHANGED, ORDER_PAYMENT_STATUS_CHANGED, ORDER_DELIVERY_STATUS_CHANGED, CUSTOMER_CHANGED, CART_UPDATED. CUSTOMER_CHANGED fires when a customer appears or their name/phone/email changes; its data carries only {customer_id}, so a CRM sync must follow up with get_customer to read the new values (no before/after diff is delivered). CART_UPDATED fires when a customer changes their cart (clearing included); data is only {customer_id}, a series of changes to one cart collapses into one event, sent at most once per 15 minutes and up to 15 minutes late — read the current contents with get_customer_cart when handling it. NOTE: ORDER_STATUS_CHANGED will stop firing for the receipt-technical statuses CREATING_INITIAL_RECEIPT and CREATING_FINAL_RECEIPTS — key new integrations on ORDER_PLACED and COMPLETED instead (the statuses themselves stay readable via get_order). IMPORTANT: the response contains the signing secret — it is shown ONLY ONCE, store it securely. Call get_operation_schema("CreateWebhook") for the exact request shape.

Update an existing webhook: change url (HTTPS only), the subscribed events, or set deactivate=true to switch the webhook to INACTIVE. events is the full subscription list, not a delta — to add CART_UPDATED to an existing webhook, read it with get_webhook first and send its current events plus the new one. Call get_operation_schema("UpdateWebhook") for the exact request shape.

Permanently delete a webhook by its ID. This cannot be undone.

Trigger webhook validation: the API sends a POST with event WEBHOOK_VALIDATE to the webhook URL. With activate=true, the webhook becomes ACTIVE if the server replies HTTP 2xx with body {"message": "validated_store_{store_id}"} (store_id: see get_store).

List warehouses of the store (paginated). The API requires a status filter; defaults to ACTIVE when not provided. The response carries a machine-readable coverage envelope (coverage, received, total_count, pages_read); coverage:"partial" MUST be reflected in the user-facing answer and forbids claiming the listing is complete.

Get a single warehouse by its ID (title, slug, status).

Create a new warehouse. Required: title. The URL slug is generated automatically from the title and cannot be changed later. Call get_operation_schema("CreateWarehouse") for the exact request shape.

Update an existing warehouse via JSON Merge Patch: send only the fields to change; setting a field to null removes it. The slug cannot be changed after creation. Call get_operation_schema("UpdateWarehouse") for the exact request shape.

Archive a warehouse (soft delete: status becomes ARCHIVED, warehouse can no longer be used for stock) or unarchive it (status becomes ACTIVE again).

List collections of the store (paginated). A collection is a curated set of product cards: STATIC (filled manually via manage_collection_cards) or DYNAMIC (filled by filters). The response carries a machine-readable coverage envelope (coverage, received, total_count, pages_read); coverage:"partial" MUST be reflected in the user-facing answer and forbids claiming the listing is complete.

Get a single collection by its ID (title, slug, status, type, SEO fields).

Create a new collection. Required: title, status (ACTIVE|INACTIVE) and collection_type (STATIC|DYNAMIC; DYNAMIC also takes a dynamic_filter). Call get_operation_schema("CreateCollection") for the exact request shape. If a write returns HTTP 429, LIMIT_EXCEEDED, timeout or another uncertain result, read back the complete collection list and reconcile before considering any repeat; never blindly retry the create.

Update an existing collection (plain JSON PATCH; only the provided fields are changed). The collection type itself cannot be changed. Call get_operation_schema("UpdateCollection") for the exact request shape.

Permanently delete a collection by its ID. This cannot be undone.

Add product cards to a STATIC collection or remove them from it. Requires product_card_ids (array of product card UUIDs).

List the store's uploaded files with their URLs (paginated). Covers images (IMAGE) and other files (OTHER) only — videos live in a separate scenario, use get_video/list_videos. The response carries a machine-readable coverage envelope (coverage, received, total_count, pages_read); coverage:"partial" MUST be reflected in the user-facing answer and forbids claiming the listing is complete.

Upload a file (e.g. an image for a variant or collection) via multipart/form-data. Files are deduplicated by content: uploading identical bytes returns the existing file. Max size 100 MB. Provide exactly one source: file_path or content_base64.

Get metadata of a previously uploaded file by its ID (name, size, URL).

List product characteristics (paginated). The response carries a machine-readable coverage envelope (coverage, received, total_count, pages_read); coverage:"partial" MUST be reflected in the user-facing answer and forbids claiming the listing is complete.

Get one product characteristic by ID.

Create a product characteristic. Call get_operation_schema("CreateCharacteristic") for the exact request shape.

Update a product characteristic. Call get_operation_schema("UpdateCharacteristic") for the exact request shape.

List product characteristic groups (paginated). The response carries a machine-readable coverage envelope (coverage, received, total_count, pages_read); coverage:"partial" MUST be reflected in the user-facing answer and forbids claiming the listing is complete.

Get one product characteristic group by ID.

Create a product characteristic group. Call get_operation_schema("CreateCharacteristicGroup") for the exact request shape.

Update a product characteristic group. Call get_operation_schema("UpdateCharacteristicGroup") for the exact request shape.

List the color values of the store's characteristics with their hex codes (paginated). Colors are keyed by the characteristic value itself (e.g. «Красный»), not by an ID. The response carries a machine-readable coverage envelope (coverage, received, total_count, pages_read); coverage:"partial" MUST be reflected in the user-facing answer and forbids claiming the listing is complete.

Set the hex code of a color characteristic value. The value must already exist among the store's characteristic values (see list_characteristic_colors) — this endpoint recolors an existing value, it does not create one. Both fields are required.

List product videos of the store (paginated), oldest upload first. The API requires a status filter; defaults to all four statuses when not provided. The response carries a machine-readable coverage envelope (coverage, received, total_count, pages_read); coverage:"partial" MUST be reflected in the user-facing answer and forbids claiming the listing is complete.

Get a single video by its ID with the current processing status. Use it to poll after upload_video: the status walks UPLOADED -> PROCESSING -> READY (the content field with the player links is filled only in READY) or ends in ERROR (details in error). Poll at most once every 5 seconds — processing time scales with the video length.

Upload a product video via multipart/form-data and queue it for processing. Max size 100 MB; formats mp4, mov, webm, avi, flv. Videos are deduplicated by content: uploading identical bytes returns the existing video. The response carries the video ID — poll it with get_video until the status is READY, then attach the video to a variant through media in create_variant / update_variant (at most one video per variant, and the same media list must also carry at least one image). Provide exactly one source: file_path or content_base64.

Upload a product video by public link and queue it for processing — use it instead of upload_video when the file lives on the web rather than on this machine. Accepts a public Yandex.Disk link to a video file, a direct link to a video file, or a link to the Yandex KIT player (which returns the already uploaded video). The link must be reachable without authentication, otherwise the API answers 400. Same limits as upload_video: max 100 MB, formats mp4, mov, webm, avi, flv, deduplicated by content. The response carries the video ID — poll it with get_video until the status is READY, then attach the video to a variant through media in create_variant / update_variant (at most one video per variant, and the same media list must also carry at least one image).

List system alerts of the store (paginated), CRITICAL ones first and newest first within the same severity. The API requires a status filter; defaults to ACTIVE when not provided. The response carries a machine-readable coverage envelope (coverage, received, total_count, pages_read); coverage:"partial" MUST be reflected in the user-facing answer and forbids claiming the listing is complete.

Mark an alert as resolved. Only WARNING alerts can be closed by hand: an active CRITICAL alert is rejected with 400 and clears itself once the underlying problem is fixed. No request body is required.

List store news articles (paginated). The response carries a machine-readable coverage envelope (coverage, received, total_count, pages_read); coverage:"partial" MUST be reflected in the user-facing answer and forbids claiming the listing is complete.

Get one store news article by ID.

Create a store news article. Call get_operation_schema("CreateBlog") for the exact request shape.

Update a store news article. Call get_operation_schema("UpdateBlog") for the exact request shape.