Your eBay Listings Don't Silently Break Anymore

You list an item on eBay through ListForge. A week later a buyer sends a Best Offer, or eBay changes something quietly on their end, and your listing in ListForge stops matching reality.

Until now you might not find out until a sale falls through, or your inbox fills with failure emails that don't say what actually failed. That is listing drift: same Active badge, two different marketplace realities.

We changed how ListForge tracks and repairs eBay listings so drift gets caught on an hourly scan, starting with whichever listings have gone wrong the longest. When a publish fails, you should now see the real reason, not a generic dead end, and you're less likely to get buried in repeat emails about the same problem.

The problem: looks fine in ListForge, isn't fine on eBay

Resellers do not run their day on vibes. You run it on whether Active is actually live, whether Best Offer is still on, and whether a failed publish is worth retrying.

The painful case is the silent one:

• ListForge looks healthy
• eBay already moved on
• Nothing red-flagged it
• You keep working from a story that is already wrong

That is not a dramatic outage. It is quiet disagreement between your tool and the marketplace, and it only becomes loud when money or time is already gone.

What drift actually costs

Drift costs more than one bad listing.

• You respond to Best Offer state that is already wrong
• You quote availability that eBay no longer has
• You burn an afternoon double-checking Active because you no longer trust the dashboard
• You get a stack of failure emails that all point at the same item and still never say what broke

The first hit is usually a sale going sideways or an inbox flood. The longer hit is trust. Once Active stops meaning active, people fall back to checking eBay by hand, which is the opposite of why they bought automation.

How repair works: oldest broken listings first

ListForge now scans for listings that have quietly drifted and repairs them on an hourly pass.

The important part is priority. It does not pick at random and it does not only touch what you happened to open today. It starts with the oldest unrepaired problems first.

The loop is simple on purpose:

1. Detect stale Best Offer, field drift, and failed publishes against live eBay state
2. Prioritize longest-unrepaired first
3. Repair from marketplace truth instead of a stale local snapshot
4. Explain failures with a real next step when publish still cannot go through

We also tightened the work around that scan so it is less wasteful while it runs: prefer the event payload when it already has what we need, cool down repeated deep fetches, and skip re-hydrating webhook events that are already synced.

Will every edge case disappear overnight? No. The useful signal this week is how many long-standing drifts the scan actually clears. But "stay wrong until a human notices" is no longer the default.

Best Offer status you can trust

Best Offer is one of those fields that looks small until it is wrong.

If ListForge overwrites a known Best Offer value with blank data, the UI can claim something is off when eBay still has it, or the opposite. You make decisions from that false picture, and only later realize the negotiation state was garbage.

Best Offer sync no longer clobbers known values with null. If we already know a real status, empty noise from a partial update should not erase it. When you look at Best Offer in ListForge, you should be looking at something that still means what eBay means.

When a publish fails, you now see why

A failed publish that only says "something went wrong" is almost worse than silence. You know it failed. You do not know whether to retry, fix shipping, fix a policy, or stop and open a ticket.

Publish failures now surface the real provider error instead of a masked generic message. If eBay rejected the listing for a concrete reason, that reason should be in front of you.

That sounds like polish. It is not. Clear failure text is the difference between a two-minute fix and a twenty-minute guess, and it is the only way automation earns the right to keep trying on your behalf.

Fewer emails, more signal

The other half of the problem was volume.

One broken listing could turn into a wall of repeat failure emails. None of them taught you anything new after the first one. They just trained you to ignore the channel.

We stopped that flood pattern. You should get signal when something is actually wrong, not a stack of near-identical messages about the same failure.

What to check this week

If you already have eBay inventory in ListForge:

1. Update ListForge and leave the hourly repair scan alone. It is meant to run without babysitting.
2. Spot-check a few listings that used to feel "off" - Best Offer state, fields that never quite matched eBay, publishes that failed without a real reason.
3. Compare Active and what eBay still has live on a store that used to drift.
4. If a publish fails, read the error. It should now point at something you can act on.

If numbers still disagree after a full inventory sync, tell us the marketplace account, the listing or item id, and a screenshot of both sides. That is how the next drift class gets prioritized.

This week also carries mobile and activation work that is not the hero of this story (native 1.15.0 on the store track, Magic eBay connection resilience, store profile and template gallery). Those matter. They are not why this post exists. This post is about listings that stop silently going wrong.

Try it

If your eBay listings have felt unpredictable, log in, check the listing feed, and let the repair pass do its job.

Update ListForge, run a full inventory sync on the store that used to drift, and compare Active to what eBay still has live. If numbers still disagree, or a publish failure still hides the real reason, tell us at list-forge.ai. We ship those tickets first.