Strip the envelope
Unwrap each acquisition payload and reduce it to the records the operation actually needs.
One contract, every operation
Integrate once. Every Amazon surface returns the same shape.
Glade turns volatile marketplace pages into one canonical contract across 17 operations and 13 marketplaces, validated before every response.
Before // every source speaks a different language
Product pagebuybox.price.amount
Search pageitems[].price.value
Offer pageoffers[0].price.display
+ 14 more operations · 13 marketplaces
each with its own acquisition shape
each with its own acquisition shape
Glade 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
ProductObject validated
{
"identity": { "asin": "B0D1XD1ZV3" },
"price": {
"value": 79.99,
"currency": "USD"
},
"availability": "in_stock",
"marketplace": "US",
"requestMeta": { "cached": true }
}- • provider fields never cross the boundary
- • unknown values stay explicitly null
- • schema version travels with the response
One integration. 17 operations. 13 marketplaces. The same validated contract on every response.
The problem
Why is Amazon 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 pagebuybox.price.amount
Search pageitems[].price.value
Offer pageoffers[0].price.display
+ 14 more operations, each with its own acquisition details
How it works
How does Glade 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
A declarative map renames provider and page-specific paths into Glade’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, GraphQL, MCP, or Skill boundary.
“Different inputs go in. The same contractual discipline comes out.”
Computed intelligence
What does Glade add on top of the raw data?
When the source provides enough information, deterministic code normalizes price and currency, stock state, placement, sponsorship, ratings, marketplace context, and request metadata. If the source does not know, Glade returns null.
computed fields
{
"computed": {
"price": { "value": 79.99, "currency": "USD" },
"isInStock": true,
"placement": 3,
"sponsored": false
}
}These are deterministic transformations, not machine learning. A source can resolve a confident field, or Glade 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, GraphQL, 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 Amazon object Glade returns—not only products. Build typed consumers once and reuse the conventions everywhere.
ProductObjectVariantObjectOfferObjectReviewObjectSellerObjectAuthorObjectCategoryObjectSearchResultObjectBestSellerObjectEstimateObjectRequestMeta
One contract vocabulary spans products, discovery, commerce, reviews, sellers, categories, estimates, and request context.
See the full schema referenceThe shape of it
One schema, holding across everything Glade returns.
13
marketplaces
17
operations
11
canonical objects
1
schema
One key, one model
Normalize once, or remap every source yourself.
Glade replaces a collection of provider-shaped integrations with one public Amazon data contract.
Integration
Glade: One key and one public contract
Self-managed: Provider keys and contracts per source
Field naming
Glade: Stable Amazon-domain fields
Self-managed: Different paths for pages and providers
Marketplace context
Glade: Domain, locale, and currency included
Self-managed: Reconstructed inside every integration
Missing values
Glade: Documented nullable fields
Self-managed: Silent omissions and provider sentinels
Documentation
Glade: 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. Product, search, seller, review, category, and estimate operations return purpose-built canonical objects. They share the same naming discipline, request metadata, marketplace context, error model, and validation boundary.
How does Glade prevent acquisition fields from leaking into the API?
Raw page and provider payloads are private implementation details. Glade maps them into provider-neutral contracts and validates the completed object before returning it.
What happens when Amazon does not expose a field?
Glade returns a documented optional or null value. It does not invent data or pass through provider-specific placeholder strings.
Do REST, GraphQL, 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 canonical types and operation catalog generate validation, API references, interface metadata, and examples. A contract change updates the public surfaces together.
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 Amazon operation and inspect the validated contract you can reuse across products, search, offers, reviews, sellers, categories, and estimates.
cURL
curl "https://gladeapi.com/api/amazon/product?asin=B0D1XD1ZV3&domain=US" \
-H "API-KEY: glade_live_YOUR_API_KEY"