Authentication patterns

Every credential model across the 221 connector platforms, grouped by flow, with token lifetimes, multi-account storage and a credential store schema.

Across the 221 platforms in this section there are eight credential models and one very large residual group with no programmatic credential at all. This page groups every platform by the model it actually uses, so a credential store and a refresh job can be designed once rather than per connector. Each platform's own page has the exact endpoint, header and request body; this page is the map.

The single most important number here: 88 of 221 platforms publish no credential model at all. Any plan that assumes a key per channel is wrong for roughly 40 per cent of this list.

The eight models at a glance

Some platforms appear twice because they genuinely support two models. Where that happens the platform page says which one to prefer.

OAuth 2.0, authorization code

The seller (or merchant, or store owner) grants your application access once. You receive a refresh token that is long lived, and exchange it for short lived access tokens. This is the only model that scales cleanly to many seller accounts, because the refresh token is per seller and the application credentials are shared.

Platforms: Amazon, Amazon MCF, Shopify, Shopify POS, BigCommerce (for apps), Etsy, eBay (user tokens), Lazada, Daraz, Wish, TikTok Shop (combined with signing), Xero, QuickBooks, Zoho Books, Sage, Eshopbox, StoreHippo, Mystore, GoFynd, Optiply (password grant), SmartConnect (password grant), Oracle (as an alternative to basic), iThink Logistics, Trackon, Tekipost, Vamaship, Zipypost, Shipsy, Logic ERP, Bizom, Paytm, Delhivery, ERPNext, and the Shopify backed stores My Baby Babbles, NatureFit, OneGuardian, PopClub and Verifast.

Token lifetimes vary widely and are the main operational trap:

  • Amazon LWA access tokens last 3600 seconds; the refresh token does not expire but is revoked if the seller uninstalls.
  • Shopify offline tokens do not expire; online tokens expire with the user session. A store owner uninstalling is the only revocation signal, delivered by webhook.
  • Etsy refresh tokens expire after 90 days of non use, so an idle shop silently falls out of sync. Refresh on a schedule, not only on demand.
  • Odoo 19 caps API key lifetime at three months, which makes quarterly rotation mandatory rather than optional.
Warning

Store the refresh token, never only the access token. A process that holds an access token in memory and restarts loses the connection for that seller until a human re-authorises. This is the most common cause of a channel going dark.

OAuth 2.0, client credentials

Your application authenticates as itself. There is no per seller grant, so the seller identity travels as a separate field: a seller id, a supplier id, an account number or a tenant header. Tokens are short lived and cheap to mint.

Platforms: FedEx, UPS, DHL (MyDHL), Walmart, Flipkart, eBay (application tokens), SAP, Microsoft Dynamics, Salesforce Commerce, Wix, Talabat, Acko, Shadowfax, Elastic Run, GoFynd, FyndTMS and QueueBuster.

noon is a variant worth calling out: you sign an RS256 JWT with a downloaded service account key and exchange that for an access token. The private key, not a secret string, is the credential, so it belongs in a key store rather than a secrets table.

OAuth 1.0a

Three platforms still sign every request rather than carrying a bearer token: Magento (HMAC-SHA256 for integrations), NetSuite (token based authentication, HMAC-SHA256) and WooCommerce (HMAC-SHA1, only over plain HTTP; over HTTPS it uses basic auth instead).

There is no token to refresh, but the signature base string is unforgiving about parameter ordering and encoding. Use the platform's own SDK where one exists.

HMAC request signing with an app secret

No token at all. Every call carries an app key and a signature computed over the request parameters with the app secret. The seller is identified by a separate field, often a shop id or cipher.

Platforms: Shopee, Lazada, Daraz, TikTok Shop, Temu, Shyplite, Paytm, Myntra, Meesho, Nykaa, AJIO, JioMart, PharmEasy, Ecom Express and FShip.

The operational advantage is that nothing expires. The disadvantage is that clock skew breaks everything: most of these reject a timestamp more than a few minutes from their own. Keep the host clock synchronised and treat signature failures as a clock problem first.

Static API key or token

One long lived secret in a header. Simple, and the most common model among carriers.

Platforms: Delhivery (Authorization: Token), RapidShyp, Blowhorn, DocPharma, Ginesys POS, ShipFast, Shiperfecto, Shipmozo, eShipz, OpenLeaf, FarEye, Best Buy (Mirakl shop key), DHL (tracking), DHL Supply Chain, ShopClues, ERPNext, Snapdeal, Shoptimize, Prozo, Ekart, ClickPost and Bhejoo.

Note

Four platforms put the key in the JSON request body rather than a header: ShipEase, iThink Logistics, Pickrr and Trackon. This matters because a body field is logged by default in most HTTP client middleware, so these keys leak into application logs unless you redact them explicitly.

Credentials exchanged for a JWT or session token

The largest model with an actual credential: 44 platforms. You post a username and password to a login endpoint and receive a bearer token with a short life. It is effectively a password grant without the OAuth wrapper.

Platforms: Shiprocket and Shiprocket fulfilment, Blue Dart, XpressBees, Zippyy, SharkShip, Shipyaari, NimbusPost, Daakit, UrbaneBolt, LogiNext, Go Swift, Blitz, Proship, PurpleDrone, Loadshare, ShipDelight, Logistiex, Pidge, Tekipost, Truxcargo, Selloship, Pico Xpress, OpenCart, Focus 9, WonderSoft, Bizom, Swiggy Instamart, Zepto, Odoo, Aramex, Caper India, DTDC and Shipmaxx.

Token lifetimes in this group are short and rarely documented. Measured examples from the platform pages: NimbusPost 3 hours, Zippyy 5 minutes, QueueBuster 24 hours, FyndTMS 10800 seconds. Treat an undocumented lifetime as 15 minutes and refresh on 401 rather than on a timer.

Warning

This model stores a reusable account password, not a scoped token. If the same credential also signs in to the seller panel, a leak gives full account control including bank detail changes. Keep these in a separate, more tightly controlled store than API keys, and ask the vendor for a service account wherever possible.

HTTP basic auth

EasyPost, ShipStation (v1), Shipway, Trendyol, WooCommerce (over HTTPS), Commerce7, Logic ERP, Logic POS, BUSY, Knot, EasyNxt, kindlife, Oracle (Fusion) and SAP (communication user).

Credentials repeated in the request body

A pattern almost unique to Indian marketplaces and carriers: there is no token endpoint, and the username and password travel in every request.

Ecom Express, Caper India, Aramex (a ClientInfo object), Nykaa, JioMart, AJIO, PharmEasy, Myntra, Meesho, Pikndel and Shippigo.

Redact these request bodies in logs. They contain the account password.

None, panel only, or not published

88 platforms. These divide into three practically different cases, and the distinction decides what you build:

  1. Vendor purchase order models. The platform owns the catalogue and buys from you. There is no listing or stock to push. Integration is a purchase order arriving by email, portal download or SFTP, and a goods receipt note coming back. FirstCry, BigBasket, Tata 1mg, Blinkit, Zepto, Swiggy Instamart, DealShare and Elastic Run.
  2. Seller panel only. A human logs in and exports CSV, or an aggregator holds panel credentials on your behalf. Limeroad, Pepperfry, Udaan, Kirana Club and most of the smaller Indian marketplaces.
  3. Dead, dormant or unidentifiable. No credential because there is no platform. See the Gaps section of each page; these are listed in the overview by confidence.

For cases 1 and 2 the integration is a document pipeline and a human relationship, not a connector. Budget for that explicitly rather than discovering it late.

Storing credentials for many seller accounts

One table serves every model above. The important property is that the secret columns are encrypted at rest with a key that is not in the same database, and that credential_type drives which columns are populated.

Three fields exist because of specific platforms. region is required because Zoho Books, Amazon and Salesforce Commerce all resolve to different hosts per region and a credential is not portable between them. scopes is required because Wish grants 37 separate scopes and a missing one presents as a generic 403. status is required because the only way to learn that a Shopify install was removed is a webhook, and the row must be marked rather than retried forever.

The rotation job

One scheduled job, driven by credential_type:

  • oauth_ac: refresh when expires_at is within 25 per cent of the token's life. Refresh unconditionally every 30 days even if unused, so Etsy's 90 day idle expiry never fires.
  • oauth_cc and jwt_login: do not pre-refresh. Mint on demand, cache until expires_at, and re-mint on any 401. These tokens are cheap.
  • hmac, api_key, oauth1, basic, body_creds: nothing expires. Rotate on a policy schedule, quarterly for Odoo because it forces it, annually elsewhere, and immediately on any staff departure.
  • none: no job. Alert if a document pipeline has received nothing in its expected window, because silence is the only failure signal these have.

Rate limit the job itself. Refreshing 200 Amazon sellers at once will consume the application's token endpoint quota and fail the ones at the end of the list.