Skip to content

FBM Articles Endpoints

Base path: /api/v1/multi + router prefix /fbm/articles → full base: /api/v1/multi/fbm/articles

Summary: Endpoints to recalculate FBM (Fulfillment-By-Merchant) pricing and profit information. The primary operation recalculates min/max price bounds and profit estimates per marketplace using Sellerlogic and Amazon SP-API helpers.

Auth: Bearer JWT required for all endpoints.

Rate limiting: Subject to global rate limiter (250 requests / 60s).

Primary models referenced: RepricerArticle, FBMDetails, FBMCountryPricing, FBMBoundDetails (models in backend/service_multi-repricer/app/models/repricer_articles.py, Pydantic schemas in schemas/repricer_articles.py).

External services used: calculate_optimal_price_with_api (SP-API helper), get_live_exchange_rates, batch_reprice_items (sellerlogic helper).

Endpoints

  • POST /recalculate/{sku}
  • Path: POST /api/v1/multi/fbm/articles/recalculate/{sku}
  • Path param: sku (string). Use all to recalculate the entire FBM catalog.
  • Description: Starts a background job that recalculates pricing for FBM-backed articles. For each article the background task:
    • Loads RepricerArticle and FBMDetails rows
    • UVP: always profit-only — pins min/max from min_uvp / max_uvp, refreshes profit/margin
    • Penner/renner (article_type): profit-only even with force_min_max; heals targets from pricing_history
    • Wave/manual (use_min_max_rules == False) without force_min_max: profit-only on existing bounds
    • Rules-on, or untyped wave with force_min_max=True (buy-price after type clear): full SP-API via calculate_optimal_price_with_api
    • Updates FBMDetails.international_pricing, status, expected_profit and margin_rule_id
  • Response: 200 — { "message": "Recalculation started in background." }
  • Notes: Emits websocket notifications (type=task_status, source=fbm) at start and finish; commits per-article to reduce locking; reports success and failed SKUs in return payload of the internal task.

Implementation details & behavior

  • The recalculation flow validates presence of brutto_buy_price and package_cost; missing values mark the FBM detail as ERROR.
  • Rules-on (since 1.10.4): every recalc runs full SP-API min/max — no profit-only shortcut when targets already exist.
  • Wave + force_min_max: buy-price / package force (incl. penner/renner) rewrites bounds via SP-API. Nightly main pass does not pass force, so unchanged waves stay profit-only.
  • UVP: always profit-only; never rewritten by force.
  • OOS FBM rows are always skipped (no force override).
  • For price calculations the code:
  • Computes buy_netto (simple DE net assumption: gross/1.19)
  • Looks up a margin rule via get_margin_rule_for_price
  • Calls calculate_optimal_price_with_api with is_fba=False and fbm_shipping_cost set to the article's package cost converted by local exchange rate
  • Applies 0.90 rounding logic and populates FBMCountryPricing entries for each marketplace
  • On calculation or API errors the country entry is populated with an error field and the FBM detail receives status=ERROR.
  • After a successful sync, recalculate, or export, error_message and per-country error keys in international_pricing are cleared (flag_modified ensures JSON column persistence). When seller SKU changes on sync, stale bounds/errors are invalidated and status moves to UPDATE_NEEDED.

Common errors

No ASIN found for SKU: {seller_sku}

Returned by Amazon SP-API getMyFeesEstimatesForSku when the seller SKU cannot be linked to a catalog ASIN. The repricer surfaces this as FBMDetails.error_message and sets status=ERROR; international_pricing entries for affected countries include the same text in their error field.

Typical causes

  • No active FBM listing on Amazon for that seller SKU.
  • seller_sku out of sync with Plenty / Seller Central (run POST …/fbm/articles/sync).
  • Bundle parent SKU synced as seller SKU while Amazon lists a child or alternate variation SKU.
  • Listing removed or never published.
  • SKU with parentheses / special chars (e.g. …(2)): older SP-API client calls used force_safe_sku=True, which percent-encoded the SKU into the FeesEstimate request so Amazon looked up …%282%29 and returned this error even when Seller Central showed an active offer. Fixed in 1.10.4 (force_safe_sku=False).

Resolution

  1. Confirm the SKU in Seller Central and Sellerlogic (must map to an ASIN).
  2. Run FBM Sync All to refresh seller_sku from Plenty variation SKUs (marketId 4.0 = Amazon DE).
  3. Correct seller_sku if the Amazon listing uses a different identifier.
  4. Re-run Recalculate (POST …/fbm/articles/recalculate/{sku} or all).

Implementation: get_spapi_fee_estimate in spapi_client.py stops retries when this message is detected; fbm_articles.py catches SpApiFeeEstimateError and writes error_message.

Examples

  • Trigger a recalculation for a single SKU:
curl -X POST "http://localhost:8000/api/v1/multi/fbm/articles/recalculate/B07SKU123" \
    -H "Authorization: Bearer <TOKEN>"
  • Recalculate all FBM-backed SKUs (may be long-running):
curl -X POST "http://localhost:8000/api/v1/multi/fbm/articles/recalculate/all" \
    -H "Authorization: Bearer <TOKEN>"

Notes & operational guidance

  • Ensure active Amazon credentials are available (service multi-repricer or fallback sellerlogic) — fee-based calculations rely on SP-API estimates.
  • Recalculation is CPU/IO intensive and may call external APIs for many SKUs; schedule during low-traffic windows for large catalogs.
  • WebSocket notifications provide progress updates for the frontend.
  • Endpoint implementation: backend/service_multi-repricer/app/api/v1/endpoints/fbm_articles.py
  • SP-API helper: backend/service_multi-repricer/app/services/amazon/spapi_client.py

Generated: detailed reference for fbm_articles endpoints.