Skip to main content
Repricing changes the price of a supported StockX or GOAT marketplace listing. Use this page for a manual or bulk change in Active Listings, for scheduled repricing, and for checking whether a provider actually applied the result. A submitted change is not an applied change until the marketplace returns a successful terminal result for that item and AIM resolves the matching local listing relationship. If that relationship is missing, the item remains failed and receives no local applied-price writeback. Who does this: the operator responsible for listing prices. Who else is involved: the provider account and the person who reviews failed or partial results. This workflow covers StockX and GOAT listing prices. Quantity publication to eBay or Shopify is a different channel operation, not this repricing workflow.

Before you start

  • Open Active Listings and select the active StockX or GOAT rows you want to price.
  • Decide whether this is a one-time manual price or a bulk calculation. Bulk modes need their stated market, payout, margin, or profit data before they can calculate a result.
  • Decide whether to pin the manual price. Active Listings starts with pinning off; a manual change is not automatically pinned. Pin-off avoids writing a new fixed formula, but it does not remove an existing pinned state.
  • For scheduled repricing, the listing needs a positive Repricing buffer, a current and starting ask, a mapped variant, fresh market evidence, and an active supported listing.
What this touches: the marketplace listing price, the formula choice that controls whether a listing can enter the scheduled lane, the provider submission and terminal result, and the matching price-history evidence.

Manual and bulk repricing in Active Listings

Use one concrete decision for each selection: enter a positive dollar ask for a direct manual price, or choose one bulk mode and confirm its prerequisites. Optional floor and ceiling clamps keep the calculated result inside the range you choose.

Example: one manual decision carried through

Harbor Kicks wants to move a fictional size-9 Jordan 4 listing from 240to240 to 220 on StockX and GOAT. The operator selects the two Active Listings rows, enters the positive $220 ask, and leaves pinning off because this request should not write a new fixed formula. Before relying on scheduled eligibility later, the operator verifies that the rows are not already pinned; pin-off does not remove an existing pinned state. For a larger group, the operator chooses one bulk mode only after checking its required data. If a market-offset calculation would fall below the chosen floor, the floor keeps the result from going lower than that boundary. The operator applies the request only after the page’s refresh gate has cleared, then treats each provider-confirmed result separately: a successful row is applied, while a partial or failed row is not treated as applied.

Pinning and scheduled repricing are different choices

Pinning controls whether a manual price becomes a bare fixed formula. Scheduled repricing controls whether an eligible listing can be considered against fresh market evidence. They are not two names for the same action. For a row that is already pinned, verify its pinned state after the request. If you need an established way to remove that existing pin, stop and contact support; this page does not establish a customer-visible removal action.

How scheduled repricing decides

Scheduled repricing is opt-in through a positive Repricing buffer. An eligible listing is active on StockX or GOAT, has its marketplace identity, current and starting asks, a mapped variant, and fresh market evidence in the current refresh window. Scheduled repricing moves only downward from its selected market reference. It never raises an ask in this lane. The result is clamped by the chosen Floor price and the starting-ask-minus- buffer boundary, and the business-scoped own-lowest-ask guard prevents a deliberate undercut of that local floor. The protective guard uses precise price arithmetic, but scheduled repricing currently keeps that guard in diagnostic shadow behavior. Shadow evidence is useful for review; it is not proof that AIM blocked, delisted, or relisted a marketplace listing. After a listed market-data refresh completes, scheduled repricing can be queued for the refreshed scope. The scheduled lane has its own eligibility and freshness conditions; do not use the broader refresh result as a substitute for the terminal provider result on an individual price change.

Submitted is not applied

For Active Listings and scheduled batch changes, AIM waits for terminal marketplace results before attempting local applied-price writeback. Provider terminal success for every submitted item with no provider failures is necessary for batch processing. AIM then resolves each item to its matching local listing relationship: a missing relationship remains failed and receives no local applied-price writeback. Only an item with both provider terminal success and a matching local listing can receive local applied-price evidence. A partial or cancelled batch, an authentication failure, rate limit, timeout, or retryable network failure is not a successful application.
The older Repricing surface has two different data paths: preview uses the market data already stored in AIM, while execute refreshes selected market data before calculation. Its mixed-call result view can ignore a non-success provider response and still open a success-styled result. Treat that view as an estimate or a summary, not as proof that every provider request succeeded. Use the per-item provider-confirmed batch result and its audit evidence instead.

Keep the audit lanes distinct

There is no single universal repricing-history record. Use the lane that produced the change, and do not treat one lane’s evidence as proof that another lane ran. For Harbor Kicks, a confirmed $220 StockX result belongs to the batch lane if it came from Active Listings. A later inbound refresh is a separate snapshot lane; it must not be read as a second, confirmed outbound repricing.

When a refresh overlaps repricing

Active Listings disables its own Apply controls while its listed market-data refresh reports that it is running. That control only gates the Active Listings page; it is not a server-wide lock and it does not govern the older direct Repricing path.Inbound StockX/GOAT listing refresh and outbound repricing are independent writers of the local listing price. Current behavior provides no shared version check, lock, or deterministic arbitration, so AIM does not establish a winner when the paths overlap. Do not assume that the inbound refresh, the outbound repricer, or the last change wins. Resolve the situation from the provider-confirmed outcome and the resulting local listing state.

If something changes after you apply

Check it worked

  1. Each selected listing has a successful terminal provider result.
  2. Each item with a successful terminal provider result resolves to a matching local listing and has local applied-price evidence; a missing relationship remains failed and receives no writeback. Failed or partial items do not count as applied.
  3. For scheduled repricing, the resulting ask is downward-only and remains within the Floor price, starting-ask-minus-buffer, and own-lowest-ask protections.
  4. The evidence is in the lane that produced the change: batch/guard events, legacy metadata, pricing-rule results, or an inbound refresh snapshot.

What was recorded

The provider result, submitted/applied/failed outcomes, guard lifecycle evidence, and inbound snapshot remain distinguishable. price_proposed is allowlisted but current batch/guard writers do not emit it, so this workflow does not promise a durable proposal event. A manual bulk dispatch may also lack a business-action audit row: that audit is best-effort and is not provider confirmation. For an applied outcome, provider terminal success is necessary but AIM must resolve the matching local listing relationship; a missing relationship leaves the item failed with no local applied-price writeback. This distinction lets you tell a submission from a confirmed application, a failure, and an inbound snapshot from an outbound repricing.
Last modified on August 9, 2026