> For the complete documentation index, see [llms.txt](https://help.refractbot.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.refractbot.com/modules/walmart/walmart-release-guide.md).

# Walmart Release Guide

Walmart releases their card products on Wednesdays, at 9:00 PM EST usually. This guide covers how to set up for the drop, what to expect from the queue, and how to handle every status and error you are likely to see. It answers almost everything related to the drop, so read it before opening a ticket.

{% hint style="info" %}
For building the setup itself (accounts, IMAP, profiles, proxies, task groups), see the setup guide:
{% endhint %}

{% content-ref url="/pages/cxfqBzylNU6MtBLZoAhm" %}
[Walmart Setup Guide](/modules/walmart/walmart-setup-guide.md)
{% endcontent-ref %}

## The drop night checklist

If you read nothing else on this page, follow this. Every step links to the section that explains it.

{% stepper %}
{% step %}

#### Any time before the drop: start your tasks

Start tasks with no SKU whenever you want, even hours early. They sit on **Waiting for Product** and use no data. Earlier is better. See [When to start tasks](#when-to-start-tasks).
{% endstep %}

{% step %}

#### At least 1 hour before: everything logged in

All tasks must be logged in at least 1 hour before the drop, running with **Use Saved Session ON**. Logging in during the last hour causes problems. See [Use Saved Session](#use-saved-session).
{% endstep %}

{% step %}

#### When the SKU is out: paste it in

Paste the SKU into your task group(s). No OID. No Skip Monitoring. Tasks start moving on their own without a restart.
{% endstep %}

{% step %}

#### During the drop: do not stop or restart tasks

Never stop or restart tasks that are in queue. Placeholder timers like `29:59` are normal. Walmart releases in waves. Changing delays is fine at any time and never restarts tasks. See [Queue Behavior](#queue-behavior).
{% endstep %}

{% step %}

#### Seeing an error?

Find it in [Common Errors & Fixes](#common-errors-and-fixes) before opening a ticket. Almost every drop-night error is explained there.
{% endstep %}
{% endstepper %}

## When to start tasks

You can start your Walmart tasks whenever you want, even hours early, with no monitor input set. They will settle on **Waiting for Product** and sit there. No proxy data is used on this step when no SKU and OID are set.

It is never too soon to start them. Starting earlier is totally fine and encouraged, in case of site security changes or the site crashing.

{% hint style="info" %}
**"Is a bot update coming before the drop?"** We never know in advance. Walmart is always changing something on Wednesdays, so updates get built and pushed as needed. If an update is pushed and it helps or is needed, everyone will be told in announcements. Do not hold off on starting tasks because an update might come; it is always safe to start.
{% endhint %}

{% hint style="danger" %}
**All tasks should be logged in at least 1 hour before the drop.** If you try to log in within the last hour before the drop, you are very likely to have issues. Log in early, then let tasks sit.
{% endhint %}

When the SKU is out (from your cook group, the bot monitor, or social media), paste it into your task group(s) and tasks start moving toward queue. OID is NOT needed.

{% hint style="info" %}
**The fastest way to get the SKU in:** click the monitor icon in the top right of the bot to open the in-bot monitor feed, filter it to Walmart, then right-click the product and choose **Set product to group**. It goes straight into your group's monitor input. See [In-Bot Monitor & Checkout Feed](/general-setup/task-creation/monitor-setup-and-multi-input.md#in-bot-monitor-and-checkout-feed).
{% endhint %}

**Live task editing:**

* Starting tasks with no SKU and entering the SKU near drop time works fine and does not restart your tasks.
* The only time tasks need to restart for a SKU change is if they are already in queue. You cannot change SKUs on tasks that are already in queue.

## Task Creation & Multi-SKU

{% hint style="warning" %}
**Multi-SKU works for Walmart queue drops as of July 29, 2026, but it is not multi-queue.** All tasks in the group join the first queue that picks up.
{% endhint %}

* Multi-SKU works like it does on every other site: put multiple SKUs in the group's monitor input, and tasks go for whichever product the monitor picks up first.
* Once a queue picks up, every task in the group commits to that queue. You cannot change SKUs on tasks that are already in queue.
* To ride separate queues for multiple products at the same time, create separate task groups for each SKU.
* You can reuse the same accounts and proxies across groups for different products.

{% hint style="info" %}
**How many SKUs per account?** We wouldn't recommend running the same accounts on more than 2-3 SKUs max. It's your bot and your accounts, so run it how you want. This is just our recommendation not to push past that.
{% endhint %}

## Setup & Drop Strategy

{% hint style="warning" %}
**Walmart+ should not be required for most drops,** unless we say otherwise. If it does turn out to be required and you don't have it, you may see "unknown response \[400]." Note that free trials and $1 trials do not work.
{% endhint %}

You do not need to pull fresh saved sessions every week if your previous sessions are still working. There's no data showing old vs. new sessions perform differently, so redoing them weekly shouldn't be necessary.

{% stepper %}
{% step %}

### Test your saved sessions early

Run a couple of tasks with Use Saved Session ON ahead of time.
{% endstep %}

{% step %}

### Check that they reach "Waiting for Product"

If your saved-session task reaches "Waiting for Product," you're good to go. Turn Use Saved Session ON for all tasks.
{% endstep %}

{% step %}

### Only regenerate if needed

Generate a new session only if your saved-session task fails to return to "Waiting for Product." To regenerate, run your tasks with Use Saved Session OFF and let them fully log in.
{% endstep %}
{% endstepper %}

## Use Saved Session

This feature lets the bot reuse a previously saved login session instead of logging in again. Walmart has strict security at login right before and during drops, so skipping login makes tasks run faster and more reliably.

{% stepper %}
{% step %}

### Confirm tasks are logged in

Check the Accounts tab to verify your tasks are logged in.
{% endstep %}

{% step %}

### Turn on Use Saved Session

Enable Use Saved Session, then start your tasks at least 1 hour before the drop (earlier is fine and encouraged, see [When to start tasks](#when-to-start-tasks)). This gives the bot plenty of time to refresh the session and avoid login errors.
{% endstep %}
{% endstepper %}

{% hint style="warning" %}
**Don't wait until the last minute to start tasks.** Logging in within the last hour before the drop very likely causes issues, and the early start is what lets sessions refresh cleanly and avoid really high PX before the drop.
{% endhint %}

{% hint style="info" %}
**"Setting cookies" every hour is normal.** While tasks wait, they refresh the session roughly once an hour, and you'll see a brief "setting cookies" status. This uses a small amount of proxy data, which is expected.
{% endhint %}

{% hint style="danger" %}
**Always enable Use Saved Session.** If you don't, the bot will try to log in from scratch, which may trigger PX blocks and leave you unable to log in.
{% endhint %}

{% hint style="warning" %}
If you hit PX blocks, let it retry. If it keeps looping on "setting cookies," toggle Saved Session OFF, restart tasks, and retry.
{% endhint %}

**Note on proxies:**

* If you're already logged in, the task begins using the proxy you logged in with.
* If that proxy gets blocked, the task automatically rotates to a new proxy in whichever proxy list is assigned to that task.

## Proxy hot swapping

You can change proxies while tasks are running. There is no need to stop anything to assign a new list.

However, the swap is not instant. Tasks continue using the proxy they were already on until they hit a block or error. Only then do they rotate onto the new list. It is not possible to change proxies immediately without restarting tasks, so if you need the new list applied right away, restart your tasks (but never restart tasks that are sitting in queue).

This applies to both monitor and task proxies. It is intended behavior. It has always worked this way and always will.

## Skip Monitoring & OID

{% hint style="danger" %}
**Never use Skip Monitoring for queue drops, ever.** Most Walmart Wednesday drops are queue drops, so Skip Monitoring should stay OFF. Enabling it on a queue drop will hurt you, not help.
{% endhint %}

{% hint style="info" %}
**OID (Offer ID) is optional and not needed** for queue drops. You don't have to find or enter it. Leave it blank unless we explicitly tell you otherwise in #dev-announcements.
{% endhint %}

Skip Monitoring exists only for non-queue drops, where speed is critical and you want to spam Add to Cart the moment the product goes live. It is not a queue-drop tool.

<details>

<summary>Using Skip Monitoring on a non-queue drop (advanced)</summary>

If, and only if, you're running a non-queue drop and choose to use Skip Monitoring:

* Add the PID (SKU) to the monitor section in advance of the drop.
* Add the OID (Offer ID) as well. It acts as a fallback if your monitor is blocked.
* At drop time, enable Skip Monitoring to force Add to Cart attempts using the PID and OID.

Both PID and OID are required here. Skip Monitoring will not function if only one is provided. Again, this does not apply to Walmart Wednesday queue drops.

</details>

## Monitors at drop time

The monitor delay controls how often the bot checks for the product. The default is `4500`.

Tasks in queue are locked to the SKU they queued for. You cannot live-swap to a new SKU once tasks are already in queue: a task only picks up the new SKU's queue if you restart it, which gives up its place in the current queue.

{% hint style="warning" %}
**Monitor IP bans near drop time are normal and expected.** Walmart bans tons of IPs near drop time, so a lot of your monitors will show **Access Denied** (the same block as Access Denied on tasks) and keep rotating to try to find a good proxy. Refract runs multiple monitor threads in the background for you, so most likely it is just a handful of blocked proxies showing that status while the rest monitor fine.
{% endhint %}

{% hint style="success" %}
**Even if all your monitors are struggling, you are covered.** A global monitor from Refract's servers pings all task groups at drop time, so you should pick up the drop fine either way.
{% endhint %}

## Queue Behavior

Queue behavior during Walmart drops can be unpredictable. A few important things to understand:

* **Placeholder timers:** Queue times like `29:59` or `9:59` can be placeholders or just the back of the line. It's impossible to know for sure. Just let tasks run.
* **There can be several placeholder times, and they change:** each drop tends to have a new one where huge chunks of tasks all show the same time. A wall of identical timers is the signature of a placeholder, not a sign your setup is broken.
* **Stuck in queue? Not broken:** Tasks stuck at placeholder times aren't broken. Walmart just hasn't issued a new queue time yet.
* **Waves release:** Walmart releases users in waves. Sitting in queue doesn't mean you won't get through. Do not end tasks early.
* **No monitor updates? Normal:** It's completely normal for the monitor section to look inactive while your tasks are in queue.
* **Try restarting some tasks:** Some users have forced a queue time by restarting tasks stuck at placeholder times. If you can afford to lose the task, try restarting a few.

**What specific queue statuses mean:**

* **Queue stuck \~30m:** Usually means you got in late and are effectively waiting at the back of the line.
* **Queue looping \~14m59s:** Can happen when Walmart is letting very few people through at a time. There's no known fix other than letting tasks run. It may be due to overlapping or flagged proxies or flagged accounts, but only Walmart knows for sure.
* **Negative queue times, like `Queue (ETA: -1409m)`:** your computer's clock is wrong. Resync your device time and the timers will read correctly. You can resync mid-drop without hurting your tasks.
  * **Windows:** Settings > **Time & Language** > **Date & time**, turn **Set time automatically** and **Set time zone automatically** on, then click **Sync now**.
  * **Mac:** Apple menu > **System Settings** > **General** > **Date & Time**, turn on **Set time and date automatically** and **Set time zone automatically using your current location**.
  * Full walkthroughs for both are also in the [IMAP guide's device time fix](/misc./imap.md).

### Stuck in queue the entire drop? The levers that help

{% hint style="warning" %}
**We cannot tell you which proxy provider or which type of resi is working best. We genuinely do not know.** The bot has no visibility into which providers people are using or what kind of resis they run. To the bot and to our team, a proxy is a proxy. Which providers are performing week to week is exactly what cook groups track.
{% endhint %}

If you keep getting stuck or looping in queue, these are the changes users report actually helping:

* **Try different proxy providers.** If one pool is oversaturated or flagged, no setting will fix it. Rotating providers is the fix, and it takes trial and error.
* **Try a server.** Users stuck in queue on home networks have reported a server helping.
* **Splitting task groups is no longer needed.** This used to be advice here: running 10 groups of 100 instead of 1 group of 1,000 meant more monitors. On the new engine version, all task groups share monitor pings instantly, so more groups no longer helps. Groups are purely for organization now; run whatever layout is easiest to manage.

**Proxy session time:** set your proxy sessions to be as long as your provider allows. And if a session rotates mid-queue anyway, that is fine. It does not break anything.

### When the queue itself crashes

Walmart's queue has been crashing at drop time. When that happens, the pattern looks like this:

1. Your task tries to enter the queue and gets a **500**. That is Walmart's queue crashing on their end.
2. The task retries and gets a **429 (rate limited)**, because you already tried.

Unfortunately this is out of everyone's control. There is no bot-side fix for Walmart's queue falling over. All anyone can do is get into queue faster, before it crashes.

## Queue Proxies

{% hint style="info" %}
**Bottom line:** Optional, not required. If you do run them, use ISP proxies only. Don't use residential (resi) proxies as your queue list, as it defeats the purpose.
{% endhint %}

**How it works:** Queue proxies are only used to enter and wait in queue, nowhere else. The switch happens as soon as you pass the queue: before add to cart, the bot moves to your task proxy and uses it for the rest of checkout. If you don't set a queue proxy list at all, your task proxy is used to enter the queue by default.

{% hint style="info" %}
Some weeks queue proxies pass better, some weeks they don't, so diversify your setup. The goal is to optimize to get into queue as fast as possible.
{% endhint %}

## Drop-night quick answers

* **In-bot notices:** Known site issues and outages (like the queue 500s) show as a notice banner at the top of your task groups, on top of Discord announcements and the dashboard Announcements tab. If a banner is up, the situation is known; you do not need to open a ticket to report it.
* **Bot updates:** No update is needed for a drop unless we explicitly say it is mandatory. If we say nothing (or say it's not needed), the update is not required.
* **Task limit:** The Walmart task limit is 2,000 per instance.
* **Instances:** The instance cap is 2 total per account. If you're at 1 or 2 instances, you cannot get a third or go higher. See [Instances](/online-dashboard/subscription/instances.md).
* **Multi-SKU:** Works for queue drops as of July 29, 2026, but it is not multi-queue: all tasks in the group join the first queue that picks up. Separate task groups are still the way to ride multiple queues at once. See [Task Creation & Multi-SKU](#task-creation-and-multi-sku).

## Common Errors & Fixes

Find your error below. Every error is listed in the "On this page" outline on the right, so you can jump straight to the one you're seeing. These are the drop-night ones; errors that can hit at any time are in the [setup guide](/modules/walmart/walmart-setup-guide.md#errors).

### Access Denied (456)

**What it means:** The task received an actual 456 response from Walmart. It is Walmart's security blocking the request (previously known as "Generating Session" loops).

**The current situation:** 456 has been incredibly high on recent drops. Tasks pass queue, then hit non-stop 456 trying to cart. This is hitting everyone, across all bots, and it is not a setup or bot flow issue. The dev team has tested dozens of proxy providers, and all of them are blocked, including when carting manually through them, so expect 456 to stay heavy even after switching proxy types or providers. The working theory is that proxy pools are oversaturated: so many people across the Pokemon space are running Walmart that the providers' IPs are burned. As always, we continue to analyze every drop in case there is anything we can improve on the bot side.

**What causes it:**

* **Proxy (most common cause):**
  * The bot auto-rotates proxies after a 456 block.
  * Proxy location matters. Proxies just outside the U.S. (for example Mexico or Canada) have triggered 456 blocks, while U.S.-based proxies passed.
  * Low-trust and oversaturated proxy pools get blocked more often.
* **Accounts:** Flagged or low-trust accounts may contribute. Re-logging into your account can sometimes refresh the session; otherwise, let the account rest.

**How to fix it:**

There is no real fix right now. The only advice:

* Diversify your proxies across multiple providers, and let the task auto-rotate and retry. The bot cycles through your list until it finds a proxy that can cart.
* Use U.S.-based residential proxies with a good trust score. Avoid international or mixed-location proxy pools.
* Try re-logging into the Walmart account to refresh session data.
* If you're already through queue and running on a local machine (not a server), live-edit the stuck tasks to force the add to cart on your local IP: right-click the task, click **Edit**, remove the proxy, and save.

<details>

<summary>456 at "Proceeding to Checkout" (and the SMS question)</summary>

When the bot shows 456 at Proceeding to Checkout, it received an actual 456 response from Walmart during checkout. The exact cause of that 456 cannot be determined from the response Walmart gives alone. It can result from account or proxy issues, the ones that show up as "Something went wrong" during manual checkouts and carts.

The SMS block is separate from this and has its own status. When Walmart has SMS enforcement switched on, blocked tasks show `SMS Required` rather than a generic 456. See [SMS Required](/modules/walmart/walmart-setup-guide.md#sms-required) in the setup guide. A 456 does not mean SMS is the problem.

</details>

### Unknown Response \[500] on Queue

A 500 means a site error on Walmart's end, usually the queue crashing at drop time. There's nothing anyone can do if their site crashes. Let tasks keep running. See [When the queue itself crashes](#when-the-queue-itself-crashes).

### Rate Limited on Queue

Walmart's site is crashing or erroring. The task retries when the site errors out and gets rate limited (429) for retrying. This is the same situation as the 500. It's on Walmart's side, not yours. See [When the queue itself crashes](#when-the-queue-itself-crashes).

### Bot not submitting login codes

Before assuming the bot or IMAP is broken, open the email inbox and check whether the codes are actually arriving. Sometimes on drop day, Walmart stops sending codes entirely. If there is no code in the inbox, Walmart never sent one, and there is nothing bot-side to fix. This is one more reason to have all tasks logged in at least 1 hour before the drop.

### Out of Stock, Retrying

The product is out of stock and the bot is retrying. No action needed. Let tasks continue.

### Errors that are not drop specific

These can hit at any time, not just on drop night, so they live in the setup guide:

* [Invalid Card Details / Max Card Attempts](/modules/walmart/walmart-setup-guide.md#invalid-card-details-max-card-attempts)
* [Payment Failure](/modules/walmart/walmart-setup-guide.md#payment-failure)
* [Invalid Address Details](/modules/walmart/walmart-setup-guide.md#invalid-address-details)
* [SMS Required](/modules/walmart/walmart-setup-guide.md#sms-required), the SMS verification block at checkout
* [Unknown Response \[400\]](/modules/walmart/walmart-setup-guide.md#unknown-response-400), Walmart+ required
* [Walmart+ Not Allowed](/modules/walmart/walmart-setup-guide.md#walmart-not-allowed)
* [Setting Cookies / Solving PX Captcha](/modules/walmart/walmart-setup-guide.md#setting-cookies-solving-px-captcha)
* [Reset Locked Walmart Account](/modules/walmart/walmart-setup-guide.md#reset-locked-walmart-account)
* [Proxy Error](/modules/walmart/walmart-setup-guide.md#proxy-error), [Connection Error](/modules/walmart/walmart-setup-guide.md#connection-error) and [Request Timed Out](/modules/walmart/walmart-setup-guide.md#request-timed-out)

## Order cancellations after checkout

Walmart cancelling orders after a successful checkout happens a lot, to everyone. The email gives different reasons: sometimes it blames the delivery address ("we can't deliver to the address you provided"), sometimes it says the order "was flagged by our policy review team" and to review your payment method. Do not read into the stated reason; it is the same cancel either way, and the payment hold is released. These cancels are Walmart-side order checks, not something Refract causes or can prevent, and they are outside what support can help with.

What we can tell you:

* **Cancels are dynamic, with no real rhyme or reason.** Some weeks everyone's stick rate is high; other weeks it is lower, with nothing changed on your end. Some nights cancels are very heavy for everyone.
* **Accounts flip week to week.** The same account can stick an order one week and get cancelled the next.
* **New accounts seem to stick less.** But even that varies user to user.

The play is to just keep running it. For current strategies on making orders stick, your cook group is the place.

## Troubleshooting any other error

{% hint style="info" %}
**This applies to all sites.** For any generic unknown error, task crash, or unknown response that isn't listed above, work through these steps before opening a ticket.
{% endhint %}

{% stepper %}
{% step %}

### Check your proxies

Make sure they have data and ping properly. This is the cause of 99% of "unknown errors," since different proxy providers sometimes return unique errors we don't handle.
{% endstep %}

{% step %}

### Check your profiles

Make sure no info is missing or incorrect, especially if you imported from somewhere else like AYCD. This is the cause of 99% of "unknown response" or task-crashed errors.
{% endstep %}

{% step %}

### Still failing? Open a ticket

If your profiles and proxies are good and you're still erroring, open a ticket. Unknown means unknown, so we'll have to check the logs.
{% endstep %}
{% endstepper %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://help.refractbot.com/modules/walmart/walmart-release-guide.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.