intelligent.pageDocs

Yo!Kart

Yo!Kart is self-hosted licensed marketplace software, so the integration path is your own MySQL database and PHP code, not a vendor API: no public REST docs exist.

Yo!Kart is multi-vendor marketplace software from FATbit Technologies, a Chandigarh company, sold as a one-time licence with source code rather than as a hosted service. The current line is V10. It is the odd one out in this catalogue: there is no Yo!Kart cloud to connect to, because every Yo!Kart marketplace is a separate LAMP install on the licensee's own server with its own MySQL database. That changes the whole connector question. You are not asking FATbit for API credentials; you are asking the marketplace operator for access to a machine they own. What FATbit does not publish, and what this page had to establish by inspection, is any REST API reference for the platform itself.

At a glance

What it is

Yo!Kart is marketplace software, not a D2C store builder: the buyer of the licence becomes the marketplace operator and onboards sellers, each with their own shop, catalogue, orders and payouts. FATbit sells it into B2C marketplaces and, through a separate B2B edition, into wholesale and procurement marketplaces. It is a global product rather than an India-only one, with RTL language support and Middle East, Africa and Latin America payment gateways alongside Indian ones, but the vendor is Indian and the Indian gateway and courier list is well covered. It is positioned against CS-Cart, Sharetribe, Magento and Mirakl, and a large part of its marketing is clone pages for Etsy, eBay, Amazon, Alibaba, Poshmark and Vinted.

Licence packages, list prices as shown on 2026-09-22: GoQuick at 1,999 US dollars, GoQuick Boost at 3,999, GoQuick Pro at 4,999, GoCustom at 6,249 reduced from 7,999, and GoQuick Ultra on quote. All are one-time with a lifetime licence, twelve months of technical support and no transaction fees.

API access

There is no vendor API programme, because there is no vendor-operated instance. Three things follow from that, and they are the whole of the integration story.

  1. You have the database. A Yo!Kart install is MySQL 8.0 or greater under PHP 8.1 on Apache 2.4 or Nginx, on Linux. Orders, listings, inventory, shipments, returns and seller payouts all sit in tables you can read directly, with no rate limit and no pagination model beyond SQL. For a data warehouse this is the fastest path by a wide margin: a read-only MySQL user and either replication or a scheduled extract.
  2. You have the code, mostly. The licence sells "the complete customizable source code", but with two carve-outs to note. The server requirements list Ioncube Loader as a required PHP extension, and the packages page says the web app source code is included "excluding framework". FATbit describes the framework as "a tightly bound library with an in-house encrypted framework". So the application layer is editable PHP and the framework layer underneath it is encoded. You can add an endpoint; you cannot read the core.
  3. Mobile app source code is a separate purchase. GoQuick Boost and Pro ship the buyer and delivery apps as binaries, and only GoQuick Ultra includes "customizable source code of mobile apps".
Note

Because there is no hosted Yo!Kart, every Yo!Kart connector is bespoke to one operator's install and one version. Do not write a connector that assumes a shared schema across two Yo!Kart marketplaces without checking both, and record the version in your configuration.

Authentication

Not applicable at the platform level. FATbit issues no API keys and runs no OAuth server. What exists on a real install:

  • Database credentials, if the operator gives you a read-only MySQL user. This is the recommended route.
  • The admin and seller panels, which are ordinary PHP sessions behind a login form. Not an integration surface.
  • The mobile app endpoint, described below, whose authentication scheme is not published.

The undocumented app API

Every stock install answers at /app-api. On FATbit's own public demo on 2026-09-22:

curl https://demo.yo-kart.com/app-api

{ "status": -1, "msg": "Invalid Request" }

The same body comes back for any single-segment path under it, while a two-segment path returns a plain Page not found., so routing is one controller segment deep. This is the endpoint the Android and iOS buyer apps talk to, and the status and msg envelope is real, observed output rather than a guess.

Nothing else about it is published: no method list, no controller names, no authentication header, no request body schema, no versioning. Do not build against it from the outside. If you need it, the honest route is to ask the operator for the app API documentation FATbit ships with the licence, or to read the routing table in the install you have access to.

Objects we can read

From the database on your own install, all of them: orders, order items, products and listings, inventory, shipments and tracking, returns and cancellations, seller payouts and settlements, customers and shop locations. Yo!Kart's feature pages confirm each of those exists as a module, including an in-built shipping module with order level, item level and shipping package rules, a tax module supporting single and combined tax structures, and seller payout handling through Stripe Connect and PayPal Payouts.

No table names, column names or sample rows are given on this page, because FATbit publishes no schema documentation and we had no install to inspect. Get the schema from the operator's install, not from a blog post.

For shipment and tracking data specifically, the integrations are outbound to carriers, so the richer source is usually the carrier account rather than the Yo!Kart tables. FATbit lists ShipStation, AfterShip, ShipEngine, EasyPost, Aramex and Shiprocket as pre-integrated shipping providers, Avalara and TaxJar for tax, and more than twenty payment gateways including Stripe, PayPal, Amazon Pay, Razorpay, Paytm, CCAvenue, Braintree, 2Checkout, PayStack, M-Pesa and Pay Fort. Each of those has its own connector page and its own documented API.

Writing back: listings, price and stock

Yes, but every route is one you build.

  • Direct database writes. Possible and sometimes the only option, but risky: the framework is encoded, so you cannot see what invariants it expects, and there are caches and search indexes that a raw write will not invalidate. Prefer reads from the database and writes through the application.
  • Custom PHP in your own copy. The supported way to add an integration endpoint. You own the application layer, so add a controller, authenticate it yourself, and keep it in version control separate from FATbit's code so upgrades do not clobber it.
  • Admin and seller panel bulk upload. Yo!Kart has catalogue and inventory management screens with bulk import. The template columns are not published; export one from your install.

There is no vendor-side feed, bulk job API or listing endpoint to target.

Webhooks and notifications

None published, and none observed. Nothing to subscribe to.

If you need change notification and you own the install, the cheapest reliable mechanism is a database-side one: poll on an indexed updated column, or add triggers or an outbox table in your own schema. Yo!Kart requires "Ability to run scheduled jobs" on the server, so cron is available for a push job you write yourself.

Rate limits and pagination

Not applicable. There is no vendor endpoint to be limited by. Against your own MySQL, the limits are the ones you set, and the usual care applies: read from a replica, not from the box serving the storefront, and keep extracts off peak.

Mapping to the unified model

Every unified table can be filled from a Yo!Kart install, but the mapping is per install and cannot be written generically. Use yo-kart as the orders.channel value only if you are aggregating several Yo!Kart marketplaces; otherwise use the marketplace's own name, since to a seller on it this is a distinct channel. Key channel_account_id on the marketplace domain plus the seller's shop id, because one install holds many sellers and the seller dimension is the one that matters for settlements.

Do the schema mapping against the operator's database once, record the column names in your configuration, and re-verify after every Yo!Kart upgrade.

Gaps and open questions

  • No table or column names are published, so the real mapping work cannot start until you have access to an install.
  • The /app-api contract is undocumented. Whether FATbit ships app API documentation with the licence is unverified.
  • The exact boundary of the encoded framework is unclear. "Excluding framework" on the packages page and the Ioncube Loader requirement agree that some of the code is not readable, but FATbit does not say which parts.
  • Whether the B2B edition shares a schema with the B2C edition is unverified. The demos are separate installs.
  • Whether upgrades between V10 point releases change the schema is not documented, which matters because this connector is schema-coupled by construction.

Sources