GrowVib: Social Media Growth

Create a checkout session: a payment link a PERSON opens and pays in their own USDC wallet (Base or Solana), for when you cannot sign a payment yourself or the user wants to pay with their own wallet. Pick the service with search_catalog or recommend_service and price it with get_quote first, then call this with service_id, quantity and link. The result carries page_url (give it to the person), the exact amount, expires_at (the price is held until then, 30 minutes by default) and a token for get_checkout_status. Creating a session moves no money and reserves nothing: nothing is charged until the person signs in their wallet, and an unpaid session simply expires. Each call opens a NEW session, so call it once per intended order and reuse the token you were given. Prefer create_paid_order when you hold a wallet and should pay yourself.

Place an order and pay for it with USDC on Base or Solana, with no GrowVib account and no human in the loop, using the x402 payment protocol. Call it FIRST without the `payment` argument: it returns the exact payment requirements, one `accepts` entry per network (amount in atomic units, asset, recipient, network, and for Solana the facilitator's feePayer). Pick the network your wallet is on: sign an EIP-3009 transferWithAuthorization (Base) or build and sign the USDC transfer transaction (Solana) for exactly those requirements, then call it AGAIN with the same arguments plus `payment` set to the signed x402 payment payload. Anything paid above the order's price stays as spendable balance on the wallet's account, so many small orders can be paid for with one settlement. If a call reports that the payment is still being confirmed, do NOT sign and send a new payment: the first one may already have gone through. Use get_quote first if you only want a price.

Read a checkout session created with create_checkout: its status (open, pending, paid, paid_no_order, failed, expired), the frozen quote, and once paid the payment and the order with its tracking code. Poll it after handing the person the link, every few seconds, until it reports paid or expired. `pending` means a payment is being confirmed: tell the person to wait, never to pay again. `paid_no_order` means the money arrived as balance on the paying wallet's account but the order could not be placed; the person was told to contact support. Read-only and idempotent, so polling is safe.

Track an order placed with create_paid_order: status, start count and remaining quantity, plus a delivery block (the start window the option lists, its bound in minutes, whether delivery has started, and start_overdue when an active order has not started past that bound). Delivery is gradual once it starts and completion time is not estimated, so a falling remains is progress, not a stall. Pass the `agent_token` that create_paid_order returned (or one from the wallet sign-in at POST /v1/agent/auth/challenge). Read-only and idempotent, so polling it is safe. Statuses: PENDING, SUBMITTED, PROCESSING, COMPLETED, PARTIALLY_COMPLETED, CANCELED, FAILED, PARTIALLY_FAILED, REFUNDED, PARTIALLY_REFUNDED.

Get the exact price that will be charged, with no account needed. Call this before every order: never total up the per-1000 prices the catalog tools return yourself, because the quantity bounds and rounding are applied here and nowhere else. Returns unit price and total in USD, priced by the same server-side path a real order uses. It places no order and charges nothing. The result's payment_methods says how the order can be paid: from a connected GrowVib account (connect one over OAuth at the /mcp endpoint, which is where the account ordering tool lives), or, when listed, with no account at all over x402 (USDC on Base or Solana, via create_paid_order or the REST endpoint it names; payment_methods.x402.networks lists the rails).

Look up ONE service you already have the id for. No id yet? Find one with search_catalog. Want a single option chosen for a quantity rather than all of them? Use recommend_service. Returns the service's full detail, including ALL of its plan options (id, name, price per 1000, min/max quantity, quality tier, typed axes such as country or watch length, listed delivery speed and start window, and the recommended flag), so you can present the available plans and quantity range to the user, then pass the chosen service_option_id to get_quote and create_paid_order (this endpoint lists it while the accountless x402 payment channel is on), or create_checkout when a person will pay in their own wallet instead (listed while checkout sessions are on).

List the orders belonging to the wallet behind an agent_token, newest first, each with the same fields get_paid_order_status returns. Use it when you no longer have the order_id an order gave you: after a restart, when resuming work another session started, or to check everything this wallet has bought. Pass the `agent_token` from any of its orders (or from the wallet sign-in at POST /v1/agent/auth/challenge). Optional `status` narrows to one order status, `page` and `page_size` page through the rest (page_size defaults to 10 and is capped at 100; the result carries the total so you know when to stop). Read-only and idempotent, so polling it is safe.

Choose WHICH plan option to order, once you know what to buy and for how many. Use it instead of comparing options yourself from search_catalog or get_service. Takes a service (or a platform plus a goal), a quantity, an audience and a preference. Returns one recommended option plus the cheapest, highest-tier and fastest-listed alternatives. Each pick carries the price per 1000, the total for this quantity, the quantity range it accepts, its quality tier, typed axes such as country or watch length, the listed delivery speed and start window, a sensitive flag marking a deliberate product such as a negative reaction, and short reasons written for the buyer. Branch on the typed fields; the reasons are prose in the requested locale and state only what an option gives, so their absence is never a drawback. One reason states how many independent delivery pools can serve the option, when two or more can: it is a count of the ways we can deliver it, not a promise about any one order, and a pick without it is not worse. The response also says how many options were considered, how many fit, and why the rest fell out (rejected: audience_mismatch, quantity_below_min, quantity_above_max, dominated). It carries quoted_at and catalog_version: the version fingerprints the option data the answer came from, so if you recommend, ask the user, then order, re-call and compare catalog_version to know whether the card changed in between. Prices are live at order time; placing an order re-prices from the same data get_quote does, so treat quoted_at as when this answer was computed, not as a price hold. tradeoffs compares each alternative with the lead as data (price and total deltas, quality steps, listed speed ratio, start bucket delta, max quantity delta, plus gives and costs naming the dimensions it wins and loses on; null means one side lists nothing). Use it to CHOOSE and to explain a choice as what each option gives ("$18.60 less for one tier lower and twice the listed rate"); never present a pick to the user as a percentage more expensive than another. Identify the service by service_id (from search_catalog) OR by platform + goal (the deliverable, e.g. platform "youtube" and goal "short-views" or "followers"). Read-only: it places no order. Pass the returned option_id as service_option_id to get_quote and create_paid_order (this endpoint lists it while the accountless x402 payment channel is on), or create_checkout when a person will pay in their own wallet instead (listed while checkout sessions are on).

START HERE when you do not yet know which service to buy: this is the entry point to the catalog. Already have a service id? get_service returns that one in full detail. Know the service and only need the right plan for a quantity? recommend_service picks one. Searches the sellable social growth service catalog (Telegram, Instagram, TikTok, YouTube and more). Each result includes the service (id, name, platform, starting/cheapest price per 1000) AND up to 8 of its plan options (the recommended and cheapest ones, each with id, name, price per 1000, min/max quantity; options_total says how many there are and get_service returns them all) - present the options to the user and let them choose a plan, then pass that service_option_id to get_quote and create_paid_order (this endpoint lists it while the accountless x402 payment channel is on), or create_checkout when a person will pay in their own wallet instead (listed while checkout sessions are on) instead of defaulting to the cheapest.