Spoofy

Stop an automation for good: every future run is cancelled. Orders already running finish, unless cancel_running: true asks those that allow it to cancel too (the undelivered part is refunded). Confirm with the user first.

Ask to cancel a pending or processing order (only when the order says cancelable: true). Whatever was not delivered is refunded to the balance in USD. Confirm with the user first.

Set up an automation: Spoofy places ordinary orders for the user on a plan. Kinds: spread (a total over time, e.g. {"kind":"spread","service":12,"link":"…","quantity":10000,"over":"3d"}; pace "steady" or "front" for an S-curve growth plan), scheduled (one order at start_at), recurring (every "1d"/"6h"/"1w", optional at "14:00" + timezone, with times, until or budget), split (past one order's max), campaign (steps [{service, link, quantity, offset_minutes, over_minutes}] or template: "token-launch" + links), keep_above (target + days + budget; public Telegram channels/groups and YouTube videos only), feed (a public Telegram channel, YouTube channel or RSS feed: every new post gets quantity of service; max_per_day, budget). Service ids come from find_services. THIS SPENDS THE USER'S REAL BALANCE: each run is charged when it goes (never above the planned price). Call first without confirm (or with dry_run: true): you get the plan — every run's time, size and cost, the total and the balance. Tell the user the total and timing and get their explicit OK, then call again with confirm: true and an idempotency_key. Errors: bad_automation / bad_schedule (the message says what to change), budget_required, count_not_readable (keep_above only reads those links), bad_feed (X has no public feed), too_many_automations, over_order_cap / platform_not_allowed / read_only_key (this key's limits).

Place an order. THIS SPENDS THE USER'S REAL BALANCE (USD) and starts delivery to the link; it cannot be undone except by cancel_order where the service allows it. Before calling: get the price with get_quote and get the user's explicit agreement to that price. Then call with `confirm: true`. Without `confirm: true` nothing is charged and you get the price back so you can ask. `dry_run: true` validates everything (link fits the service, quantity range, key limits) and returns price, balance and whether it is enough — never charges. Pass a fresh `idempotency_key` per intended order so a retry never charges twice. Errors: insufficient_balance (details.shortfall = USD to top up — call get_top_up_info), over_order_cap / over_daily_cap / platform_not_allowed / read_only_key (this key's limits), wrong_platform, bad_quantity, link_busy (too many running on that link: details.available), chain_not_supported. Services with an `input` (find_services) take their fields in `inputs`: `comments` (custom comments, one per line or a list — their number is the quantity), `usernames` (accounts to mention), `hashtag`, `username`, `answer_number` (poll option, 1 = first), `runs` + `interval` (spread out; quantity is per run), or subscription terms (`min`, `max`, `posts`, `old_posts`, `delay`, `expiry`: auto-engagement on future posts, paid up front for at most max × posts). Text we post for the user is checked first: text_blocked = refused, nothing charged; a dry run says `text_review: true` when our team may check it before it starts. Errors also: bad_inputs, inputs_required. Done-for-you services (kind "manual": listings) need a form with images — those are ordered on the website.

Place up to 25 orders in one go — several services, one link or several — paid together from the balance. THIS SPENDS THE USER'S REAL BALANCE (USD) and starts delivery. Use it when the user wants several things at once (e.g. followers + likes + views for one account); for one order use place_order. Every order is checked first at today's price: if any one cannot go (link does not fit, quantity out of range, too many running on one link, balance short…) NONE is placed and each item says why. Then they are placed one by one; should one fail at that very moment, the others stay placed and that one says why (nothing charged for it). Without `confirm: true` nothing is charged: you get each price and the total so you can ask the user. With `confirm: true` also pass `max_total` = the total the user agreed to; if prices moved above it nothing is placed (price_changed). Pass a fresh `idempotency_key` per intended batch: a retry with the same key never places an order twice. Each item takes what place_order takes: `service`, `link`, `quantity`, or `inputs` for services with an `input`. Errors: batch_invalid (details.items says which and why), insufficient_balance (details.shortfall = USD to top up — call get_top_up_info), order_rate_limited, over_daily_cap, price_changed, idempotency_conflict.

Carry on with a paused automation: the rest of the plan moves by the time it was paused. After a price change, resuming accepts the new price for the runs left — tell the user first.

Stop placing new runs until it is resumed (orders already running keep delivering). Nothing is charged while paused.

Find what Spoofy can do for a link or a goal, with prices. ALWAYS call this first: service ids come from here. Give `link` (any profile, post, video, channel, group, token page or website URL) and/or `goal` in plain words, e.g. "500 followers on my tiktok" or "cheap views for this YouTube video". With a link you only get services that fit that exact link (a profile link gets followers, a post link gets likes/views). Returns matching services: `service` (the id to quote/order), name, tier (basic/standard/premium), pricePer1k (USD per 1,000 units), min/max quantity, start time, speed, preset packages with USD prices, and — when the goal names a quantity — a `suggestion` with the exact total for that quantity. A service with an `input` needs those fields in place_order `inputs` (custom comments, accounts to mention, a hashtag, a poll option, runs, subscription terms); `input.quantity` says where the quantity comes from. `query` narrows to services whose words match, e.g. "usa", "brazil", "real", "story". Free; spends nothing. On every service, counts can drop after delivery and drops are not replaced — tell the user before they buy followers, members or likes.

One automation with its timeline: every run, the order it placed and what that delivered, or why a run waits or was skipped (balance, budget, a daily limit).

The user's spendable balance in USD. Orders are paid from it.

Status and progress of one order: status (pending, processing, completed, partial, refunded, cancelled, failed), start count, delivered, remains, charge and refunds in USD, and whether it can be cancelled now.

Exact price in USD for a quantity of one service (from find_services). Checks the quantity is within the service range. Free; spends nothing. Use it to tell the user the cost before place_order. For services with an `input`, pass the same `inputs` as for place_order; the quantity is then the units charged: the number of comments or usernames, per run × runs, or for subscriptions max × (posts + old_posts).

How the user adds money to the balance: stablecoins (USDC, USDT or USDG, on the networks that are on) sent to their own deposit address — one address for every EVM network, another on Solana — credited 1 coin = $1, plus the top-up page link. Use it when an order fails with insufficient_balance. Tell the user to send only the listed coin on the listed network. You cannot move money yourself — give the user the address or the link.

The user's automations, newest first, with progress (runs placed, delivered), spend against budget and the next run. Filter by status.

The user's orders, newest first. Filter by status; page with `before` = the smallest order number already seen.