Why "USED" Condition Fails in eBay Inventory API (Action Figure Category)

Snowball — Sat, 19 Jul 2025 04:59:53 +0000

Background

In the Action Figure category on eBay, the listing UI only provides two condition options:

NEW and USED.

However, when creating a SKU using the eBay Inventory API, specifying "USED" directly causes an error.

Root Cause

According to eBay's API specification, the enum value "USED" does not exist.

UI Label → "USED"
API Expected Value → "USED_EXCELLENT" (Condition ID: 3000)

So, to reproduce the UI’s “USED” condition in the API, you need to use "USED_EXCELLENT" instead.

References

❌ Example: Fails with `"USED"`

curl -X PUT 'https://api.ebay.com/sell/inventory/v1/inventory_item/test-sku-001' \
  -H "Authorization: Bearer DUMMY_ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "condition": "USED",
    "product": {
      "title": "Dummy Action Figure",
      "description": "Dummy description for an action figure item.",
      "imageUrls": ["https://dummyurl.com/dummy-image.jpg"]
    },
    "availability": {
      "shipToLocationAvailability": {
        "quantity": 1
      }
    }
  }'
\```
{% endraw %}



### Error Response

\
{% raw %}
```json
{
  "errors": [
    {
      "message": "Could not serialize field [condition]"
    }
  ]
}
\```
{% endraw %}


## ✅ Example: Success with {% raw %}`"USED_EXCELLENT"`

\
{% raw %}
```bash
curl -X PUT 'https://api.ebay.com/sell/inventory/v1/inventory_item/test-sku-001' \
  -H "Authorization: Bearer DUMMY_ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "condition": "USED_EXCELLENT",
    "product": {
      "title": "Dummy Action Figure",
      "description": "Dummy description for an action figure item.",
      "imageUrls": ["https://dummyurl.com/dummy-image.jpg"]
    },
    "availability": {
      "shipToLocationAvailability": {
        "quantity": 1
      }
    }
  }'
\```
{% endraw %}


Now the **USED** listing works correctly via API.

## Summary

- In the Action Figure category (and similar), the **UI only shows "New" and "Used"**, but...
- The eBay Inventory API **does not accept {% raw %}`"USED"`{% endraw %}**.
- Instead, use {% raw %}`"USED_EXCELLENT"`{% endraw %} (Condition ID {% raw %}`3000`{% endraw %}) when listing as used.
- Therefore:
  - New item → {% raw %}`"condition": "NEW"`{% endraw %}
  - Used item → {% raw %}`"condition": "USED_EXCELLENT"`{% endraw %}
- This mismatch stems from eBay’s internal {% raw %}`ConditionEnum`{% endraw %} design and is **not clearly documented**, making it a common source of confusion for developers.

Why PDCA Often Fails — And How GP-PDCA Can Fix It

Snowball — Sat, 19 Jul 2025 04:56:09 +0000

Introduction

Have you ever followed the PDCA cycle (Plan-Do-Check-Act) and still ended up with no tangible results?

You’re not alone.

The truth is: PDCA is a powerful framework — but only when used in the right context, with the right starting point.

Too often, people jump into the "Do" phase without clarifying what they're really trying to achieve or solve.

That’s where my original framework GP-PDCA comes in.

What's Wrong with PDCA?

PDCA is popular because it provides a simple loop for continuous improvement.

However, many teams run into the following issues:

❓ Unclear what the real problem is
🎯 No alignment with the ultimate goal
🌀 Endless cycles of "doing something" without meaningful impact
📉 False sense of progress

The root cause: PDCA assumes the problem and goal are already clear — which is rarely the case in the real world.

Introducing: GP-PDCA

To make PDCA effective, you need two steps before Plan:

Goal and Problem.

🥅 Goal

What are we really trying to achieve?
What is the ideal future state?
Why does it matter — and to whom?

🔍 Problem

What’s preventing us from reaching the goal?
What are the bottlenecks or pain points?
What is the root cause?

Then finally: the original PDCA loop

Plan: Hypothesize and design solutions
Do: Execute a small-scale trial
Check: Measure and evaluate
Act: Standardize or iterate

GP-PDCA Flow

G (Goal) → Define your ideal target or outcome (KGI)
P (Problem) → Identify obstacles or root causes
P (Plan) → Create hypotheses and KPIs
D (Do) → Take action
C (Check) → Evaluate performance
A (Act) → Reflect, standardize, or retry

Real-World Example: Improving a Dev Team's Output

Goal: Double the team’s release frequency
Problem: PR reviews are slow, test automation is lacking, rework is frequent
Plan: Improve CI pipeline, enforce WIP limits, clarify review guidelines
Do: Pilot these changes for 1 sprint
Check: Measure PR turnaround time, number of weekly releases
Act: Adopt successful practices across the team

Why “G → P” Before PDCA Is So Powerful

Starting with Problem is better than jumping into “Do”.

But starting with Goal is even better.

Without a clear goal, you're just solving problems — not driving toward anything meaningful.

GP-PDCA forces you to answer:

“Where are we going?”
“Why does it matter?”
“What’s standing in our way?”

Only then is it worth asking, “What should we do?”

Summary

PDCA is not broken — but it’s incomplete when used in isolation.

The GP-PDCA model adds two crucial layers: purpose and problem clarity.

This simple mental model has helped me dramatically improve how I approach product development, team processes, and even personal projects.

Final Thoughts

If PDCA has ever felt like busywork or a corporate ritual, you're not alone.

GP-PDCA gives it teeth again — by anchoring it to purpose and clarity.

If this model resonates with you, feel free to comment or share your own use cases.

Let’s upgrade our thinking — one cycle at a time.

Written by [Your Name]

Inspired by real-world frustration with shallow PDCA loops.

DEV Community: Snowball