Submit Listings and Track Their Status

Last updated: Oct 15, 2026 at 12:51PM

Once a listing shows Ready for Submission, submitting it sends its data to the marketplace for approval — and Osello tracks every step from there until it's live.

Submitting is paused while your Osello subscription payment has failed. Every submit action then refuses with a message saying so, and a banner at the top of the page links to Stripe to update your card. See Fix a failed payment or an expiring card.

Submit a single listing

1. Open the listing. When it's ready, a Submit Listing button appears at the top (it reads Resubmit Listing if the listing has been submitted before).
2. Click it and confirm. Any pending changes are sent along with the submission.

For a listing with variants, the confirmation dialog shows these options. When one doesn't apply to the listing, it's grayed out, and hovering it says why. A standalone listing has only one variant, which is always sent, so the dialog shows neither.

• Only submit changed variants starts checked. Osello sends only the variants the marketplace doesn't have the latest version of: ones never submitted, ones edited since their last submission, and ones whose last submission failed or was rejected. Editing the listing's parent data (its category, group code or shared fields) marks every variant, so the whole listing goes. Uncheck it to resubmit every variant. If nothing has changed, the dialog says so and sends nothing. It's locked on a listing's first submission, where every variant is new.
• Include disabled variants appears when the listing has disabled variants, and starts unchecked. When every variant is disabled it's locked on, since leaving them out would send nothing. Checking it sends their content too, following the setting above: an unchanged disabled variant stays behind when only changed variants are being sent. No offer goes live for a disabled variant until you enable it. On Target+, submitting a disabled variant re-enables it instead, and the dialog warns you first. A disabled Target+ listing always goes whole: submitting it re-enables the listing and every variant, so the dialog shows no options.

Both options are available to API callers as only_changed_variants and include_disabled_variants on the listing submit endpoint. Both default to off there.

If Osello already knows the listing isn't ready, the dialog stays open and tells you exactly what to fix, and nothing is sent. That covers the parent as well as the variants, so a required value missing at the parent level blocks the listing even on marketplaces that don't carry a parent product.

Otherwise the dialog switches to a progress view and reports each step as the submission works through it — loading the variants, checking the listing's content, validating, sending. You can close it at any point; the submission keeps running and its status shows on the listing. The full content check runs there rather than while you wait, so submitting a style with hundreds of variants starts just as quickly as a small one.

Submit in bulk

1. On the marketplace's Listings page, select the listings you want (or select all matching your current filter).
2. Choose Submit to Marketplace from the actions bar.
3. Confirm. Listings with missing or invalid required values are skipped — only the ones that are ready get submitted. Use the Action required filter to find what was left behind and fix it.

A large bulk submission can take a while. If it's interrupted partway, when Osello restarts its servers for instance, it picks up where it stopped: listings already sent stay as they are and the rest still go out. Listings you resubmitted in the meantime are skipped, because the newer submission covers them. The listing that was being sent at the moment of the interruption shows Submission Failed with a note to submit it again. A submission interrupted before it gathered its listings fails instead of starting late; submit it again.

Submit only some variants of a listing

A new colorway usually arrives with its full size run while the sizes already on the marketplace are settled and selling. You don't have to resubmit the whole style to send it:

1. Open the listing and go to its Variants tab.
2. Select the variants you want to send — the new color's sizes, say.
3. Choose Submit to Marketplace from the actions bar and confirm.

Only the variants you selected are sent. The rest of the listing is left exactly as it is, so a sibling that's still half-filled doesn't hold your selection back, and a variant that's already approved isn't put back through review.

Two things to know:

• Every variant you select has to be ready. If any of them is missing a required value or has one that fails validation, nothing is submitted and the dialog names the SKUs to fix or deselect. This is the opposite of the bulk listings action above, which skips what isn't ready — here you picked the variants by hand, so we don't quietly drop any of them.
• Disabled variants can be submitted. Their content goes to the marketplace, but no offer goes live until you enable them, and the dialog says so before you confirm. A disabled listing is different: nothing under it can be submitted until the listing itself is enabled. On Target+, submitting re-enables the variants you picked, and the listing too if it was disabled. The dialog says so before you confirm.

On marketplaces that carry a parent product (Target Plus), the listing's parent data is always sent alongside your selection — the marketplace needs it to attach the variants to.

On Target Plus, a listing's variation options go out as Target's variation themes: Color, Size, and Size Type (Size Group on Target). Each variant sends its own color name, while its size and size group are sent from its Product Size and Size Grouping fields, because Target only accepts its own values for those.

On Target Plus, the parent product carries only the fields Target holds at the parent level. A field you can set on both the listing and its variants is sent on each variant instead: the variant's own value, or the listing's value while its Use parent value box is checked.

Track the status

The status badge updates live at every step, from the moment you click Submit:

• Submitting — the submission is on its way to the marketplace.
• Submitted — the marketplace received it and Osello is waiting for it to acknowledge the review; this usually moves to Pending Approval within minutes. Nordstrom, Macy's, Bloomingdale's, Shop Simon and Dia & Co can take longer: they import each submission as a file, and a variant stays Submitted until the marketplace has imported it.
• Submission Failed — the submission never reached the marketplace. Either Osello's own check found something missing or invalid when the submission started (content can drift between clicking Submit and the submission running — a new required field, an edit, a rejected image), the marketplace's server errored, or the submission was interrupted before the listing was sent. Hover over the badge for the reason, fix anything it mentions, and resubmit. Submitting a listing sends it whole: if one variant fails the check, the whole listing is held back rather than sending its siblings without it. Submitting variants from the Variants tab is the exception — there only the variants you selected are checked and sent.
• Pending Approval — the marketplace is reviewing the submission.
• Pending Publication — the marketplace accepted your content but hasn't published the product to its catalog yet. Nothing to do; the offer goes out automatically once the product is published. Some marketplaces (Nordstrom, Macy's, Bloomingdale's, Shop Simon, Dia & Co) publish on their own schedule, so this step can take a while.
• Pending Offer — the content was approved; the price and inventory (the offer) go out next, which usually happens automatically.
• Offer Submitted — the offer is with the marketplace, awaiting activation.
• Live — approved and selling. A red out-of-stock icon beside the badge means the offer carries no inventory: the listing is live, but the marketplace has nothing to sell, so the product may not show on the storefront. Hover over the icon (tap it on a phone) for the note. The icon only ever sits beside a live badge (Live, Live*, Partially Live or Partially Live*): a listing that is not live yet has nothing on the marketplace for stock to hide. It also appears on a live listing whose variants are all out of stock, on the listing and variant tables, and on each page header.
• Changes Required — the marketplace reviewed it and asked for a fix; hover over the badge (tap it on a phone) to see what. Correct it and resubmit.
• Rejected — the marketplace isn't taking the product at all (an assortment or SKU-gating decision, say), so there's nothing to resubmit. See fix rejected listings for the difference between the two.
• Unlisted / Suspended — the marketplace took the item down (discontinued, removed on request, or your account is inactive). Resubmitting an unlisted listing starts the cycle over from Submitting; see fix rejected listings.

Editing a listing that's already been submitted rolls its status back to Ready for Submission (or a completion percentage if the edit left required fields unfilled) so it's clear the marketplace hasn't seen the new version yet; the badge tooltip also notes when changes are pending submission. The only badge that ever carries an asterisk is Live* — it means an older version of the listing is live (a plain Live badge means the latest version is live).

Listings with variants show two badges

A listing with variants tracks two things that move independently: how far along its variants are, and how much of it is live on the marketplace right now. So it shows up to two badges.

The first badge is progress. When every variant is at the same step it reads plainly (Pending Approval); when they differ it names the one that needs attention first and prefixes it — Partially Changes Required, Partially Submitted. Ordering is deliberate: anything still setting up comes first, then the states you can act on (incomplete, then changes required, then ready), then the rest of the lifecycle, and finally the states you can't act on (rejected, unlisted, suspended). Disabled variants are ignored entirely — they aren't holding anything back. Hover the badge for the full breakdown of which variants are where.

Two labels never take the "Partially" prefix. Ready for Submission doesn't, because you submit a listing as a whole, so a partial version isn't something you can act on differently. The completion percentage doesn't either, because it's calculated across the whole listing — though Partially Invalid does appear when only some variants have validation errors.

The second badge is liveness: Live, Partially Live (some variants are live, the rest aren't yet), or the same two with an asterisk when what's live is an older approved version. A listing that's fully live with nothing outstanding shows a single Live badge.

Target Plus reviews a listing's parent product separately from its variants, so it can approve every variant while the parent is still pending. Until the parent is approved too, the listing reads Partially Pending Approval and Partially Live, and the badge tooltip lists the parent's state beside the variants. An approved parent never makes a listing live on its own: with no variant live, nothing is for sale.

When you resubmit a live listing

Editing and resubmitting a listing that's already live doesn't take it down — the marketplace keeps selling the old version until the new one is approved. While that's in progress the first badge shows where the new version is (for example Pending Approval), and a second outlined Live* badge appears beside it to confirm an older version is still live on the marketplace. Hover over either badge for details. A banner on the listing page also tells you when a previous version is live and what to do next.

Filter by what needs doing

To watch a group of listings, open Filters on the Listings page and pick a category under Show. The same picker appears on the variants table inside a listing.

• Action required — needs work from you: incomplete or invalid, ready for (re)submission, changes required, submission failed, or unknown.
• Waiting — nothing to do but check back. Reason covers both sides in one list: the marketplace's (submitted, pending approval, offer submitted) and Osello's (setup, a submission in flight, an offer that hasn't gone out yet).
• Live — selling on the marketplace. Live State starts with all four rows selected; untick to narrow.
• Inactive — disabled by you, or rejected, unlisted, or suspended by the marketplace. Nothing here is waiting on you.
• Any state — the two badge axes directly. Current version matches the exact progress badge, Partially forms included; Last approved version matches the liveness badge. Use this when you want the results to mirror a specific badge exactly. Turn on Omit disabled listings to see every listing except the ones that are fully disabled.

Live State has four rows because liveness is two questions at once — how many variants are live, and whether any of them is live via an older approved version (the asterisk):

	All up to date	Some on an older version
Some variants live	Partially Live	Partially Live*
All variants live	Fully Live	Fully Live*

Tick whichever combination you want: both Fully rows for "completely live, whatever version"; both asterisked rows for "has edits that haven't gone live yet".

Outside the Live category the same picker appears as Last approved version with two extra rows: Not Live (nothing live at all) and Not Fully Live (at least one variant still isn't live — listings with nothing live count too). Pairing it with a category is how you ask a question like "needs action and isn't fully live yet", so you can chase the SKUs that are still holding a listing back. Fully Live isn't offered there, since a listing with nothing outstanding can't also be in one of those categories.

The four categories match a listing if any of its variants is in one of those states, so a listing with one SKU needing changes still shows under Action required even when its badge reads something else. That means a listing can legitimately appear in more than one category. Two exceptions: a listing you've disabled shows only under Inactive, whatever its variants say — disabling it is the whole story, so its variants read and filter as Disabled too, and nothing on it counts as live; and Any state matches the badge itself.

Expanding a listing's row carries your filter down with it. The variants table opens showing only the variants that put the listing in your results, so the one SKU needing changes is right there instead of buried among its siblings. Open Filters on that table to widen it back out. Filters that describe a mix rather than a single variant don't carry down — a Partially progress badge such as Partially Submitted, or Not Fully Live — so a row filtered that way opens showing every variant. The one exception is Partially Live under the Live category: it carries down to the variants that are live, since those are what you opened the row to see.

Inactive variants sit at the bottom of the variants table, both inside a listing and in an expanded row. That covers everything under Inactive in the filter: variants you disabled, variants in a disabled listing, and variants the marketplace rejected, unlisted, or suspended. Sorting by Updated is the exception: the most recently updated variant comes first even if it's inactive, and inactive variants only drop below the rest when they were updated at the same moment.

The Listings page does the same for whole listings: disabled listings sit below the rest, most recently updated first within each group. Choosing a sort column yourself turns this off.

Every category shows a live count, so you can see at a glance where the work is — and each stays listed even at zero, because "nothing to do here" is the useful answer. Picking one narrows to exactly that many rows.

Choosing a category is usually all you need. More options underneath opens the individual states within it, each with its own count; states with a count of zero are hidden there.

Filter by source product tags or SKU

The same Filters dialog has two sections for this. Source Product Tags follows a listing back to its source products and keeps only listings made from a product matching your tag query — the same query language as the Products page (combine tags with AND, OR, NOT, and parentheses); listings that aren't linked to a source product never match a tag filter. SKUs matches the listing's own variant SKUs against a pattern, with a Doesn't match mode to exclude instead.

Both sections also appear on the variants table — inside a listing, and in the sub-table you get by expanding a listing on the Listings page — where they narrow individual variants instead of whole listings. Two differences worth knowing:

• Source Product Tags matches the variant's own source product, so a listing built from more than one product can show just the variants that came from the tagged one. A variant with no source product never matches.
• SKUs checks the variant's listed SKU and its source product's SKU, and keeps the variant if either matches. The two can differ, because a listed SKU is frozen at first submission while the source keeps changing (see Listing SKUs and barcodes after submission). Doesn't match excludes a variant when either of its SKUs matches, so nothing you asked to drop slips through on the strength of the other one.

These two carry down into an expanded row the same way the status filter does, and unlike the status filter they always carry down in full — a tag query or SKU pattern asks the same question of a variant as it does of its listing, so there's no "mix" case to leave behind.

Dig into a specific listing

Every listing has tabs with the full paper trail:

• Submissions — each submission with when it happened and how many variants were approved, rejected, or still pending. Open one for the details, including any rejection reason.
• Issues — everything the marketplace sent back, sorted into categories and tied to the variant or field it affects.
• History — a searchable log of changes to the listing and who or what made them. It covers the whole listing: changes to the listing itself, to any of its variants, and to any field value. The Variant column says which variant each row belongs to — a specific variant by its options (linked to that variant), or Parent for the shared data every variant inherits. Changes to the listing as a whole leave the column blank. The By column names who made each change, and what it came through: a sync, an import, an AI chat or an AI assistant you connected (for example, Jay via Claude MCP). Search by a variant SKU, the listing's group code, a field name (such as Size chart) or an assistant's name (such as Claude) to narrow it down.

Because editing a submitted listing rolls it back to Ready for Submission, History is where you find out why that happened. Every change that can cause it is recorded: an edited field value, a changed SKU or barcode, a swapped variant option or group image, a new category, and disabling or re-enabling a listing or variant.

Submission milestones are marked with an icon so they stand out from edits:

• Submitted listing, with who submitted it and how many variants went out.
• Disabled and Re-enabled, for the listing or a variant.
• Changed content state from Pending approval to Approved (or whichever states apply) when the marketplace or a person moves a variant to a settled state such as Approved, Changes Required, Rejected, Unlisted or Submission Failed. The in-between steps of a submission (Submitting, Submitted) and the switch between Incomplete and Ready for Submission while you edit aren't listed.

Offer updates (price and inventory pushes) don't appear in History.

When the same change reaches several variants at once, such as disabling six sizes in one go or the marketplace approving a whole colorway, the listing's History shows it as one row. Click the 6 variants button on that row to see each variant it covers. A variant's own History tab still lists the change on its own.

The marketplace also has a store-wide History page in the sidebar covering changes across all its listings, grouped the same way.

What a submission's own status means

A submission is the record of one push. Its status describes what happened to that push — not whether the listing is selling today, which is what the listing's own badge is for. Alongside Approved and Rejected you'll see:

• Pending Approval — the marketplace is still working through this submission.
• Accepted — the marketplace took the data and closed out this submission without giving a verdict on it. Common on Nordstrom, Macy's, Bloomingdale's, Shop Simon and Dia & Co, where the retailer reviews on its own schedule. Nothing to do; the listing's badge tracks what happens next.
• Superseded — you submitted the same variants again (from the listing, or from its Variants tab), so this older submission stopped being the current one. It can still be approved on the marketplace's side, and if it is, the listing goes live from it — a submission can't be recalled once it's been sent.
• Expired — the marketplace no longer keeps a record of this submission (they clear them out after a few months), so its outcome can't be looked up anymore. Only affects old submissions, and never the listing itself.

Where to go next

• Fix rejected listings
• Required fields and listing readiness
• Offers: price and inventory