Strip the envelope
Unwrap each acquisition payload and reduce it to the records the operation actually needs.
One contract, every operation
Integrate once. Every eBay surface returns the same shape.
SoldFetch turns volatile marketplace pages into one canonical contract across 3 data operations and supported eBay sites, validated before every response.
Before // every source speaks a different language
Product pageitem.price.value
Search pageitems[].price.value
Category pageresults[].price.value
+ 14 more operations · supported eBay sites
each with its own acquisition shape
each with its own acquisition shape
SoldFetch normalization engine
1Strip the envelope
2Field map
3Add marketplace context
4Normalize + null backstop
5Validate the contract
validated on every responsedocs cannot drift
After // one canonical shape, every operation
ItemDetails validated
{
"itemId": "377534750427",
"price": "79.99",
"currency": "USD",
"condition": "Used",
"ended": true
}- • provider fields never cross the boundary
- • unknown values stay explicitly null
- • schema version travels with the response
One integration. 3 data operations. supported eBay sites. The same validated contract on every response.
The problem
Why is eBay data so hard to work with?
Product, search, offer, and review pages expose the same ideas through different paths. Add locale, currency, marketplace, page drift, and missing fields, and one integration quickly becomes a stack of special cases.
Product pageitem.price.value
Search pageitems[].price.value
Category pageresults[].price.value
+ 14 more operations, each with its own acquisition details
How it works
How does SoldFetch normalize every operation into one public shape?
Every raw record passes through the same five-stage boundary. Nothing undeclared crosses into the public API.
Field map
An explicit mapping renames provider and page-specific paths into SoldFetch’s canonical fields.
Add marketplace context
Attach the domain, locale, currency, and request identity that make the record usable.
Normalize + null backstop
Coerce stable types, normalize enums, and return documented nulls when a source is silent.
Validate the contract
Check the completed object before it crosses the REST, MCP, or Skill boundary.
“Different inputs go in. The same contractual discipline comes out.”
Computed intelligence
What does SoldFetch add on top of the raw data?
When the source provides enough information, deterministic code normalizes price, currency, shipping cost, item identity, and observation timestamps. If the source does not know, SoldFetch returns null.
computed fields
{
"soldPrice": "79.99",
"shippingPrice": null,
"totalPrice": null,
"quality": {
"priceBasis": "displayed_listing_price",
"acceptedOfferAmount": null,
"saleDateVerified": false
}
}These are deterministic transformations, not machine learning. A source can resolve a confident field, or SoldFetch returns a documented null—never a convenient guess.
Models reason; contracts compute.
The proprietary edge
How do you keep the schema and the docs from drifting apart?
One canonical schema is the source of truth for every operation and every interface. Change it once, and each public surface updates from the same definition.
One source of truth
Canonical types and the operation catalog define every supported field exactly once.
Mechanical cascade
A field change flows through runtime validation, examples, OpenAPI, REST, MCP, and the Skill.
Validated on every response
The completed object passes its contract gate before it is returned as a successful response.
Provider fields rejected
Undeclared source fields stay behind the boundary instead of becoming accidental public API.
“The documentation cannot drift from the implementation, because both derive from the same source.”
One schema, every object
Does the unified schema cover more than product details?
The same discipline extends across every eBay object SoldFetch returns—not only products. Build typed consumers once and reuse the conventions everywhere.
ItemDetailsSoldListingActiveListingSearchPageQuality
One contract vocabulary spans item details, sold and active listings, categories, and request context.
See the full schema referenceThe shape of it
One schema, holding across everything SoldFetch returns.
3
marketplaces
3
operations
5
canonical objects
1
schema
One key, one model
Normalize once, or remap every source yourself.
SoldFetch replaces a collection of provider-shaped integrations with one public eBay data contract.
Integration
SoldFetch: One key and one public contract
Self-managed: Provider keys and contracts per source
Field naming
SoldFetch: Stable eBay-domain fields
Self-managed: Different paths for pages and providers
Marketplace context
SoldFetch: Domain, locale, and currency included
Self-managed: Reconstructed inside every integration
Missing values
SoldFetch: Documented nullable fields
Self-managed: Silent omissions and provider sentinels
Documentation
SoldFetch: Generated from the runtime contract
Self-managed: Hand-maintained beside the implementation
Frequently asked questions
Unified schema questions.
Can’t find what you’re looking for? Talk to our team.
Does every operation return the exact same object?
No. Item lookup and search operations return purpose-built canonical objects. They share the same naming discipline, request metadata, marketplace context, error model, and validation boundary.
How does SoldFetch prevent acquisition fields from leaking into the API?
Raw page and provider payloads are private implementation details. SoldFetch maps them into provider-neutral contracts and validates the completed object before returning it.
What happens when eBay does not expose a field?
SoldFetch returns a documented optional or null value. It does not invent data or pass through provider-specific placeholder strings.
Do REST, MCP, and the agent Skill use the same schema?
Yes. Each interface resolves through the same operation catalog and canonical objects, so changing transport does not require remapping your data model.
How do the documentation and runtime stay aligned?
The input schema and operation catalog define supported parameters. Contract tests check the provider mapping and public examples are reviewed alongside changes.
Can the schema evolve without breaking my integration?
Additive changes can arrive within the current version. Breaking changes require an explicit version boundary rather than silently changing an existing field.
One integration
Start free.
Call one eBay operation and inspect the validated contract you can reuse across item details, keyword searches, and category searches.
cURL
curl "https://soldfetch.com/v1/item/377534750427?ebaySite=ebay.com" \
-H "API-KEY: soldfetch_live_YOUR_API_KEY"