> ## Documentation Index
> Fetch the complete documentation index at: https://docs.aimventory.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Repricing
> Review and apply manual or scheduled price changes on supported StockX and GOAT listings, then verify provider-confirmed outcomes.
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.
| Step | Where in AIM | What you do | What you should see |
| ---- | --------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 1 | Active Listings | Select active StockX or GOAT listing rows. | The selection is made up of listing rows supported by this repricing path. A row without a supported marketplace listing cannot be dispatched. |
| 2 | Active Listings pricing controls | For a direct change, enter a positive dollar ask. For a bulk change, choose **set**, **add**, **subtract**, **discount percentage**, **match-market offset**, **target payout**, **payout margin**, or **profit dollars**. | The chosen mode has the data it needs, and any optional floor or ceiling clamp is explicit. |
| 3 | The selection | Keep each request at 2,000 updates or fewer. Split a larger selection into additional requests. | Each request stays within the supported limit. |
| 4 | Pin control | Turn pinning on only when you want the manual price to become a fixed price for scheduled repricing purposes. Leave it off when the request should not write a new fixed formula. | With pinning on, the manual change writes a bare fixed price and scheduled repricing skips that listing. With pinning off, the request carries no new fixed formula; it does not remove an existing pinned state. |
| 5 | Active Listings Apply controls | If listed market data is refreshing, wait for the page to enable its Apply controls. | Active Listings blocks its own Apply controls while that refresh is running. This is a page-level gate, not a server-wide repricing lock. |
| 6 | Active Listings Apply | Apply the manual or bulk change. | The change is submitted for provider processing. Submission is not proof that the marketplace applied the price. |
| 7 | Provider result and price history | Review each item's terminal provider result, then review the corresponding price evidence. | A successful terminal provider result is necessary but not sufficient: AIM must also resolve the matching local listing relationship. If it cannot, the item remains failed and receives no local applied-price writeback. Partial, cancelled, authentication, rate-limit, timeout, and retryable network outcomes are not successes. |
### Example: one manual decision carried through
Harbor Kicks wants to move a fictional size-9 Jordan 4 listing from $240 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.
| Choice | Result |
| -------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- |
| Pin off | The request carries no new fixed formula. This avoids writing a new fixed formula, but does not remove an existing pinned state. |
| Pin on | Active Listings writes a bare fixed price. The scheduled planner skips that listing. |
| No formula recorded | The scheduled planner can fall back to a marketplace default. Do not assume that every listing without a formula is skipped. |
| Bare fixed price with no market signal | This is the established skip case for scheduled repricing. |
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.
| Lane | What it records | What it does not prove |
| -------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Active Listings and scheduled batch or guard | Current writers emit `price_submitted`, `price_applied`, `price_failed`, and guard lifecycle events with bounded batch or guard evidence. `price_proposed` is allowlisted but not emitted by the current runtime. A manual bulk dispatch only attempts a business-action audit row on a best-effort basis; that row is not provider confirmation and may be absent. | A calculated target or submitted event is not an applied price. Provider terminal success is necessary but not sufficient: AIM must resolve the matching local listing relationship; a missing relationship remains failed and receives no local applied-price writeback. |
| Older direct Repricing action | Legacy repricing metadata and a best-effort operation record. | It is not proof that every direct result also appears in the append-only price-event history. |
| Pricing rules | A rule-run record plus aggregate sync results. | It does not mean there is one price event for every listing. |
| Inbound listing refresh | A provider-to-AIM listing snapshot that can update local price, listing status, and related metadata. | A refreshed local snapshot is not proof that an outbound repricing was applied. |
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
| What you see | What it means | What to do |
| ----------------------------------------------------------- | -------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- |
| Apply is disabled | The listed market-data refresh is running. | Wait for Active Listings to enable Apply. Remember that this page gate does not arbitrate the older direct Repricing path. |
| A row is already pinned after a manual request with Pin off | Pin-off did not write a new fixed formula; it does not establish removal of an existing pin. | Verify the pinned state. Stop and contact support if you need an established removal path. |
| A bulk mode cannot calculate | Its stated market, payout, margin, or profit data is not available. | Supply the required data or choose a mode whose prerequisites you can verify. |
| A provider result is partial, cancelled, or failed | The affected item is not a confirmed applied price. | Keep the outcome in its failed or incomplete state and review the per-item provider result before taking another action. |
| The older Repricing screen shows a success-styled result | The view may have ignored a non-success provider response. | Do not use the modal as confirmation; check provider-confirmed item results and the matching audit lane. |
## 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.
## Related
* [Quantities, and why received is not ready to list](/concepts/inventory-numbers) — keep listing eligibility separate from price eligibility.
* [What syncs, when, and who wins](/understand/what-syncs-and-who-wins) — see the broader channel direction and the existing winner-free price-overlap warning.