Bulk ordering: batching links and avoiding duplicates

A bulk order fails for boring reasons. The same link appears twice under two URL forms. A batch exceeds the service maximum and is split silently. A partial delivery is refunded against the batch but not against the link, so nobody knows which account is short. The rate was fine. The data was not.

This guide treats a bulk order as a list-processing job. The purchasing step is short once the list is clean: normalize, deduplicate, batch against the row's limits, keep a manifest, and reconcile the delivery line by line. The method works for a short list or a long one, and it is the same method a reseller needs for a client list.

Normalize before you count

Two links can point to the same target and look different. A profile URL with a trailing slash, a post URL with a tracking parameter, a shortened link that redirects, a video URL with a timestamp: all four can be the same delivery target. If you count them as four, you will order four times.

Normalization is the step that reduces each link to the identifier the platform uses. Keep the host, the path and the identifier. Drop the query string unless the query is the identifier, drop the fragment, resolve the shortener, and use the canonical form the platform serves. Do the work in a spreadsheet column next to the original link, so the original is still visible for review.

Platform	What to keep	What to drop
Instagram	Profile name, or the post or reel shortcode	Tracking parameters, share tokens, trailing slash
TikTok	Profile name, or the video id	Share parameters, shortener redirects, language prefix
YouTube	Channel id or handle, or the video id	Timestamps, playlist parameters, tracking parameters
Telegram	Channel username or invite hash	Message ids, share parameters, preview tokens
X	Handle, or the post id	Referral parameters, share tokens, trailing slash

A normalization checklist. It contains no market figures.

The identifier matters more than the URL. A username can change, and an old URL may redirect or fail. A numeric id is stable. Where the platform exposes an id, keep it in the manifest next to the URL. When a link stops resolving, the id is what lets you find the same target again.

Deduplicate in three passes

The first pass is exact: sort the normalized list and compare adjacent rows. The second pass is structural: strip the scheme, the www prefix and the trailing slash, then compare again. The third pass is by identifier: compare the id column, not the URL. Each pass catches a different kind of duplicate, and the third pass catches the ones the first two miss.

Keep a count at each pass: rows in, rows out, duplicates removed. A list that shrinks by a large share after normalization is a list that was built by copying links from different places. That is normal. What is not normal is a list that still has duplicates after the third pass, because that means the identifier column is not trustworthy.

Retries are where new duplicates are born. Before you re-order a link that failed, check the manifest for an existing order id and its state. A failed order can still be pending, and a pending order can still start. Re-ordering a pending link is a double order with a clean-looking spreadsheet.

Batch by the stated limits

Every service row states a minimum and, usually, a maximum. The maximum is the ceiling for one placement. A batch above it is either rejected or split by the panel, and a silent split produces two order ids, two start times and two refund paths. Plan the split yourself so you know what you are buying.

When the market table has stated limits, the table below reads them at the time this page is rendered. The maximum is a median across the panels quoting the product, so it is a planning figure, not a promise for a specific panel. The last column shows how many placements a 100,000-unit order needs at that median maximum.

Product	Panels	Min order	Max order	Placements for 100,000
Instagram followers	28	10	1,000,000	1
Instagram likes	30	10	300,000	1
TikTok views	26	100	1,000,000,000	1
TikTok followers	26	10	500,000	1
YouTube views	29	500	1,000,000	1
YouTube subscribers	10	10	100,000	1
Telegram members	24	100	100,000	1
X followers	20	100	100,000	1
Spotify plays	19	500	5,000,000	1

Limits are medians of the active offers in the market table, read when the page is rendered. A specific panel can state a different maximum. Market edition: 7 November 2026.

Two rules follow from the table. First, batch at or below the maximum, never above it. Second, keep the batch small enough to reconcile. A batch that is too large turns one partial delivery into a large open ticket, and the ticket has to name every link in the batch. A small batch is easier to settle than a large one, even if the rate is the same.

The minimum matters in the other direction. A batch of small quantities can fall below the minimum for the service, or the panel may apply the minimum per link rather than per order. Ask which rule applies before you build the list. The answer decides whether a list of small accounts can be ordered as one batch or has to be grouped.

The manifest

The manifest is the only document that survives a bulk order. It maps every link to an order id and every order id to a charge and a delivery. Without it, a partial refund is a number without a target.

Column	What it holds	Why it matters
Row	A stable row number	Lets you refer to a link without repeating the URL
Original link	The link as supplied	Shows what the client or the sheet actually asked for
Canonical link	The normalized form	The link the order should use
Identifier	The platform id or shortcode	Survives a username change
Variant	Platform, category, quality, country, refill	Prevents a batch from mixing products
Quantity	The units for this link	The basis for the per-link refund
Batch	The batch id	Groups the links placed together
Order id	The panel's order id	The key for support and reconciliation
Charge	The amount paid	Matches the wallet entry
Delivered	The units that arrived	The basis for the delivered cost
Refund	The credit for the shortfall	Closes the row
State	Pending, in progress, partial, complete	Stops a retry on an open row

A manifest schema. It contains no market figures.

Keep the manifest in a format you can filter, not in a chat thread. A spreadsheet or a small database is enough. The point is that every link has one row and every row has one state. When a delivery arrives short, the row tells you which link to re-order and which to leave alone.

Place the batches

Place one order per batch, not one order per link, if the panel supports a multi-link order. Check how the panel counts the minimum and the maximum on a multi-link order before you use the feature. A panel that applies the maximum per link and a panel that applies it per order produce different batch plans from the same list.

Stagger the batches if the platform is sensitive to spikes. A batch that starts every link at the same minute produces a delivery curve that no single order explains. A stagger of hours or days gives each batch its own start time and gives you a baseline between batches. The stagger is a risk choice, not a guarantee; the platform can still treat the delivery as inauthentic.

Keep the variant constant across a batch. Mixing a standard row and a real row in one order makes the delivery impossible to interpret: a drop in one part cannot be attributed to the pool or to the row. If a client list needs two variants, split it into two manifests and two batches.

When a link cannot be normalized

Some links resist normalization. A shortener that no longer resolves, a profile URL that redirects to a login page, a video that is region-locked, a post that was deleted after the list was built. These rows should not be placed. Move them to a separate tab with the reason, and send the list back to whoever supplied it. A bulk order is not the place to guess what a link was meant to point to.

The same rule applies to a link that resolves to a different target than the label says. A row labelled with one account that opens another is a data error, not a delivery opportunity. Correct the row before it enters a batch. A batch with one wrong link produces a partial delivery that is hard to explain and harder to refund.

Client lists and permissions

A reseller's bulk order is a client list with a payment attached. The list is sensitive: it maps an account to a service and a quantity, and it may include an account the client has not announced. Keep the manifest in a place the client cannot edit, and share only the rows the client needs. Do not put the list in a public spreadsheet with a link that anyone can open.

If a team member places the batches, give them the manifest and the batch plan, not the account passwords. The order needs a public link, and the team member needs the row and the quantity. A shared login is a security problem that a bulk order does not require. The privacy guide covers the boundary in more detail.

Reconcile partial delivery

A partial delivery is a batch-level event with a link-level consequence. The panel refunds the undelivered share to the wallet; the manifest has to distribute that refund across the links. Do it in this order: read the delivered quantity, subtract it from the ordered quantity, allocate the shortfall to the links in the batch, and mark each row with the refund it should receive.

If the panel reports only a batch total, ask for the per-link remains. A supplier that can deliver a multi-link order can report which link stopped short. If the panel cannot, the batch is not reconcilable, and the next batch should be smaller or single-link.

Do not re-order a short link until the first order is closed. A partial order can still be open for a correction or a refill. Re-ordering it while it is open is the duplicate that the manifest was built to prevent.

A five-minute check before you place a bulk order

1. Normalize every link. Canonical host, path and identifier. Keep the original in the next column.
2. Run the three dedupe passes. Exact, structural, identifier. Write the counts.
3. Write the variant once. Platform, category, quality, country, refill. Apply it to every row.
4. Check the minimum and maximum. Batch at or below the maximum, and confirm whether the minimum is per link or per order.
5. Build the manifest before you pay. One row per link, one batch id per group.
6. Place the batches with a stagger. One order per batch, same variant, same window.
7. Reconcile on delivery. Per-link delivered, refund and state. No retry until the row is closed.

A bulk order is a list with a payment attached. The list is the part you control. Clean it once, keep the manifest, and the rate becomes a small variable in the result.

For the charge at each quantity, read the price formula. For the states a batch passes through, read the order lifecycle. To place a first batch, open the guided order flow or the full catalogue.