Guidance Required: Rendering Seller-Based Product Prices via App Builder | Community
Skip to main content
A
AkshayBorhade
Level 1
February 16, 2026
Question

Guidance Required: Rendering Seller-Based Product Prices via App Builder

  • February 16, 2026
  • 1 reply
  • 10 views

We are implementing a custom solution in Adobe Commerce using Adobe App Builder and require technical guidance on an architecture/design aspect.

Business Requirement:

  1. Product prices are managed at the seller level (multi-seller marketplace setup).

  2. Price varies depending on the seller.

  3. Seller availability depends on the customer-entered pincode.

  4. Based on the pincode:

    • Only eligible sellers should be considered.

    • The frontend should display the corresponding seller-specific price.

  5. Pricing data originates from the seller backend account.

Clarifications Required:

  1. What is the recommended approach in App Builder to:

    • Fetch seller-specific pricing dynamically?

    • Filter sellers based on pincode before rendering price on the PDP/PLP?

  2. Should this logic be implemented as:

    • A Runtime Action exposed via a custom API?

    • An Event-driven architecture (e.g., reacting to cart/pincode entry events)?

    • A middleware layer between Adobe Commerce and the frontend?

  3. What is the best practice for:

    • Caching strategy (considering pincode-based variability)?

    • Ensuring performance when multiple sellers are mapped to one SKU?

    • Securing seller pricing data exposed through APIs?

  4. Can App Builder directly extend the GraphQL layer of Adobe Commerce for such dynamic pricing use cases, or is a separate endpoint recommended?

We want to ensure the implementation follows Adobe-recommended architecture patterns and remains scalable for high traffic.

Kindly advise on the optimal design approach.

1 reply

AmitVishwakarma
Community Advisor
AmitVishwakarmaCommunity Advisor
Community Advisor
February 18, 2026

Hi ​@AkshayBorhade ,
Use App Builder as a pricing microservice, fronted by API Mesh, and extend Commerce GraphQL.
1. Core pattern:

  • Front end -> API Mesh -> Adobe Commerce + App Builder
    • PDP/PLP calls one GraphQL endpoint (API Mesh) with sku + pincode.
    • Custom Mesh resolver calls an App Builder runtime action (“pricing service”).
    • The action:
      • Looks up eligible sellers for that pincode (from seller backend or a pre‑synced store).
      • Computes/returns seller‑specific prices for that SKU.
      • Mesh merges that into the Commerce GraphQL response (e.g. extra field on product).

This matches Adobe’s recommended out‑of‑process extensibility model: Commerce core stays clean; custom logic lives in App Builder + Mesh.https://experienceleague.adobe.com/en/docs/commerce-learn/tutorials/extensibility/adobe-developer-app-builder/introduction-to-app-builder

https://experienceleague.adobe.com/en/docs/commerce-operations/implementation-playbook/architecture/enterprise-blueprint

 

2. Where to put the logic

So: synchronous action for reads, events/webhooks for feeding data.

3. Caching, performance, and scale

  • Key for cache: (sku, pincode)
  • Where to cache:
    • Inside App Builder (short TTL, e.g. 1–5 min) using state or external cache.
    • Optionally at the CDN for fully public prices if SEO/UX allow (careful with personalized pricing).
  • Pattern from internal “Pricing Engine” examples:
    • Small pricebook‑like schema in App Builder,
    • Bulk load/refresh via CSV or API,
    • Runtime action getProductPrice(sku, pincode) resolving from that store. 

For many sellers per SKU, focus on pre‑aggregation per (sku, pincode) in your store so runtime doesn’t iterate large seller lists per request.

4. Security & data exposure

  • Do NOT expose seller systems directly to the browser.
    • Frontend only talks to Commerce GraphQL (via Mesh).
    • Mesh talks to App Builder; App Builder talks to seller backends with proper auth.
  • Use:
    • API Gateway + OAuth/JWT for seller APIs where possible.
    • Secrets in App Builder for keys/credentials (never in front end).
  • Only expose what’s needed to the browser: e.g. sellerName, price, deliveryEta, not raw seller account data. 

5. GraphQL vs separate endpoint

  • Best practice: extend GraphQL via API Mesh, not a totally separate REST endpoint.
  • Mesh is designed to compose Commerce + external services into one schema
  • A separate endpoint behind App Builder is okay internally (Mesh -> App Builder), but the storefront should hit only the unified GraphQL API.

Build a seller‑aware pricing microservice in App Builder, front it with API Mesh as a custom GraphQL resolver, feed it with events/webhooks if needed, cache by (sku,pincode), and only expose aggregated, secure pricing data back to the PDP/PLP via Commerce GraphQL.

Thanks,
Amit

Terms & ConditionsAccessibility statement

Loading footer...