intelligent.pageDocs

Knot

US consumer-permissioned merchant API with basic auth, mTLS, webhooks and five SDKs; the Indian channel of the same name is unconfirmed.

The name Knot is ambiguous and the ambiguity has to be resolved before anyone builds. The company with a real, documented API is Knot at knotapi.com, a United States fintech infrastructure business that connects a consumer's merchant accounts on the consumer's behalf: switching a card on file, pulling SKU-level transaction data, managing subscriptions. It is not a seller channel and a brand cannot list products on it. Separately, Indian order management aggregators are reported to carry a sales channel called Knot, which would be a different company entirely. That second one could not be confirmed. This page documents the API that exists and states plainly what is unresolved.

At a glance

Which Knot is this

Two candidates, and the evidence for each:

Knot (knotapi.com), United States. Confirmed by direct reading of its marketing site and documentation index. It describes itself as building products that "connect your cardholders to hundreds of merchants", and sells to "financial institutions and other businesses of all sizes". Its products are CardSwitcher, TransactionLink, AccountUpdater, SubscriptionManager and AgenticShopping, with Detect and Vaulting in the API reference. It has a dashboard at dashboard.knotapi.com and a status page at status.knotapi.com.

An Indian sales channel called Knot. Reported to appear in EasyEcom's channel catalogue, and not confirmed. support.easyecom.io is a client-rendered help desk that returned no article content to the fetcher on every path tried, easyecom.io's own sitemap contains no Knot integration page, and web search was unavailable in this session.

Warning

Treat the identity as unresolved. It is implausible that an Indian order management platform integrates a US card-provisioning API as a sales channel, so the channel named Knot is almost certainly a different company, most likely a small Indian marketplace or D2C brand. Do not merge the two into one connector record. Resolve it by opening support.easyecom.io in a real browser and reading the Knot article, or by asking EasyEcom support which platform it refers to.

What it is

Knot at knotapi.com sits in the consumer-permissioned data layer, the same neighbourhood as Plaid but pointed at merchant accounts rather than bank accounts. A bank or fintech embeds Knot's SDK, the cardholder authenticates to a merchant such as Amazon, Netflix or Uber inside that flow, and Knot then acts on that connection: provisioning a new card into the merchant wallet, reading purchase history, or cancelling a subscription.

For a commerce database this is an interesting but very different kind of source. TransactionLink returns SKU-level detail of what a consumer bought, across merchants, which is basket data no marketplace seller API will ever give you. What it is not is a seller interface: there are no listings to publish, no inventory to write, no settlements to reconcile and no seller account to attach. The data belongs to the consumer who granted access, which carries obligations that seller data does not.

API access

Credentials are issued through a commercial relationship. The site offers a demo request and a dashboard login rather than self-serve signup, and no eligibility policy is published. Expect a contract, a security review and, given the card provisioning surface, scrutiny from the counterparty's risk function. Official SDKs cover five platforms: iOS (CocoaPods or Swift Package Manager), Android (Maven Central), React Native (npm or yarn), Flutter (pub) and web (unpkg or npm). Migration guides exist per platform, so the SDKs carry breaking changes across major versions and should be pinned.

Authentication

Knot documents two mechanisms. HTTP basic auth: requests carry a client_id and a secret, base64-encoded in the standard basic auth form, against separate documented base URLs for the development and production environments. Mutual TLS: an alternative using client certificates, offered for higher-assurance deployments.

The exact base URLs, the header composition and the credential rotation policy sit on the authentication page of the reference, which was not read in this pass. No endpoint path, host or header value is reproduced here, because inventing one would be worse than the gap. Read docs.knotapi.com before writing the client.

Session handling is explicit: the reference documents create session and extend session calls, so a short-lived session is minted server side and handed to the SDK rather than the client holding long-lived credentials. Your backend holds client_id and secret; the app never sees them.

Objects we can read

Mapped against the unified model's object list, most of it is absent.

Orders and order items

The one object that exists, through TransactionLink, described as retrieving SKU-level transaction data from merchant accounts. Granularity is documented as transaction level, order level and SKU level depending on the product. Field names are not reproduced here because the reference pages were not read.

Accounts, merchants and subscriptions

The reference documents List merchants, for rendering a merchant picker in your own interface, Detect accounts with search and sync, for finding merchants a user already has accounts with, get and unlink account calls, and SubscriptionManager for reading and cancelling subscriptions.

What does not exist, and the privacy constraint

Listings, inventory, shipments, returns, settlements and locations have no counterpart: Knot does not see a seller's side of a marketplace. Everything it does return is personal data about an identified consumer, obtained under that consumer's grant. The API documents a Delete user data call and an audit log, so the compliance model is explicit rather than incidental. Keep Knot data in a separate schema with its own retention rules, and wire the deletion call into your own deletion path.

Writing back: listings, price and stock

Not available, and not the point of the product. Knot's write surface is CardSwitcher, which provisions a card into a merchant wallet, Vaulting, and subscription cancellation. None of these touches a commerce listing, a price or a stock level.

Webhooks and notifications

Yes, and they are properly specified. Subscription URLs are configured in the Knot dashboard, and signatures are verified using a Knot-Signature header.

Documented event families:

Merchant status update events also exist. Retry policy and signature algorithm are on the webhook pages of the reference, which were not read. CREDENTIALS_FAILED is the event to build operational alerting around, because a silently dead connection produces missing data rather than errors.

Rate limits and pagination

Not read in this pass, and the documentation index surfaces no dedicated rate limit page. Check the API reference and the dashboard before designing any sync cadence.

Mapping to the unified model

Only the consumer purchase objects map, and they map onto orders and order_items from the buyer's side rather than the seller's.

Gaps and open questions

  • The identity question is open. Whether EasyEcom's channel called Knot is knotapi.com or an unrelated Indian company is unresolved, and the evidence strongly suggests they are different. Resolve this before creating a connector record.
  • The authentication, API reference, rate limit and webhook retry pages were not read individually; only the documentation index was. Base URLs, endpoint paths, field names and limits are therefore not stated on this page.
  • Pricing and eligibility for Knot credentials are not published, and the merchant coverage list, which decides whether TransactionLink covers Indian merchants at all, was not retrieved.
  • support.easyecom.io is client rendered and returned no article content, so no EasyEcom knowledge base article could be cited here, and web search was unavailable in this session.

Sources