Skip to main content
Glama

Create Bulk Purchase

create_bulk_purchase
Destructive

Place bulk purchase orders for Wistia media, including captions, localization, audio descriptions, or text translations, in one asynchronous batch.

Instructions

Submits either an actions array of up to 1000 orders or one job that can resolve to up to 5000 media. Orders are placed asynchronously. Returns a background job status whose Show endpoint reports aggregate progress and per-order results.

Orders in the batch can incur charges, so a saved credit card is required. Supported resource types are captions (Wistia-generated English captions), localization (a dubbed, language-specific version of a media), extended_audio_description, and text_translation (the media's transcript translated into another language, audio untouched). Each order's id is the hashed ID of the media to order for.

What an order costs depends on the account, not on this endpoint. Automated captions are included at no cost on plans that provide them and billed at the account's configured per-minute rate otherwise; human-reviewed captions bill per minute at the account's standard or rush rate; localizations bill per minute once the account's free-dub allowance is used up; text translations bill as an overage once the account's included translation minutes are used up. Check the account's plan and billing settings for its actual rates.

Orders are priced and placed individually: failures -- an ineligible media, a language that already has a localization, an account not entitled to buy -- are reported per order and do not stop the rest of the batch. Pricing and eligibility match the equivalent single-media endpoints exactly.

Use the Create Bulk Actions endpoint for create, update, and delete work; it does not accept purchase, and this endpoint accepts nothing else.

Requires api token with one of the following permissions

Read, update & delete anything

Tokens with the "Act with a team member's permissions" permission (all:delegate_to_contact_permissions scope) can also be used. Requests made with such a token are authorized using the permissions of the contact assigned to the token. Requires confirm=true for the requested mutation. May share access, notify people or incur provider charges.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
jobNoOne order placed for many media, named by a parent (`scope`) or listed explicitly (`ids`), so ordering captions for a folder of 47 videos takes one job rather than 47 orders. A `scope` resolves to exactly what List Media returns for that parent, including media in the folder's subfolders and **archived** media, and to at most 5000 media -- beyond that the job is rejected rather than truncated. The job attempts one order for every media it resolves to. Ineligible media fail individually without placing an order; successful orders are metered and may incur charges according to the account's plan. Confirm the scope and potential cost with the customer before submitting. Not available to external contacts.
accountNoNamed private Wistia account; selects credentials, not a remote account ID.
actionsNoThe orders to place, one per media. Maximum 1000 per request, and the request body must stay under 2 MB -- whichever limit is reached first. An oversized body is rejected with a `413` and no order in it is placed. Every order is priced and placed independently: one failing (an ineligible media, an account without a saved card, a language that already has a localization) does not stop the rest of the batch. Use `job` instead to order for a whole folder, channel, or account.
confirmNoMust be true for the specific user-requested write.
payloadNoComplete JSON request body instead of body flags. Supports current nested customization, caption and nullable values.
payload_fileNoRegular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare destructive=true, openWorld=true, idempotent=false, readOnly=false, but the description adds critical behavioral context beyond those flags: asynchronous execution, background job status via a Show endpoint, aggregate and per-order results, per-order independent pricing/placement, individual failure behavior, billing mechanics per resource type, and the saved-card requirement. It also notes that a 5000-media scope is rejected rather than truncated, which is operationally important.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core abstraction (actions vs job, async, background job result) and then layers billing and error semantics. It is longer than ideal and the billing paragraph is dense, but each paragraph carries operational information an agent needs before invoking a paid, destructive batch endpoint.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given this is a destructive, paid, open-world batch mutation with no output schema, the description covers what an agent needs: async semantics and status retrieval, per-order failure isolation, billing variability, saved-card requirement, scope size limits, and sibling routing. Almost nothing required to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the nested schemas already document job/actions/scope/ids/payload extensively, including per-resource payload options. The description reinforces the actions-vs-job split and the per-order pricing/eligibility model, but that overlaps with what the schema already states, so it adds marginal value over structured data.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb (submits/places orders) and resource (bulk purchase of captions/localization/extended_audio_description/text_translation), and explicitly distinguishes itself from the sibling create_bulk_actions by noting that this endpoint accepts only 'purchase' while the other does not. An agent can tell it apart from purchase_captions, order_extended_audio_description, and create_localization because it operates on batches.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly tells when to use `actions` (up to 1000 orders named by id) vs `job` (one scope resolving to up to 5000 media), and names the alternative sibling (Create Bulk Actions) for non-purchase work. It also states prerequisites (saved credit card, confirm=true) and per-order failure semantics, which is strong routing guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools