Amazon SP-API & Flipkart Seller API: A Practical Integration Guide

This guide has two readers in mind. If you are a developer, you want enough concrete detail on Amazon's Selling Partner API and Flipkart's Seller API to scope real work: auth, rate limits, the shape of the JSON. If you are a founder or seller, you want to understand what integration actually involves so you can decide, with open eyes, whether to build it in-house or hire it out. We will serve both, and Flipkart gets real coverage because honest documentation for it is genuinely scarce.

What SP-API is (and what it replaced)

Amazon's Selling Partner API (SP-API) is the current programmatic gateway for sellers and vendors. It replaced the old Marketplace Web Service (MWS); if you find a tutorial referencing MWS, it is obsolete. SP-API is a set of REST endpoints returning JSON, organised into resource groups: Orders, Listings Items, FBA Inventory, Feeds, Reports, Catalog Items, Finances, and more. You almost never need all of them; a typical seller integration touches Orders (pull new orders), Listings and FBA Inventory (push stock and price), and Reports or Feeds (bulk operations).

The auth model is the first real hurdle

SP-API uses Login with Amazon (LWA) OAuth 2.0. The flow, in plain terms:

• You register a developer profile and an application in Seller Central / the developer console.
• A selling account authorises your app, which yields a refresh token.
• Your backend exchanges that refresh token for short-lived access tokens on each run.
• Requests carry the access token; Amazon dropped the older AWS Signature (SigV4/IAM role) requirement for most calls, simplifying what used to be a painful step.

One nuance that trips teams up: restricted roles and PII. Endpoints that expose customer personal data (buyer name, shipping address) require your application to be approved for restricted data access, and you must handle that data according to Amazon's data protection policy. Plan for the approval step; it is not instant.

Rate limits: the token-bucket reality

SP-API throttles using a token-bucket model. Each endpoint has a restore rate (tokens added per second) and a burst (maximum bucket size). You can spend bursts quickly, then you are limited to the steady restore rate. The response headers tell you your remaining quota, and a 429 means back off. Any serious integration needs a rate-aware queue with exponential backoff, not naive loops. For bulk work, do not hammer per-item endpoints; use the Feeds API to submit large updates and the Reports API to pull large datasets asynchronously, both of which are designed for volume and sidestep per-call limits.

Flipkart Seller API: the sparsely documented half

Flipkart exposes a Seller API (v3.0) for marketplace sellers, and it is where public knowledge thins out. The essentials:

• Auth: OAuth 2.0. You obtain an application id and secret from the Flipkart seller developer portal, then acquire access tokens (self-authorized for your own account, or the authorization-code flow for serving other sellers).
• Core areas: order management (fetch new orders, acknowledge, dispatch), shipment and label generation, returns, listings and inventory updates, and pricing.
• Identifiers: Flipkart uses the FSN (Flipkart Serial Number) for catalogue items and its own order and shipment ids; your integration must map these to your internal SKUs, exactly the mapping problem multichannel sellers know well.
• Workflow shape: Flipkart's order lifecycle is more prescriptive than Amazon's. You typically acknowledge orders, then move them through packing, label generation and dispatch states via the API, rather than just reading and fulfilling freely.

The practical takeaway: Flipkart's API is capable but less forgiving and less documented, so expect more time reading the portal's reference and testing against a sandbox than you would for Amazon. Budget accordingly.

Where a solo seller hits the wall

Reading the above, a developer thinks "fine, a few weeks of work". A non-technical founder should notice how many moving parts there are: two different OAuth flows, two identifier schemes, two throttling behaviours, restricted-data approvals, async feeds and reports, and webhook or polling infrastructure to keep it all live. Building it once is a project. Keeping it running as both marketplaces version their APIs, deprecate endpoints and change policies is an ongoing commitment. That maintenance tail is what surprises people who scoped only the first build.

Build vs buy, for real this time

Build in-house when

You have engineering capacity, your logic is genuinely custom (unusual pricing rules, a bespoke ERP, workflows no off-the-shelf tool models), and you are prepared to own maintenance. Directly integrating gives you maximum control and no per-order middleman fees. If that is you, the developer detail above is your starting map.

Hire it out or buy a connector when

You want the outcome (orders flowing in, stock and prices flowing out, labels generated) without staffing an API team, or you need it live in weeks not quarters. A custom-built integration delivered for you, or a maintained connector, means someone else absorbs the OAuth quirks, the throttling and the version churn. For most sellers whose competitive edge is their product and merchandising, not their API plumbing, this is the rational choice.

Getting orders in: webhooks, notifications and polling

Both marketplaces let you learn about new orders in more than one way, and picking the right one shapes your architecture. Amazon offers Notifications (via EventBridge or SQS) so you can be told when an order is created rather than polling the Orders API on a timer; that is the scalable choice at volume. Flipkart leans more on you fetching orders in the acknowledged state. Whatever the source, the discipline is the same: ingest the event, write it to your own store immediately, then process asynchronously so a slow downstream step never causes you to lose an order notification. Building this as a resilient queue rather than a straight-through script is the difference between an integration that survives a traffic spike and one that drops orders during your biggest sale.

Testing is where the time actually goes

Developers consistently underestimate the test phase. Amazon provides a sandbox for SP-API, but sandbox responses do not perfectly mirror production data, so you will still find surprises when real orders arrive: unusual address formats, gift options, multi-item shipments, marketplace-specific tax fields. Flipkart's sandbox coverage is thinner still. Plan for a shadow period where the integration runs read-only against live data and you compare its output to what your team does manually, before you let it write anything back. The teams that skip this are the ones that ship a bug straight into their live catalogue.

A note on FBA, Flipkart Fulfilment and self-ship

Inventory is not one concept across fulfilment models. Stock sitting in Amazon's FBA warehouses is tracked by the FBA Inventory API and is not the same pool as your self-shipped stock; likewise Flipkart's fulfilment options hold inventory you cannot freely double-count. If you mix fulfilment models, your master has to treat FBA stock, Flipkart-warehoused stock and your own warehouse as separate pools that map to the same product but cannot be sold from interchangeably. Getting this wrong is a classic source of phantom availability, and it is invisible until an order cannot be fulfilled.

If you do build: a sane order of work

Start with read-only Orders on one marketplace to prove auth and parsing. Add inventory and price writes next. Introduce a rate-aware queue before you scale volume. Move bulk operations to Feeds and Reports. Only then add the second marketplace, reusing your queue and mapping layer. Treating both marketplaces as plugins behind one internal model, rather than two bespoke codebases, is what keeps the project maintainable. The same discipline underpins our custom webhooks and API automation work.

Listings and pricing: the endpoints that touch revenue

Reading orders is low-risk; writing listings and prices is where a bug becomes expensive. On SP-API, the Listings Items API lets you update price and quantity per SKU, and a fat-fingered feed that drops a zero or resets a price is live to buyers within minutes. Flipkart's pricing and inventory endpoints carry the same danger. Two safeguards belong in any serious build: a validation layer that rejects implausible values (a price 90 percent below normal, a negative quantity) before they are sent, and an audit log of every write so you can trace and reverse a bad update. Marketplaces will happily broadcast your mistake at scale, so the guardrails matter as much as the endpoints.

Budgeting the real timeline

For a founder scoping this, a rough shape helps. A read-only single-marketplace order sync is a couple of weeks for a competent developer. Add reliable inventory and price writes with validation, and you are into the next month. A second marketplace, done properly behind a shared model, is less than the first but not free. Then add the perpetual maintenance: API version migrations, deprecations, new policy requirements, and the occasional outage to handle gracefully. Sellers who budget only for the first build and forget the maintenance tail are the ones who end up with a half-working integration that nobody has time to fix. Whichever path you choose, price in the upkeep, not just the launch.

Whether you build or buy, the endpoints are only half the story; the durable value is in the plumbing around them. Explore our Amazon SP-API integration and Flipkart Seller API integration to see a maintained approach, or talk to our team if you would rather hand the plumbing to someone who has already solved it.