Tasks

Tasks are what the platform actually does. Everything else (accounts, proxies, profiles, integrations) exists so that a task can run. One endpoint creates them, the rest let you watch, retry, and stop them.

Two scopes cover the domain. tasks.read for the catalogue, the listings and a single task, tasks.write for creating, retrying, cancelling and deleting. POST /api/v1/tasks/preview also needs tasks.write even though it writes nothing, so a read-only key cannot size up a selection.

Start at the task catalogue. It tells you the 44 types you may create, the exact config each one accepts, and which of them your plan covers. A client that guesses instead will cache the wrong shapes and find out through 422.

Selecting accounts #

Creating tasks and previewing a selection both take a selection: which Steam accounts the work targets. There are two shapes, and you send exactly one.

{ "account_ids": ["019fb42e-9a61-70d2-818a-f6a56593f3a5", "019fb42e-9a7e-728d-b960-8b4c2162898c"] }

An explicit list, capped at 1,000 ids. Over the cap you get 422 bulk_limit_exceeded with the cap in max.

{ "filters": { "guard": "mobile", "wallet": "has" }, "exclude_account_ids": ["019fb42e-9a7e-728d-b960-8b4c2162898c"] }

A definition resolved on the server. The ids are never materialized, so "every account with a mobile authenticator" is the same size on the wire whether it names four accounts or forty thousand. A filter selection always runs asynchronously and always answers 202, even when it happened to resolve small enough to run inline.

Sending both is refused, and so is sending neither: a request with no selection would otherwise mean "every account I own" by accident.

Filter keys #

wallet_min and wallet_max compare natively when wallet_currency is also set. Without it, balances are normalized to USD, because a bare number would otherwise compare 15 PLN against 15 EUR. An account whose balance has never been reported matches neither bound.

session is read from the live worker registry rather than a column. While no worker is reporting, the filter is ignored rather than matching nothing.

search, session, tags, exclude_tags, groups, and include_ungrouped are spelled the same in both vocabularies. For the other account-side filters, use GET /api/v1/accounts to get the ids and pass them as account_ids.

Task lifecycle #

A task moves through six statuses.

The last three are final. Nothing leaves them.

Parents and children #

How many accounts are eligible decides the shape of what you get back.

• One eligible account: a single standalone task, bound to that account. 201 with the task record.
• Many eligible accounts: a batch parent with one child task per account. The parent has no steam_account_id of its own and carries the rolled-up counters in children.
• More than 500 eligible accounts, or any filter selection: the same batch parent, but built by a queued job. 202 with just the parent's id.

"Eligible" excludes accounts that already have a pending, queued or running task of the same type, which is what stops a repeated call from double-queueing anyone. It also excludes accounts a type cannot work on: check_bans skips accounts with no steam64_id, assign_currency skips accounts that already have a wallet, place_buy_order skips accounts that cannot fund the order, change_password skips accounts missing a stored Steam password or either authenticator secret. Those show up as accounts_skipped.

When anything was skipped, the response also carries accounts_skipped_reasons: an object of reason slug to account count. An account failing several checks is counted once, against the first check it failed, so the counts sum to accounts_skipped (any remainder a reason could not be pinned on is simply not listed). The slugs are stable:

The field is absent when nothing was skipped, and on the few pipelines that do not attribute their skips (distribution, boosting, trade-ups).

Following a fan-out #

curl "https://dashboard.steamlabs.dev/api/v1/tasks/019fb431-2c88-71ea-b0a3-8ce2f5d19b07" \
  -H "Authorization: Bearer $STEAMLABS_API_KEY"

Poll the parent. It sits at Queued while its children are still being written, flips to Running once they all exist, and finishes when the last child does. children.total grows as the batch is built, so treat completed + failed + cancelled == total as done rather than watching total alone.

For per-account detail, use GET /api/v1/tasks/{id}/children. Do not page the whole child set just to count outcomes: the parent's counters already have them.

Discover what you can create #

Every creatable type, its config schema, and whether your plan covers it.

Requires tasks.read.

curl "https://dashboard.steamlabs.dev/api/v1/task-types" \
  -H "Authorization: Bearer $STEAMLABS_API_KEY"

import requests

types = requests.get(
    "https://dashboard.steamlabs.dev/api/v1/task-types",
    headers={"Authorization": f"Bearer {api_key}"},
).json()["data"]

creatable = {t["type"]: t["config_schema"] for t in types if t["allowed"]}

const response = await fetch('https://dashboard.steamlabs.dev/api/v1/task-types', {
    headers: { Authorization: `Bearer ${apiKey}` },
});

const { data } = await response.json();
const creatable = data.filter((type) => type.allowed);

{
    "data": [
        {
            "type": "claim_weekly_drops",
            "label": "Claim Weekly Drops",
            "description": "Claim each account's two weekly CS2 drops, picked automatically by highest price or from your selection.",
            "category": "cs2",
            "requires_steam_account": true,
            "allowed": true,
            "blocked_by": null,
            "plan": null,
            "config_schema": {
                "strategy": {
                    "type": "string",
                    "required": true,
                    "enum": ["highest_price", "manual"],
                    "default": "highest_price"
                },
                "ignore_graffitis": { "type": "boolean", "required": false, "default": false },
                "claim_item_ids": {
                    "type": "array",
                    "required": false,
                    "max": 2,
                    "default": [],
                    "items": { "type": "string", "required": false, "max": 64 }
                }
            }
        },
        {
            "type": "trade_up_contract",
            "label": "Trade-Up Contract",
            "description": "Craft 10 same-rarity skins into 1 skin of the next rarity, picked automatically by expected value or by hand.",
            "category": "cs2",
            "requires_steam_account": true,
            "allowed": false,
            "blocked_by": "plan",
            "plan": {
                "heading": "Not included in your plan",
                "badge": "Available on Pro or higher",
                "upgrade_url": "https://dashboard.steamlabs.dev/subscription"
            },
            "config_schema": { "…": {} }
        }
    ],
    "meta": { "page": 1, "per_page": 50, "total": 33, "last_page": 1 }
}

Locked types are listed, not hidden, exactly as the panel greys them instead of dropping them. allowed is false and plan carries the same block a 403 plan_limit_reached would return, so an integration can tell "you have not bought this" apart from "this does not exist".

blocked_by says why a locked entry is locked: plan (buy more plan) or maintenance (wait it out). During platform maintenance every entry reports allowed: false with blocked_by: "maintenance", and the plan block's upgrade_url is null because no purchase lifts it.

category is one of account, profile, trading, inventory, market, cs2, tf2. requires_steam_account is false for the four orchestration types (distribute_items, store_items, withdraw_items, sell_items), whose parents group per-account children rather than reaching a worker themselves.

Reading a config schema #

Each field in config_schema is described with the same descriptor the server validates against, so the two cannot drift.

Fields that are not required accept null, which means the same as leaving the key out.

List tasks #

Requires tasks.read.

curl "https://dashboard.steamlabs.dev/api/v1/tasks?top_level=true&status=running&per_page=1" \
  -H "Authorization: Bearer $STEAMLABS_API_KEY"

$tasks = Http::withToken($apiKey)
    ->get('https://dashboard.steamlabs.dev/api/v1/tasks', [
        'top_level' => true,
        'status' => 'running',
    ])
    ->json('data');

{
    "data": [
        {
            "id": "019fb431-2c88-71ea-b0a3-8ce2f5d19b07",
            "type": "refresh_details",
            "status": "running",
            "is_batch_parent": true,
            "is_cancelling": false,
            "parent_id": null,
            "steam_account_id": null,
            "steam_account": null,
            "children": { "total": 4182, "completed": 3907, "failed": 12, "cancelled": 0 },
            "error": null,
            "worker_id": null,
            "bytes_sent": null,
            "bytes_received": null,
            "cancel_requested_at": null,
            "dispatch_after": null,
            "started_at": "2026-07-30T14:02:11+00:00",
            "finished_at": null,
            "created_at": "2026-07-30T14:01:58+00:00",
            "updated_at": "2026-07-30T14:19:40+00:00"
        }
    ],
    "meta": { "page": 1, "per_page": 1, "total": 1, "last_page": 1 }
}

bytes_sent and bytes_received are what the worker measured on the wire while running the task. They are null when it reported nothing, which is not the same as zero, so skip those rows rather than coerce them when you add figures up. A task that was re-queued reports only what its final attempt moved. The same bytes roll up per proxy, account and source under bandwidth usage.

task_data and logs are deliberately absent from list rows. A storage batch's payload carries thousands of asset ids and a finished task's log is unbounded, so a 200-row page would be megabytes nobody asked for. Both are on the single-task response.

top_level=true is the filter you want for a dashboard. Without it, a 100,000-account batch puts 100,000 children in your list.

Preview a selection #

Resolve a selection and count it, without creating anything.

Requires tasks.write. No Idempotency-Key: it writes nothing, so a retry costs one COUNT(*).

Takes a selection and nothing else. No type, no config.

curl -X POST "https://dashboard.steamlabs.dev/api/v1/tasks/preview" \
  -H "Authorization: Bearer $STEAMLABS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"filters": {"guard": "mobile", "market": "eligible"}}'

affected = requests.post(
    "https://dashboard.steamlabs.dev/api/v1/tasks/preview",
    headers={"Authorization": f"Bearer {api_key}"},
    json={"filters": {"guard": "mobile", "market": "eligible"}},
).json()["accounts_affected"]

if affected > 500:
    raise SystemExit(f"refusing to queue {affected} accounts")

{ "accounts_affected": 4182 }

The count is the selection, not the eligible set. POST /api/v1/tasks will usually create fewer tasks than this, because accounts that already have a task of the same type queued are skipped.

Cancel many tasks #

Requires tasks.write.

Explicit ids only. There is no filter mode here on purpose: these act on task rows you have just listed and can see, and "cancel everything queued" is a blast radius you should have to spell out.

curl -X POST "https://dashboard.steamlabs.dev/api/v1/tasks/cancel" \
  -H "Authorization: Bearer $STEAMLABS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"task_ids": ["019fb431-2c88-71ea-b0a3-8ce2f5d19b07", "019fb431-3d0f-7002-9a41-51c8b6f7e2aa"]}'

{ "cancelled": 1, "skipped": 1 }

skipped covers everything that did not move: tasks that finished between your listing and this call, tasks already cancelling, children of a live batch (cancel the parent instead), and ids that are not yours.

Create tasks #

The endpoint everything else on this page exists to support.

Requires tasks.write. Requires an Idempotency-Key header. See Bulk operations.

curl -X POST "https://dashboard.steamlabs.dev/api/v1/tasks" \
  -H "Authorization: Bearer $STEAMLABS_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: $(uuidgen)" \
  -d '{
        "type": "sell_items",
        "config": { "marketplace": "steam", "mode": "undercut", "undercut_cents": 1, "categories": ["container"], "max_items": 50 },
        "filters": { "market": "eligible", "inventory": "synced" }
      }'

$response = Http::withToken($apiKey)
    ->withHeaders(['Idempotency-Key' => (string) Str::uuid()])
    ->post('https://dashboard.steamlabs.dev/api/v1/tasks', [
        'type' => 'sell_items',
        'config' => [
            'marketplace' => 'steam',
            'mode' => 'undercut',
            'undercut_cents' => 1,
            'categories' => ['container'],
            'max_items' => 50,
        ],
        'filters' => ['market' => 'eligible', 'inventory' => 'synced'],
    ]);

$taskId = $response->json('task_id') ?? $response->json('id');

const response = await fetch('https://dashboard.steamlabs.dev/api/v1/tasks', {
    method: 'POST',
    headers: {
        Authorization: `Bearer ${apiKey}`,
        'Content-Type': 'application/json',
        'Idempotency-Key': crypto.randomUUID(),
    },
    body: JSON.stringify({
        type: 'refresh_details',
        account_ids: ['019fb42e-9a61-70d2-818a-f6a56593f3a5'],
    }),
});

import uuid, requests

response = requests.post(
    "https://dashboard.steamlabs.dev/api/v1/tasks",
    headers={
        "Authorization": f"Bearer {api_key}",
        "Idempotency-Key": str(uuid.uuid4()),
    },
    json={
        "type": "claim_weekly_drops",
        "config": {"strategy": "highest_price", "ignore_graffitis": True},
        "filters": {"guard": "mobile"},
    },
)

What you get back #

201 Created, when explicit ids resolved to 500 or fewer eligible accounts. The task record (a standalone task, or the batch parent) plus two counters:

{
    "id": "019fb440-7a10-7c33-bd51-2f0c9e4471d2",
    "type": "refresh_details",
    "status": "queued",
    "is_batch_parent": false,
    "is_cancelling": false,
    "parent_id": null,
    "steam_account_id": "019fb42e-9a61-70d2-818a-f6a56593f3a5",
    "steam_account": {
        "id": "019fb42e-9a61-70d2-818a-f6a56593f3a5",
        "username": "farm_017",
        "persona_name": "Ada",
        "steam64_id": "76561198000000017"
    },
    "children": { "total": 0, "completed": 0, "failed": 0, "cancelled": 0 },
    "error": null,
    "worker_id": null,
    "bytes_sent": null,
    "bytes_received": null,
    "cancel_requested_at": null,
    "dispatch_after": null,
    "started_at": null,
    "finished_at": null,
    "created_at": "2026-07-30T14:02:11+00:00",
    "updated_at": "2026-07-30T14:02:11+00:00",
    "tasks_created": 1,
    "accounts_skipped": 0
}

202 Accepted, for every filter selection and for any batch over 500 eligible accounts. The parent exists, its children are being written by a queued job:

{
    "task_id": "019fb431-2c88-71ea-b0a3-8ce2f5d19b07",
    "accounts_affected": 4182,
    "accounts_skipped": 311,
    "accounts_skipped_reasons": { "task_in_flight": 292, "never_refreshed": 19 }
}

200 OK, only for a trade-up dry run (config.trade_up_dry_run: true). Guardrails were evaluated, nothing was created and nothing was consumed:

{
    "dry_run": { "contracts": 42, "slots": 378, "cost": 118.44, "ev": 131.02, "scanned": 100, "total": 4182 }
}

The dry run scans at most the first 100 accounts of the selection, so scanned and total differ on anything large.

When nothing is created #

The two 422s are different answers and worth telling apart. no_eligible_accounts means "pick different accounts"; nothing_to_plan means "the accounts were fine, their inventories were not".

plan_limit_reached is not transient, and retrying never fixes it. GET /api/v1/task-types tells you which types are locked before you ask, and GET /api/v1/me reports allowed_task_types and allowed_marketplaces outright. The marketplace half bites sell_items (per its config.marketplace) and place_buy_order (always Steam).

What Steam is giving away #

The giveaway catalogue behind claim_free_games: the paid games Steam is currently handing out permanently. Refreshed hourly from Steam's own store feed.

Requires account.read, not tasks.read: this describes what Steam is offering, not anything you own or have queued.

curl https://dashboard.steamlabs.dev/api/v1/free-games \
  -H "Authorization: Bearer $STEAMLABS_API_KEY"

{
    "data": [
        {
            "app_id": 2000040,
            "name": "Space Menace",
            "package_id": 1827145,
            "header_image": "https://shared.akamai.steamstatic.com/store_item_assets/steam/apps/2000040/header.jpg",
            "normal_price_cents": 699,
            "ends_at": "2026-09-23T17:00:00+00:00",
            "store_url": "https://store.steampowered.com/app/2000040/"
        }
    ],
    "meta": { "page": 1, "per_page": 50, "total": 1, "last_page": 1 }
}

Most of the time this list is short, and often it is empty: giveaways come and go a few times a month. The list is read from one region, so an entry is an offer worth trying rather than a promise that a given account can take it.

You do not have to wait for this catalogue to notice a promotion. A claim_free_games task accepts any app id, and each account checks its own store page, so nothing is claimed unless Steam actually offers it there.

Config by task type #

config is validated against the type you sent. Every type below is creatable; the shapes here are the same descriptors GET /api/v1/task-types publishes.

Throughout: min and max are a numeric bound on numbers, a character length on strings, and an item count on arrays. Fields not marked required may be omitted or sent as null, which mean the same thing.

Item conditions #

Four types narrow which items they act on with the same shared block: sell_items, distribute_items (also inside each routing rule), store_items and withdraw_items.

Leave the whole block out and the type acts on everything it can. That is fine for a storage deposit and expensive for a sale, which is why sell_items demands an explicit acknowledgement (see below). float_min and float_max are CS2-only and are refused when games is set and does not include cs2.

No configuration #

These take no config at all. Send {} or leave the key out.

Account and wallet #

change_password sets a new Steam password on every eligible account through the logged-in help wizard and a mobile Steam Guard confirmation. Accounts without a stored password, shared secret, or identity secret are skipped. After Steam accepts the change, the stored password is updated and the session is cleared so the next task logs in fresh.

Two modes. Omit mode (or send password) to type one password for every account. Send mode: generate to mint a unique password per account at create time. Read a generated password from an account export or from the account Credentials tab after the task succeeds. The task itself never returns it.

At least one of lowercase, uppercase, digits, or symbols must be true when generating. The password is stored only so the worker can apply it. GET /api/v1/tasks/{id} omits it from task_data, including on a batch parent.

request_free_licenses registers the free licence for the games you name.

In all mode every account registers every app id you sent. In random mode each account draws its own random_count games from that pool, so a fleet ends up with varied libraries rather than one list repeated across every account. The draw happens when the tasks are created, so each child task already names the games it will register and a retry repeats that account's own draw. Games an account does not already own are drawn first, so the count delivers new licences wherever there are new licences left to give.

This is the free-to-play door: it registers a free-on-demand licence, which works for permanently free titles such as CS2, Dota 2 or Team Fortress 2. It does not claim a limited giveaway. Steam accepts the request for one and grants nothing, without an error. Use claim_free_games for those.

claim_free_games claims the paid games Steam is currently giving away permanently, the store's one-click "Add to Account" button.

all_active claims every giveaway running at the moment the task is created, read from the giveaway catalogue. The list is resolved to concrete app ids before anything is queued, so the created task names the games it actually tried, and retrying it later claims that same set rather than whatever is free by then.

Per account, each game ends up in exactly one of four buckets, reported in the finished task's task_data:

unavailable is not an error. Giveaways are regional, so on a fleet whose proxies exit in different countries a real share of accounts land there, and those accounts are never asked about that game again. failed is treated as transient and can be retried.

Accounts with nothing left to do are skipped rather than queued, and reported under the already_claimed skip reason.

redeem_wallet_code redeems Steam wallet codes, one code per account.

The batch is capped at the number of codes you sent: 40 codes across a 600-account selection creates 40 tasks and reports the rest as skipped. Codes are single use, which is the reason this endpoint carries an Idempotency-Key.

add_funds_paysafecard starts a wallet top-up and returns a payment link to finish off-site.

A tier maps to the nearest denomination in each account's currency, so accounts in a currency with no denomination table are skipped rather than dispatched amountless.

Both modes need the account to already hold a wallet currency. Steam assigns one when the account's wallet is first opened, not from its store country, so an account that has never been funded has no currency to pay in even though the store shows prices in one. Those accounts are skipped as no_wallet_currency in either mode; run an assign_currency task on them first, which opens the wallet for free, then top up. You can list them with the account filter wallet_currency: "none".

add_funds_blik starts a Steam wallet top-up via Blik and returns a payment link to finish off-site. Blik is PLN only, so there are no tiers: one exact amount, applied to every selected account.

Accounts whose wallet currency is not PLN are skipped rather than dispatched. The wallet payment this produces has provider blik; open its pay_url (see the wallet payments endpoint) to complete the payment.

buy_package buys a Steam store package with the account's wallet balance.

With an insufficient_funds_method set, accounts that already have a pending wallet payment are skipped (topup_already_pending): Steam allows one open checkout transaction per account, and a new one would silently cancel the pending payment. With blik, accounts whose wallet currency is not PLN are skipped (unsupported_wallet_currency), and accounts with no Steam wallet at all are skipped as no_wallet_currency.

assign_currency gives a walletless account a wallet currency, so market and checkout work can run.

Only accounts with no wallet currency are eligible: Steam refuses to open a second wallet. A billing address for the currency's country is generated and stored on each account as part of the task.

buy_point_shop_items spends Steam Points on exact rewards or a filtered catalogue shortlist.

The server freezes the matching definition ids and approved prices when you create the task. Every account uses that same immutable shortlist. The worker fetches each live definition again before buying and skips it when the price changed, the item disappeared, the account already owns it, or Steam says the account is not eligible.

Seasonal badges (community_item_class 1) use Steam's badge-level redeem, not the ordinary item redeem. One purchase can buy several levels of the same badge, one level per 1000 points on the current Summer and Winter collections, up to level 40. max_purchases counts each level. An account already at the cap is recorded as already owned. Only the collection Steam's Seasonal Badge page is selling right now (Summer from June through November, Winter from December through May) can be selected or redeemed. Older collections stay in Steam's catalogue as active, and the worker records them as unavailable instead of spending points.

When owned_games_only is on (the default) and at least one selected account has a synced library, the frozen shortlist is taken from those owned games, plus rewards that are not tied to a game, including seasonal badges (they use an event app id that no library owns). That stops cheapest-first from filling the list with rewards a CS2 farm cannot buy. Each account still drops anything it does not own at run time. Rewards that cost nothing and rewards not tied to a game stay eligible for that per-account filter, and an account whose library has never been refreshed is not filtered. Expired free promotions (no end date) are left out of matching-item plans. Currently running free giveaways stay in.

A run that buys nothing because every remaining candidate was unavailable, not eligible, or for a game the account does not own fails the task instead of completing. An account that only skipped items it could not afford, or already owned, still completes.

Two kinds of candidate are dropped before the account touches Steam, so they never consume an attempt and stay available to a later run. owned_games_only drops rewards belonging to a game the account has no licence for, because Steam always refuses those. Separately, a candidate whose frozen price is above what the account can spend is skipped without a lookup, so an account short on points finishes immediately instead of working through the whole shortlist. Both counts are reported on the task as point_shop_purchase.skipped.not_owned and point_shop_purchase.skipped.unaffordable.

Set category_strategy to one_each_first to prioritize one successful purchase from every matching reward category before buying another item from a category that is already covered. Failed ownership or eligibility checks move to another candidate in the missing category. A category is not guaranteed to complete when Steam rejects every matching candidate, the task reaches max_attempts, or the account runs out of spendable points.

When vary_by_account is also enabled, each account gets a stable variation of the category and item order while keeping the one-per-category priority.

Set max_purchases_per_category to stop one category from taking more than its share of the budget. For example, combine one_each_first with a per-category limit of 1 to buy at most one profile background, one avatar frame, and one item from every other matching category.

minimum_remaining_points is applied after the budget mode. For example, an account with 4,000 points, a 50% budget, and a 2,500 point reserve can spend at most 1,500 points. max_points is always a hard cap, including percentage and available-balance modes.

Set equip_after_purchase to put what was bought straight onto the profile. Four reward categories are profile slots: profile backgrounds, mini-profile backgrounds, avatar frames and animated avatars. A purchased seasonal badge is featured on the profile instead. Emoticons, stickers and chat effects are consumed per use, and startup movies are a Steam Deck setting, so none of those are ever equipped. A profile holds one item per slot, so when a run buys several for the same slot the most expensive one is equipped. Equipping happens after every purchase is recorded, and a failure to equip is reported in the task result without failing the task, because the points are already spent. The result gains an equipped array of {slot, community_item_id, equipped, error_message} (slot is a profile slot or favorite_badge), and the account's profile_items.equipped is refreshed by the next details refresh.

Profile #

set_profile writes the profile, typed in once or drawn per account from your profile library.

change_profile_privacy flips Steam visibility settings. Every field is optional and an omitted field is left unchanged, so one call can change a single setting across the fleet.

Send at least one. A config with none would read every account's settings and write them back unchanged, so it is refused with an error on config.profile.

equip_profile_items puts cosmetics an account already owns onto its profile.

There is no field for a specific item, and that is deliberate: every account owns a different set, so the item is resolved per account when the task runs. newest takes the most recently acquired, random picks one, and name keeps only items whose name contains your text, with the newest of those winning a tie.

A profile holds one item per slot. A slot the account owns nothing for is reported and skipped, never treated as a failure, and with skip_if_equipped on a repeat run only fills the gaps. One slot Steam refuses does not stop the others; the task only fails when every slot it tried was refused.

The result carries a slots array of {slot, outcome, community_item_id, name}, where outcome is equipped, already_equipped, no_match, owns_nothing, or failed. After anything is equipped the account's profile_items.equipped is re-read from Steam and updated, so it reflects the change without waiting for a details refresh.

set_profile_theme sets the colour theme on each Steam profile. This is the chip row on Steam's Profile settings (Default, Summer, Midnight, Steel, Cosmic, Dark mode), not a Points Shop item and not part of set_profile. Steam writes it through IPlayerService/SetProfileTheme, a different surface from the community profileSave that name, summary, country and custom URL use.

selected applies the same colour to every account. random picks one colour per account from themes when the task is created, so a retry reapplies the same choice. default is Steam's unstyled profile (an empty theme_id on the wire).

The result is {mode, theme, themes}, where theme is the colour that was written.

set_favorite_badge features one of the badges an account has earned on its profile.

As with equipping, there is no field for a specific badge: each account has earned a different set, so it is ranked per account at run time. recommended takes the years-of-service badge first, then the highest seasonal sale badge, then the owned-games badge, and features nothing if the account has none of those. highest_level ignores the type and takes the highest level, then the highest XP. random picks uniformly among the account's Steam-wide badges, so a fleet run does not clone one badge onto every profile.

Only Steam-wide badges are eligible. Per-game badges are addressed by a different identifier that SteamLabs does not write, so they are never featured.

The result is {strategy, outcome, badge_id, badge_name, level, reason}, where outcome is set, already_set, no_badges, or no_match, and reason says which rule picked the badge: years_of_service, seasonal_sale, owned_games, highest_level, or random. badge_name may be null when Steam's badge page could not be read; the ranking still works, though the seasonal-sale step is skipped, since that is the one step that needs names.

claim_community_badge is a different job from featuring a badge or redeeming a paid Points Shop sale badge. Steam awards Community Pillar (and later levels of the same community badge) when enough quests on /badges/2 are done. There is no one-click claim RPC. The worker reads Steam's official quest-progress list (and the badge page for the title and the "N of 28" counts) and runs the remaining quests that have a stable web endpoint and spend nothing: Discovery Queue, discussions search, wishlist, workshop rate or subscribe (then unsubscribe), view a broadcast, join the Steam Trading Cards group, post then delete a status, comment then delete on the account's own profile, activity-feed upvote, set a real name when it is empty, and feature a badge if none is featured. Viewing a guide only counts from the in-game overlay, so that quest is skipped.

It skips anything that costs wallet or points, needs another account, writes a public review, or is account-security / market work (trade, market, phone, Steam Guard, 2FA, craft cards, screenshots, videos, add a friend, play a game, chat emoticon, avatar upload, profile background). Limited accounts can finish fewer quests. Steam still awards the next badge level when the remaining count is high enough.

The result is {outcome, badge_id, badge_name, level_before, level_after, completed_before, completed_after, total, quests}, where outcome is completed, already_complete, or partial, and each quest is {id, outcome, detail?}. A repeat run is cheap: finished quests are reported as already_done and not retried.

Inventory and storage #

store_items deposits matching CS2 items into the account's storage units.

withdraw_items moves matching items back out of storage.

rename_storage_unit renames storage units across accounts.

distribute_items sends items to one destination, or spreads them with routing rules.

Each entry of rules is an object:

Market #

sell_items lists matching marketable items, priced live per item.

Rules the sell form enforces visually apply here too:

• buy_order pricing is only available on steam, and top_bid only on marketcsgo and dmarket. The wrong pairing fails on config.mode.
• skinland buys at its own quote, so it takes no mode. Sending one fails on config.mode. Leaving it off is how you sell there.
• A config with no item condition, no max_items and no confirm_sell_all would list every marketable item on every selected account. It is refused on config.confirm_sell_all until you set that flag to true.
• manual needs named catalog items, so config.item_ids must name at least one. An empty list is refused on config.item_ids.
• A mixed item_ids list needs manual_prices_cents with a cents value for every named item. One shared manual_price_cents is refused on config.manual_prices_cents.
• manual_convert is Steam-only. csfloat and marketcsgo quote in USD and have no per-account wallet to convert into, so pairing them fails on config.manual_convert.
• auto_reprice supports CSFloat, market.csgo and DMarket and requires mode: "undercut" plus a floor_percent. Each successful listing captures its own absolute USD floor. Listings whose venue reference price is missing are still created but are not enrolled.

Exact pricing across accounts

mode: "manual" lists at prices you type rather than prices derived from the order book. Name the items under item_ids. One item can use manual_price_cents. Several items need manual_prices_cents keyed by those same ids. Copies of one item across accounts share that item's price. Two things then decide how Steam spends the numbers:

manual_currency says what the number means. Steam wallets each have their own currency, so 707 is 7.07 zł on a PLN wallet and $7.07 on a USD one. Accounts whose live Steam wallet is not in manual_currency are skipped, and their items come back under the task's skipped list with reason wallet_currency_mismatch.

manual_convert: true trades exactness for coverage: nothing is skipped, and each account lists at that value converted into its own wallet currency using the item's own order book as the rate. Items whose rate cannot be derived are skipped with no_fx_reference.

curl -X POST "https://dashboard.steamlabs.dev/api/v1/tasks" \
  -H "Authorization: Bearer $STEAMLABS_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: $(uuidgen)" \
  -d '{
        "type": "sell_items",
        "config": {
          "marketplace": "steam",
          "mode": "manual",
          "manual_price_cents": 707,
          "manual_currency": "PLN",
          "manual_convert": false,
          "item_ids": ["<item-id>"]
        },
        "filters": { "market": "eligible", "inventory": "synced" }
      }'

$response = Http::withToken($apiKey)
    ->withHeaders(['Idempotency-Key' => (string) Str::uuid()])
    ->post('https://dashboard.steamlabs.dev/api/v1/tasks', [
        'type' => 'sell_items',
        'config' => [
            'marketplace' => 'steam',
            'mode' => 'manual',
            'manual_price_cents' => 707,
            'manual_currency' => 'PLN',
            'manual_convert' => false,
            'item_ids' => ['<item-id>'],
        ],
        'filters' => ['market' => 'eligible', 'inventory' => 'synced'],
    ]);

place_buy_order places the same buy order across accounts.

Only accounts that can actually place buy orders are eligible: market eligible, mobile authenticator, billing address on file, and enough wallet balance to fund price x quantity on top of their already-open orders (Steam caps open orders at ten times the balance). Everything else is reported as accounts_skipped, split by reason in accounts_skipped_reasons (insufficient_funds, cannot_place_buy_orders, task_in_flight). In outbid mode the price is resolved per wallet currency at creation time.

CS2 armory and drops #

buy_store_items buys from the in-game CS2 store with the account's wallet balance.

buy_armory_items spends armory credits, split by weight.

Each line is { "item": "…", "percentage": 25 }, where item is one of fever_case, arabesque_collection, spy_tech_collection, overpass_2024_collection, auto_racing_stickers, fruits_and_veggies_stickers, community_2025_stickers, missing_link_charms, missing_link_community_charms, dr_boom_charms, small_arms_charms, and percentage is 1 to 100.

activate_armory_passes activates bought-but-inactive passes.

claim_weekly_drops claims the account's two weekly CS2 drops.

Run fetch_weekly_drops first if you want to review the options before claiming.

trade_up_contract crafts 10 same-rarity skins into 1 of the next rarity.

Planning has side effects: a real run reserves the input items and writes ledger rows per account. Accounts with no viable contract under your guardrails are skipped. Set trade_up_dry_run to true first, which answers 200 with the digest and consumes nothing.

TF2 #

buy_tf2_store_items buys from the in-game TF2 store with the account's wallet balance.

use_tf2_items applies unused items already sitting in the backpack.

Delete many tasks #

Requires tasks.write.

curl -X DELETE "https://dashboard.steamlabs.dev/api/v1/tasks" \
  -H "Authorization: Bearer $STEAMLABS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"task_ids": ["019fb431-2c88-71ea-b0a3-8ce2f5d19b07"]}'

{ "deleted": 1, "skipped": 0 }

Unfinished tasks are flagged cancelled before the rows go, so the fleet drops the work instead of erroring on a missing row. Deleting a batch parent takes its children with it.

skipped counts ids that could not be deleted: children of a batch that has not finished (their results still feed the parent's counters), and ids that are not yours.

Clear finished tasks #

Requires tasks.write. No request body.

curl -X DELETE "https://dashboard.steamlabs.dev/api/v1/tasks/finished" \
  -H "Authorization: Bearer $STEAMLABS_API_KEY"

{ "deleted": 42 }

The one-click history cleanup, matching the Tasks page's "Clear finished" button. Every finished top-level task goes, and a deleted batch parent takes its children with it (deleted counts top-level rows only). Queued and running tasks are never touched: to remove live work, cancel it or name its ids in Delete many tasks.

One task #

Requires tasks.read.

curl "https://dashboard.steamlabs.dev/api/v1/tasks/019fb440-7a10-7c33-bd51-2f0c9e4471d2" \
  -H "Authorization: Bearer $STEAMLABS_API_KEY"

{
    "id": "019fb440-7a10-7c33-bd51-2f0c9e4471d2",
    "type": "claim_weekly_drops",
    "status": "failed",
    "is_batch_parent": false,
    "is_cancelling": false,
    "parent_id": "019fb431-2c88-71ea-b0a3-8ce2f5d19b07",
    "steam_account_id": "019fb42e-9a61-70d2-818a-f6a56593f3a5",
    "steam_account": {
        "id": "019fb42e-9a61-70d2-818a-f6a56593f3a5",
        "username": "farm_017",
        "persona_name": "Ada",
        "steam64_id": "76561198000000017"
    },
    "children": { "total": 0, "completed": 0, "failed": 0, "cancelled": 0 },
    "error": "The Game Coordinator session timed out.",
    "worker_id": "worker-eu-14",
    "bytes_sent": 1204482,
    "bytes_received": 12044820,
    "cancel_requested_at": null,
    "dispatch_after": null,
    "started_at": "2026-07-30T14:02:44+00:00",
    "finished_at": "2026-07-30T14:04:02+00:00",
    "created_at": "2026-07-30T14:02:11+00:00",
    "updated_at": "2026-07-30T14:04:02+00:00",
    "task_data": { "strategy": "highest_price", "ignore_graffitis": true },
    "point_shop_purchase": null,
    "logs": [
        { "ts": 1785420164, "level": "info", "msg": "Signing in to Steam" },
        { "ts": 1785420191, "level": "info", "msg": "Launching CS2" },
        { "ts": 1785420242, "level": "error", "msg": "GC session timed out after 45s" }
    ],
    "worker_public_ip": "185.22.10.4",
    "proxy": { "id": "019fb42f-1188-70aa-8f2c-3b7de51a9c60", "host": "res-eu-01.example.net", "port": 8080 }
}

Four fields appear only here: task_data (the payload the worker was handed, already resolved per account), point_shop_purchase (the purchase summary and 20 most recent attempts, or null), logs (the last 200 lines the worker sent back), and proxy (which proxy it went through).

For buy_point_shop_items, point_shop_purchase.summary contains purchased, attempted, points_spent, and accounts, and point_shop_purchase.skipped contains unaffordable and not_owned for the candidates that never became attempts. Each recent attempt includes its definition id, title, approved and live costs, balances, outcome, Steam eresult, grant ids, and timestamps. A batch parent rolls up every child that shares its purchase plan.

A task id that belongs to someone else returns 404, the same as an id that does not exist. We do not distinguish, because confirming an id exists elsewhere leaks that it exists.

A batch's children #

Requires tasks.read.

curl "https://dashboard.steamlabs.dev/api/v1/tasks/019fb431-2c88-71ea-b0a3-8ce2f5d19b07/children?status=failed" \
  -H "Authorization: Bearer $STEAMLABS_API_KEY"

Rows are the same shape the list endpoint returns. GET /api/v1/tasks?parent={id} gives you the identical set with the full filter vocabulary, if you need type or a date range as well.

Call this with status=failed to see which accounts failed and why. To act on them, use retry-failed on the parent rather than looping the children.

Retry a failed task #

Requires tasks.write. Requires an Idempotency-Key header.

No body. The task's own resolved task_data becomes the config, so a random persona name re-rolls and an already-planned trade-up re-dispatches verbatim.

curl -X POST "https://dashboard.steamlabs.dev/api/v1/tasks/019fb440-7a10-7c33-bd51-2f0c9e4471d2/retry" \
  -H "Authorization: Bearer $STEAMLABS_API_KEY" \
  -H "Idempotency-Key: $(uuidgen)"

Answers 201 with the new task, exactly as POST /api/v1/tasks does for a single account.

The task must be Failed, bound to a Steam account, and not a batch parent. Anything else gets 422 task_not_retryable. A failed child of a finished batch qualifies; the parent itself does not.

Points Shop purchases have a stricter rule. A task with a pending, purchased, or unknown attempt returns 409 point_shop_purchase_retry_unsafe. Create a new task after checking the account instead. This prevents a retry from buying the same reward twice after Steam completed an earlier request.

Retry a batch's failures #

Requires tasks.write. Requires an Idempotency-Key header.

No body. The failed set travels as a filter, never as ids, so a 100,000-child batch does not have to materialize its failures before it can retry them.

curl -X POST "https://dashboard.steamlabs.dev/api/v1/tasks/019fb431-2c88-71ea-b0a3-8ce2f5d19b07/retry-failed" \
  -H "Authorization: Bearer $STEAMLABS_API_KEY" \
  -H "Idempotency-Key: $(uuidgen)"

{
    "task_id": "019fb44a-51e7-7ab8-9f30-6ca7ce31f008",
    "accounts_affected": 12,
    "accounts_skipped": 0
}

Always 202 with a new batch parent, because you cannot know how many children failed. The original parent is left alone.

The parent must be finished, have at least one failed child, and still carry the selection it was created with. Otherwise you get 422 task_not_retryable.

Points Shop purchase batches always return 409 point_shop_purchase_retry_unsafe here. Create a new task for the accounts you want to run again, so the catalogue and prices are frozen into a new plan.

Cancel one task #

Requires tasks.write. No body, and no Idempotency-Key: cancelling twice changes nothing.

Cancelling is a request, not a transition, which is why this answers 200 with the record rather than 204:

• a Waiting or Queued task flips to Cancelled straight away;
• a Running task only gets cancel_requested_at stamped, and the worker decides the final status. It may still finish and report Completed.

Read status and cancel_requested_at off the response to tell which of the two happened. While the request is outstanding, is_cancelling is true.

curl -X POST "https://dashboard.steamlabs.dev/api/v1/tasks/019fb431-2c88-71ea-b0a3-8ce2f5d19b07/cancel" \
  -H "Authorization: Bearer $STEAMLABS_API_KEY"

Cancelling a batch parent cancels its children. Only top-level unfinished tasks with no cancel already pending can be cancelled; anything else gets 422 task_not_cancellable.

Delete one task #

Requires tasks.write.

An unfinished task is flagged cancelled before the row goes, so the fleet drops the work. A batch parent takes its children with it.

A child of an unfinished batch cannot be deleted on its own: its result feeds the parent's counters, and removing the row would strand the parent running forever. That is 422 task_not_deletable. Cancel or delete the parent instead.

Errors #

On top of the universal codes, this group returns:

Everything else (validation_failed, not_found, missing_scope, rate_limit_exceeded, the idempotency conflicts) behaves as described on Errors.

Validation failures on a config report per field under config.*, so a bad sell mode reads as config.mode rather than a bespoke envelope:

{
    "message": "The given data was invalid.",
    "code": "validation_failed",
    "errors": {
        "config.mode": ["The buy_order pricing mode is only available on the steam marketplace."],
        "config.confirm_sell_all": ["This config has no item condition and no cap, so it would list every marketable item on every selected account. Set confirm_sell_all to true to accept that."]
    }
}