> 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/target/target-release-guide.md). # Target Release Guide ## Target Release Guide This guide covers how to run Target releases with Refract: how Shape and cookies work, how to set up, which settings to use, and the things you cannot change no matter what. Read it fully before your first drop. {% hint style="danger" %} **Read the setup guide before running Target.** If you do not at least make an attempt to read it, we will not be able to help you. {% endhint %} {% content-ref url="/pages/ZIjKBqUxKICZUBQEU2Ez" %} [Target Setup Guide](/modules/target/target-setup-guide.md) {% endcontent-ref %} ### Run 30-50 tasks on Windows, 200+ on a Mac Target has become a submit order lottery. Carting is not the hard part anymore: plenty of users cart around 90% of their tasks on a drop, especially on macOS. Checking out is. With the DCO (High Demand) rate limits, you have to cart a ton of tasks and spam submit order to push an order through. It is what every bot does, and only about 1% of carts turn into an order. That is why 10 tasks does not cut it anymore, and why 5-account setups do not work. The median running task count is 12, and most setups are not competitive with how Target works now. The people you see hitting double digits in cook groups are probably running hundreds if not thousands of tasks. The in-bot harvester has made big strides, and people are now running 200+ tasks without issues scaling, especially on macOS, local or on Mac servers. Local Windows gets flagged much faster, so run 30-50 tasks there. Windows servers are still really bad for Target: heavily flagged, Windows VMs worst of all, so do not scale onto one. Scale your harvesters with your tasks so every task keeps about 3 cookies banked. See [How many tasks to run](/modules/target/target-setup-guide.md#how-many-tasks-to-run). ### Blocks are normal {% hint style="info" %} **Blocks are normal, on every site, and Shape on a drop has an extremely low pass rate for everyone.** That is just the nature of the site. Experienced botters and new botters have very different ideas of what a "normal" amount of blocks looks like. {% endhint %} Experienced users will tell you they can get 80% blocks on a restock and be completely fine with it, because they know they will hit eventually. Some newer users think you are supposed to see all green all the time. That is not how it works. Unless you are getting blocked close to 100% of the time and nothing is moving at all, just have patience. When you check the stats of someone who is sure their setup is bad, the stats almost always look the same as everyone else's. The perception of what is "normal" is the thing that is off. Let the site security come down. Let your proxies and device cool down. Have patience. ### Shape, explained This is the most important section. Read it slowly. Everything we know about Shape lives in these guides. Opening a ticket will not get you more than what is written here, because we have nothing more. #### What Shape and Target cookies are Some requests to Target (add to cart and login) are protected by Shape, which is Target's antibot system. To pass that protection, the request has to present a valid cookie. Think of the cookie as a test that has to score 90% or higher to pass. * The in-bot harvester generates these cookies and saves them for each task to use. The harvester never sends the actual add-to-cart or login request itself. It intercepts that request and saves the cookie for later. * Each protected request consumes one cookie. Every add-to-cart attempt makes your cookie count go down. #### Shape is a score, not a single setting This is the part people miss. Shape does not pass or fail you on one thing. It scores the whole picture and rejects cookies based on several factors at once: * Proxy trust score * Device trust score * Browser * How many cookies you are generating * The product's current security level Each product has its own security level based on how much traffic it is getting. The more a product gets spammed, the higher its security climbs. Later in the day, after many small restocks where people have hammered a product, security will be higher for everyone. {% hint style="warning" %} **Because Shape is a combined score, there is no single fix and no one-size-fits-all approach.** A proxy swap alone will not save a tired device, and a fresh device will not save bad proxies. What fixed someone else's blocks may do nothing for yours. Treat your proxies, device, browser, and cookie count as one setup that has to be healthy together. {% endhint %} #### Why your cookies get depleted * Since each add-to-cart attempt uses a cookie, each task uses at least 1 cookie when a product restocks. * If an attempt gets blocked, it shows "Shape Block," then tries again and consumes another cookie. * In practice: if you have 20 tasks and 40 cookies, a restock uses at least 20 cookies. If every task gets blocked on the first attempt, it tries again and uses another 20, leaving you at 0. So bank about 3 cookies per running task. That is a per-task number: your bank grows with your task count, about 150 cookies for 50 tasks, about 600 for 200. What backfires is piling up far more than 3 per task, which raises your own risk of getting flagged and Shape blocked. {% hint style="info" %} **Bad cookies do not cart.** If you are not carting with about 3 cookies per task, generating more bad cookies will not fix it: improve the setup (device, browser, proxies) instead. This is about cookies only. You still need a lot of tasks. On your harvesters, residential proxies have been passing Shape far better than ISPs. {% endhint %} #### How many tasks should you run? **Windows: 30-50. Mac: 200+.** 10 tasks does not cut it anymore on high-demand drops: only about 1% of carts turn into an order. People are now running 200+ tasks on Macs, local or on Mac servers, without issues scaling. Local Windows gets flagged much faster, so stay in the 30-50 range there. Windows servers are still really bad for Target. Every task needs about 3 cookies banked behind it, so scale your harvesters with your tasks: 50 tasks need roughly 150 cookies, 200 tasks around 600. Tasks your harvesters cannot feed sit on **Waiting for Cookies** instead of carting. {% hint style="info" %} **These numbers move.** Target's security level changes, and so does the count that makes sense. Check Discord announcements around a drop rather than treating any number here as permanent. {% endhint %} #### How many Shape browsers do you need? People often ask for a browser-to-task ratio, or exactly how many browsers to run. There is no simple answer. It takes as many browsers as it takes to generate the cookies you need. The target is the same as always: about 3 cookies per running task. Scale your browser count up or down to hit that number, and find the sweet spot for your machine. As a rough starting point, for around 90-120 cookies you will probably need about 6 browsers. How fast each browser generates depends on your machine, your proxies, and the product's current security level, so treat that as a guide, not a fixed rule. Those browsers can all use the same path. Point every harvester at the same Chrome, Brave, or Edge install; the bot handles a separate profile and cache for each one automatically, with no extra setup on your side. Safari and Firefox are not supported. #### How to pass Shape blocks {% stepper %} {% step %} #### Shape blocked on login? Turn on Login with OTP On login specifically, turn on **Login with OTP (May pass login antibot better)** and pair it with IMAP. It has lower security than other login methods. If login is still blocked, the same principles apply as for add to cart: take login really slowly, do not use a Windows server, use in-bot harvesters, try different browser types on them, and harvest on residential proxies. See [Shape blocked on login?](/modules/target/target-setup-guide.md#shape-blocked-on-login) {% endstep %} {% step %} #### Use the right device Device type matters a lot for your Shape score, and it sets how far you can scale. Best to worst for Target: 1. **Mac mini, local or in a datacenter** (best for Shape, 200+ tasks) 2. **Local Windows** (30-50 tasks) 3. **Windows server** (avoid, heavily flagged) Macs share a common hardware fingerprint, so one Mac looks much like every other Mac to Shape, and that is what lets a Mac setup scale several times further before it stands out. Windows gets flagged considerably faster as a whole, and a Windows VM is the worst case of all because its hardware is faked and Shape detects that very obviously. A Mac mini server is not a separate category: it is a Mac mini hosted in a datacenter, with the same hardware, and it scales the same way. The only difference is that it has no home IP, so it always needs residential proxies. See [How many tasks to run](/modules/target/target-setup-guide.md#how-many-tasks-to-run). {% endstep %} {% step %} #### Let your setup rest instead of buying more Do not run out and buy 300 new proxies just because you stopped hitting later in the day after a bunch of tiny restocks. More than likely your device and proxies just need a rest, and the product's security level will come down over time as the restocks slow down. {% endstep %} {% endstepper %} {% hint style="warning" %} **For Target Shape, a Mac mini is best, local or in a datacenter, then local Windows.** Do not use a Windows server for Target if you can avoid it. It is much harder on Shape than the other two, and a Windows VM is the worst of the lot because its faked hardware is easy to detect. If you are buying hardware to scale on, buy macOS: it is the difference between 30-50 tasks and 200+. {% endhint %} #### Recommended setup Run at a competitive size from the start. Full details are in the setup guide: * **Windows: 30-50 tasks**, on unique Target accounts, one task per account per product. * **Mac: 200+ tasks**, on unique Target accounts, one task per account per product. Local or a Mac mini server. * Running multi-SKU * Running on a local machine, a Mac if you have one. Windows servers are not worth running. * [In-bot cookie harvesters](/modules/target/in-bot-shape-generation.md), not the browser extension. Mix Chromium browsers (Chrome and Brave). Safari and Firefox are not supported. You can reuse the same browser path on as many harvesters as you want; the bot handles profiles and cache automatically. Scale the harvester count so you hold about 3 cookies per running task. * Residential proxies on tasks and especially on harvesters. ISPs on the monitor. * Experimenting with lower monitor and task delays to find what works for your machine {% hint style="info" %} **Keep the cookie bank matched to your tasks.** About 3 per running task: fewer and tasks sit on Waiting for Cookies, far more per task and you raise your own flag risk. Remember the factors: proxies, device, browser, and how many cookies are being generated. {% endhint %} #### Don't get discouraged Shape blocks happen to everyone, and they are far more common after the first wave because everyone is spamming at once. Target sees traffic jump 100x or more right after a drop, so they crank security up immediately. On a drop, Shape's pass rate is extremely low across the board; that is the nature of the site. Seeing Shape block does not mean your setup is broken. #### Where the step-by-step setup lives Cookie generation runs in the bot. The in-bot harvester covers both login and add-to-cart cookies, and the guide below walks through setting it up. {% hint style="warning" %} **The browser extension is deprecated.** It still connects to the bot, but it is no longer updated, we do not recommend it, and we do not provide guidance for it. Use in-bot harvesters: they are far ahead of the extension on Target. {% endhint %} On proxies: residential on tasks, and especially on harvesters. Resis use data, but they have been passing Shape much better. Keep ISPs on the monitor. {% content-ref url="" %} {% endcontent-ref %} ### Multi-SKU / Multi-Input You can run the same accounts more than once for Target. Multi-SKU is still preferred. Keep the cookie cost in mind: for every task group you duplicate, you need double the cookies you needed before, since each running task should have 3 cookies. In numbers: 50 tasks in 1 group need 150 cookies, the same 50 accounts duplicated into a second group are 100 running tasks needing 300, and a third group makes it 450. Multi-SKU covers the same products at the original cookie cost. How the list behaves: there is no priority order. All tasks in the group go for whichever product the monitor picks up first, stay on it until it is completely out of stock, then move to the next product that pings in stock. Full details on [Monitor Setup & Multi Input](/general-setup/task-creation/monitor-setup-and-multi-input.md). {% hint style="warning" %} **Generate about 3 cookies per running task, not a pile beyond that.** Duplicated groups multiply the cookies you need for the same accounts, and going far past 3 per task raises your flag risk. To run more tasks, add more accounts. {% endhint %} ### Recommended settings These are the settings that have worked best. Start here. #### Hype Product Set this to ON / ENABLED. Hype Product must be enabled for any Target drop that requires Shape cookies, which is all the high-demand drops (cards, consoles, and similar). #### High Stock & Pre-Orders Only Optional. With this on, the bot only goes for high-stock items (10+ in the stock count) and pre-orders. Leave it off by default, including for a normal potential restock. #### Loop Checkouts Optional, and run at your own risk. It may increase flags and cancels. Loop Checkouts is also used if you are running multi-SKU and you hit. With this on, tasks do not stop at "Success." They keep looping to that same product (as multi-SKU always does) until that product is out of stock, then move to the next in-stock product. ### Rate Limit (High Demand) {% hint style="danger" %} **Do not open a ticket about Rate Limit (High Demand).** There is nothing we or you can do about it. This is Target rate limiting everyone's checkouts during high-traffic drops. It is not a proxy, account, or bot issue. It is a site-wide traffic throttle. {% endhint %} There is still a lot of confusion around Target rate limits. That makes sense, because the current Target experience is not intuitive for normal manual users either. Their system has made hype drops frustrating across the board. A regular "Rate Limit" message usually indicates a proxy or bot-related block. Based on our analysis, the bot-related rate limits that were happening a few weeks ago have been resolved. "Rate Limit (High Demand)" is different. This appears to be Target limiting how many requests can reach their backend during high-traffic drops. If you test manually and inspect the requests, you will see the same behavior: during hype drops, clicking Add to Cart often does nothing, and you have to click it repeatedly. The bot runs into the same issue. The response is a 429 and usually includes one of these errors: * `FAST_SELLING_ITEM_RATE_LIMIT_EXCEPTION` * `ERR_A2C_TCIN_RATE_LIMITED` You may also see this on-site as a "High-demand item in your cart" popup ("A popular item in your cart is causing a delay. We're managing high traffic right now. Please try again."). The bot just has to keep submitting the order and let it ride. That is what a task sitting on **Submitting Order** is doing: spamming submit order to force the order through the rate limit. Every bot has to brute-force it this way on high-demand drops, and it is why the number of accounts you run matters so much on Target. Go on the site manually at drop time and you will see it is barely functional for everyone, and you have to hope every action goes through. {% hint style="info" %} **This is all the information we currently have.** We do not know what percentage of requests Target allows through during this high-demand rate limit, but based on testing it is most likely intended to reduce traffic hitting their backend. That may work for Target, but it creates a poor experience for manual users and bots alike, especially since these drops often happen at 3 AM. {% endhint %} {% hint style="info" %} **"Rate Limit" and "Rate Limit (High Demand)" are not the same thing.** Plain "Rate Limit" has been heavily improved and fixed on drop. "Rate Limit (High Demand)" is different and you will still see it on any Target restock. Based on all current testing, this is a site-wide Target rate limit, not an issue with your setup or the bot. We are actively testing to see if there is anything we can do to mitigate it, but right now all signs point to this being controlled on Target's side. {% endhint %} ### Target Profiles & Cancellations The common cancellation states are **Item Demand**, **Fraud Deny (Consult OVT)**, and **Quantity Limit**. **Item Demand and Fraud Deny (Consult OVT):** although the statuses differ, they can be addressed the same way. In most cases, these cancellations are associated with your Target profile, account, proxy, and/or payment method rather than a setting in Refract. **Quantity Limit:** Target enforces a per-customer purchase limit on hype products and cancels orders beyond it. Target decides what counts as the same customer, and it links orders by more than the account alone: shipping address, payment method, and other identity signals can group your orders together. If several of your checkouts for the same product share too much information, expect the extras to get cancelled. The prevention is entirely on your end: keep checkouts per product within Target's limit per identity, and vary the identities across your setup. How far to vary them is exactly the profile territory your cook group covers. The Refract team can review our logs for signs of a Refract-side issue, but all of these cancellations are caused by Target-side order checks that we cannot diagnose or resolve. These outcomes vary heavily by user, and there is no single Refract-side change or guaranteed fix that works for everyone. #### What community testing shows about cancels None of this is a Refract setting or a guarantee. It is the closest thing to a consensus from extensive community testing, and it is the same picture support would point you to: * **Account age is the biggest factor.** Aged accounts stick orders; fresh accounts cancel far more, and there is no quick fix for that in your profiles. If fresh accounts are all you have, make them now and warm them up: cancels on a young account do not appear to hurt it long term, so an account that eats cancels today should still stick orders once it has age. * **Use a real Gmail per account, never a catchall.** A catchall might stick an order or two, but its long-term cancel rate is terrible. Other regular providers work, just suboptimally; Gmail is the consistent recommendation. * **Real bank cards stick far better than virtual cards, one card per account.** Physical Amex employee or business cards are the trap here: they are plastic, but they cancel like virtuals. Fewer profiles backed by true bank cards beats a big stack of virtual-backed profiles. Extra profiles on virtuals are fine as a supplement, as long as they do not dilute your bank card profiles. * **Heavy jigging matters less than people assume.** Target's cancel filter behaves like a fraud filter, not a duplicate filter. The same name across profiles is fine, addresses need little to no jigging, and the one field worth varying per profile is the phone number. The exception is Quantity Limit above: that check is about the per-customer limit, so orders sharing an address and payment method still get grouped against it. {% hint style="info" %} **Start with your cook group.** Users often compare notes in Discord communities and other cook groups to learn which strategies are currently helping reduce cancellations. Aside from trial and error, these communities are the best source of up-to-date information, since effective methods are often shared privately. There is no foolproof solution we can recommend, but this is the best place to gather ideas and begin testing different approaches. {% endhint %} {% hint style="warning" %} **Not in a cook group yet?** Ask around in the community for an active one to join, and start there. There are many options. {% endhint %} ### Important notes {% hint style="warning" %} **Shape security spikes during drops.** That is just how it is. Millions of tasks are spamming add-to-cart, and after the first wave it will be harder to ATC. {% endhint %} {% hint style="info" %} **Defaults exist for a reason.** The bot's defaults are what has worked best. You are free to change delays and harvester settings to test different things. That is your call. But asking us what to change them to will not help, because we do not have suggestions. If we had better values, they would already be the defaults. {% endhint %} --- # 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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://help.refractbot.com/modules/target/target-release-guide.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.