Amazon Selling Partner API Integration Challenge

The Problem: On Amazon, the delivery promise a customer sees — “Get it by Tuesday” — is among the strongest drivers of conversion. It is not one national number. It varies by pincode, and follows directly from three things Plantex already controls: where stock sits, how much sits there, and order cutoffs. Plantex already plans stock placement against demand clusters and runs the rebalancing engine that acts on those plans. This project closes the loop — measuring the delivery promise those placement decisions actually produce, at pincode granularity, continuously. A working internal prototype already does the hard part: it queries the Selling Partner API (getFulfillmentPreview) for an estimated arrival date for a given SKU to a given pincode, and assembles a SKU x pincode matrix. Your job is to take it from a script to a system. Project Scope: In Scope: Collection: Automated, scheduled, resumable gathering of delivery-promise data via the Amazon SP-API. Storage: A queryable store that holds history, so the same SKU x pincode is comparable week over week. Analytics: Promise by cluster, SKU and category; trend detection; root-cause separation. Interface: A dashboard, or a clean Power BI dataset, readable by a supply chain manager in seconds. Calibration: A method for quantifying the gap between the API-reported promise and the live storefront promise. Alerting: Notification when a cluster degrades materially. Out of Scope: No web scraping. No storefront scraping of amazon.in, flipkart.com or any marketplace — no HTTP scraping, headless browsers, proxy or VPN rotation, no third-party scraped datasets. A first-party API exists that returns structured, authoritative data with no blocking and no account risk; reaching for a scraper instead is a poor engineering judgement and is scored as one. Any submission containing scraping code or scraped data is disqualified before scoring begins. Also out of scope: competitor pricing or catalogue data; any write operation against Amazon (the system is strictly read-only); customer personal data; mobile applications. Working Environment: Teams build against the SP-API sandbox plus a supplied set of several thousand real, anonymised API responses served by a local mock server. Production credentials are never issued externally; shortlisted submissions are validated against the live account by Plantex engineers, with the team present. Deliverables: Four tracks. Tracks A and B are mandatory to qualify. C and D separate a strong submission from an adequate one. Track A — Collection Engine (Mandatory): Scheduled, unattended execution at a configurable cadence. Client-side throttling to the published limit (2 req/s, burst 30) with exponential backoff on HTTP 429. Idempotent and resumable — an interrupted sweep continues without duplicating work. Structured logging and a per-run summary: calls, successes, failures, throttle events. Classified handling of every documented failure mode, including DeliverySLAUnavailable, ItemQuantityNotAvailable and HTTP 403. Credentials from environment or a secret store, never from source. Track B — Data Model and Storage (Mandatory): A schema supporting the time-series question: the same SKU x pincode measured weekly over months. A justified storage choice — PostgreSQL, SQLite, DuckDB or Parquet all acceptable; the reasoning earns the marks. Ingestion that is safe to re-run, plus a documented query interface for downstream consumers. Track C — Analytics and Interface: SKU x cluster promise matrix with clear visual banding, and week-on-week trend per cluster. Root-cause split — unfulfillable (stock placement) versus slow (transit), each quantified. A join against FC stock position showing which SKUs are misplaced relative to demand. Delivered as a web dashboard or a clean Power BI dataset with a sample report; both count equally. Track D — Calibration and Alerting: A reproducible method for measuring the offset between the API-reported promise and what a real customer sees, applied per cluster. A statistically defensible alerting rule separating genuine degradation from noise — state the false-positive rate it implies. Notification delivery by email or webhook.