Refining Affiliate.com API Results with Merchant and Network Filters

Merchant and network filters are control fields that narrow Affiliate.com API results by the source of the product record. A merchant is the retailer selling the product, while a network is the affiliate network through which the merchant program is connected.

For existing API users, these filters are not merely cleanup tools. They are retrieval rules. Affiliate.com aggregates normalized product data across more than 30 networks, tens of thousands of merchant programs, and over a billion products, so source control matters when a query can return a very large result set.

Why merchant and network filters matter

A broad query is useful for exploration. A governed query is useful in production.

Consider a product team building a deal module for running shoes. The first query may start with the any field because the team wants wide discovery across names, descriptions, brands, and categories. But once the team knows the merchandising strategy, the query should become sharper: brand, price, discount, availability, merchant, and network filters should all work together.

Affiliate.com supports network name, Network ID, merchant name, and Merchant ID as source fields, which lets teams decide where product results should come from before those results reach a page, app, newsletter, or internal review queue.

Search intent: merchant filters versus network filters

Use merchant filters when the retailer matters

Merchant filters are best when the retail source is part of the user experience.

A commerce editor may want to build a product set around a trusted retailer. A product manager may want only merchants already approved for a given experience. A data team may want to test whether a single merchant feed is producing the expected product depth.

Use merchant filters when you need to:

1. Limit results to named retailers.
2. Build around a known merchant mix.
3. Review product coverage for a specific merchant.
4. Keep a page aligned with a retail strategy.
5. Compare identical products only within a selected merchant group.

Affiliate.com’s prior guidance notes that merchant filtering can be done by merchant name or Merchant ID, and is useful when teams know which retailers they want to feature.

Use network filters when the source system matters

Network filters are better when the question is operational.

A team may want to preview products from one network at a time, isolate results from selected network IDs, or keep a query limited to the networks that matter for a specific workflow. Network filters are especially useful when the team is validating source coverage or preparing a controlled product selection.

Use network filters when you need to:

1. Limit retrieval to selected networks.
2. Compare coverage across network sources.
3. Troubleshoot why products appear or disappear.
4. Build a controlled dataset for review.
5. Reduce noise before applying more granular filters.

The main distinction is simple. Merchant filters answer, “Which retailers should appear?” Network filters answer, “Which source channels should the query include?”

A practical workflow for cleaner API results

Start broad only long enough to learn. Then layer filters until the query reflects the actual business rule.

Example: regional sale page for wireless headphones

Begin with discovery:

1. Any contains “wireless headphones”
2. Currency equals USD
3. In Stock equals true
4. On Sale equals true

Now add source control:

1. Network ID equals the selected network group.
2. Merchant ID equals the approved retailer list.
3. Brand equals Sony, Bose, JBL, or Beats.
4. Final Price is less than the target ceiling.
5. Sale Discount is greater than the minimum threshold.
6. Deduplication is on for a clean discovery list.

This gives the team a sharper set of products without relying on product titles alone. If the experience shifts from discovery to offer comparison, turn deduplication off so users can see multiple merchant offers for the same item.

Affiliate.com’s product data includes fields for brand, pricing, discounts, currency, availability, merchant context, network context, and identifiers such as barcode, SKU, UPC, GTIN, and MPN, which makes this type of layered query practical rather than theoretical.

Where identifiers fit into source filtering

Merchant and network filters decide where a product record comes from. Identifiers help decide what the product actually is.

That distinction matters. A merchant filtered query can still contain lookalikes. A barcode matched query can verify when separate merchant records refer to the same physical product, even when titles differ.

For exact match workflows, use barcode when the goal is to compare the same product across merchants. Use MPN or SKU when the goal is a model specific or merchant specific search. Affiliate.com’s knowledge base describes barcode, UPC, EAN, GTIN, and ISBN as identifiers that help verify when two listings from different networks refer to the same product.

Deduplication decision rule

Deduplication controls whether identical product offers are grouped into one result or returned as separate listings.

Use deduplication on when the user needs a clean product list. This is usually the right choice for category pages, curated collections, and product discovery modules.

Use deduplication off when the user needs offer level comparison. This is usually better for price comparison, merchant choice, and workflows where the same product should show multiple buying options.

Affiliate.com’s prior guidance frames the decision clearly: deduplication can reduce repeated listings for clean browsing, while leaving it off gives teams flexibility to compare merchant offers.

Checklist before saving or sharing a query

Before moving a merchant or network filtered query into production, review the logic in the Query Builder.

1. Are merchant filters using Merchant ID when precision matters?
2. Are network filters scoped to the intended source group?
3. Does the query use brand, barcode, MPN, SKU, or ASIN where identity matters?
4. Are final price, regular price, sale price, and discount fields used for the right ranking logic?
5. Is currency scoped for the intended market?
6. Is availability or in stock included when unavailable products should be excluded?
7. Is deduplication set for discovery or comparison?
8. Has the result set been checked in the live UI before publishing?

The Query Builder is useful here because it lets product, editorial, and data teams test API requests without turning every refinement into an engineering ticket. Affiliate.com describes the Query Builder as a way to create, refine, and save Product API queries, with configurable merchant, network, price, availability, discount, barcode, and related parameters.

The operating principle

Merchant and network filters are not afterthoughts. They are part of the query architecture.

Start with intent. Decide which merchants and networks are eligible. Add product identity fields when exact matching matters. Layer pricing, discount, currency, stock, and attributes. Then choose deduplication based on whether the experience is meant for discovery or comparison.

Open Affiliate.com’s Query Builder, test the same query with and without merchant and network filters, then inspect how the result set changes. That exercise usually reveals the hidden rule every production query needs: not just what to retrieve, but what to exclude.