Ginesys POS

Ginesys One publishes a real REST API keyed by a Ginesys_Api_Key header. It is write-heavy: documents can be pushed in, but POS sales cannot be read out.

Ginesys is an Indian retail technology vendor whose suite, Ginesys One, is built around apparel, footwear and lifestyle chains: Ginesys ERP for head office, Ginesys POS as the long-standing on-premise store till, Zwing as the newer cloud point of sale, Browntape as the e-commerce order management layer, EaseMyGST for tax and a business intelligence module. In a brand running Ginesys, the ERP holds the item and article master, stock by site, purchase and sales documents and the customer ledger, while the POS holds the bill-level sales at each store and syncs them up to head office.

Ginesys is one of the few vendors in this part of the catalogue with a genuine public API reference. The "Public API for Ginesys ERP" section of the Ginesys One Knowledge Hub is open without login and documents around ninety operations across seven modules, each with the HTTP method, the full path, the authentication header, a complete example request and a real success and error response. That is a much better starting position than Logic ERP or AlignBooks.

The catch is the direction of travel. The public API is overwhelmingly a write surface. You can create almost any document in Ginesys. You cannot read a POS bill, a sales invoice, a stock position or a customer through it. That shapes what a connector can be.

At a glance

Warning

The single most important finding for planning: there is no documented public endpoint that returns sales. Not a POS bill, not a sales invoice, not a sales order. Every sales-side operation in the public reference is a create, an update, an authorise or a cancel. If the requirement is to read store sales out of Ginesys, the public API does not do it, and the route is the business intelligence module, a report extract or a database-level arrangement with the customer. Establish that before promising a sales feed.

What it is

Ginesys One is sold as a connected suite rather than a single product, and the parts matter because they have different integration stories.

Ginesys ERP. Head office: procurement, inventory, sales and distribution, warehouse management, production and finance. This is where the public API lives.
Ginesys POS. The established on-premise store application with a POS Back Office and a POS Manager at head office. Stores run a local database and exchange data with head office through a scheduled data sync, with full and differential backup files. The knowledge hub's POS troubleshooting pages are almost entirely about that sync: sync schedulers, checking sent and received data, differential backup failures and transport-level SQL Server errors. There is no store-level API in that design.
Zwing. The cloud point of sale, with a Zwing Console for configuration, WebPOS for billing, product and category management, tax management, stock adjustment, goods transfer and return, stockpoint transfer, goods receipt notes and store credit notes. Zwing connects to Ginesys ERP through an ERP Integration Plugin, and the knowledge hub documents on-premise server prerequisites for enabling Zwing to Ginesys integration, so even the cloud till reaches head office through a customer-hosted component.
Browntape. The e-commerce order management layer, acquired by Ginesys. It has its own documented APIs in the knowledge hub, including Orders, Inventory, Manifests, Returns, Company, a SKU and inventory lookup and an explicit API Limits page. Two Returns API versions are documented, 0.11 marked "To be Sunset by Sept 2026" and 0.12 as the successor. If the requirement is marketplace and e-commerce orders for a Ginesys customer, Browntape is the right surface, not the ERP API.
EaseMyGST and Business Intelligence complete the suite.

The public knowledge hub exposes seven spaces: Ginesys ERP, Ginesys POS, Cloud POS (Zwing), Browntape, Business intelligence, EaseMyGST and EaseMyRetail.

API access

The knowledge hub's own framing is that Ginesys "is releasing its Public APIs to enable developers, partners, and businesses to integrate more effectively with its ERP platform", and it explicitly anticipates "free and premium API tiers, allowing customers to pay for advanced functionalities or higher usage limits". No tier, price or limit is actually published.

What is known about getting access:

The customer runs Ginesys ERP at a release recent enough to carry the endpoint. Each API page states a release version, and they range from 12.28.7 through 12.32.1 across the set, so endpoint availability depends on the customer's upgrade state. Check the customer's version against the page for every endpoint you plan to use.
A key is issued and sent as Ginesys_Api_Key. The procedure to generate it is not in the public space.
The base URL is per installation. Every documented example uses the literal placeholder https://baseurl/, so Ginesys does not operate a shared public host for this API.

There is no OpenAPI specification, no Postman collection and no SDK in any language.

A structural limitation of the public documentation is worth stating plainly. Each endpoint page includes a "Properties" table that is pulled in from a restricted internal space, and on the public page it renders as an error: "User 'null' does not have permission to view the page". So the public reference gives you the method, the path, the headers, a complete worked example request and the real response shapes, but not the field-by-field reference with types, lengths and mandatory flags. A few pages, such as Create POS User, do carry their property table inline. Plan to ask Ginesys for the property tables.

Authentication

A static API key. There is no token exchange, no expiry and no refresh documented.

Every endpoint page documents exactly two mandatory headers:

Note the value format: the literal word API, a space, then the token. It is not Bearer.

An authenticated call:

POST /erp/gds/api/sales-order HTTP/1.1
Host: your-ginesys-host
Ginesys_Api_Key: API YOUR_TOKEN_HERE
Content-Type: application/json

{
  "orderDate": "2026-03-04T00:00:00",
  "customerId": 40071,
  "channelCode": 2001,
  "documentNo": "DOC-SO-2026-00101",
  "orderNo": "ORD-2026-00101",
  "ownerSiteCode": 1001,
  "destinationSiteCode": 1005,
  "reservationRequired": "Y",
  "partialReservation": "N",
  "isPosOrder": "N",
  "intgOrderId": "INTG-SO-88001",
  "itemDetails": [
    {
      "itemCode": "ITM-00891",
      "qty": 50,
      "rate": 1299,
      "factor": 1,
      "intgOrderDetailId": "INTG-SO-DET-001",
      "channelB2COrderDetId": "B2C-DET-001"
    }
  ]
}

There is nothing to refresh. For multiple selling entities, expect one key and one base URL per installation and per organisation unit. The knowledge hub has a page on connecting two Ginesys organisational units to one Zwing instance, so the organisation unit is a real boundary in this product and should be modelled as the account key.

Objects we can read

Read coverage is narrow and is restricted to masters. All reads follow the same envelope.

Products and listings

GET /erp/gds/api/inv/item returns one item by item code or barcode. The documentation notes an unusual convention: "Input should be given as request String and not as request Body", with the example sending a JSON object on a GET.

{
  "requestId": "a4d544fe-4587-49e5-9768-f144949c160c",
  "status": 0,
  "timestamp": "2025-12-25T14:40:42.7513545+05:30",
  "message": "Item Fetched Successfully.",
  "result": {
    "itemCode": "K991067",
    "barcode": null,
    "division": "MENS",
    "section": "JEANS",
    "departmentCode": 19,
    "department": "JEANS",
    "articleCode": 1009,
    "isNonInventoryItem": "N",
    "category1Name": "9 SHADES",
    "category2Name": "JEANS",
    "category3Name": "34",
    "category4Name": null,
    "category5Name": null,
    "category6Name": "2",
    "rsp": 699,
    "scanUnit": 1,
    "taxGroupCode": 6,
    "taxGroupName": "TAXABLE",
    "vendorCode": 193,
    "vendorName": "A TO Z : SE52",
    "vendorAlias": "A TO Z",
    "uom": "PCS",
    "expiryDate": null,
    "shortName": "68",
    "standardRate": 699,
    "wsp": 430
  }
}

That response is a good window into the model. Ginesys is built for apparel: division, section, department, article and six free category levels, with size and shade landing in the category slots. The item is the saleable unit, the article is its parent. Three prices coexist: rsp (retail selling price), wsp (wholesale selling price) and standardRate, alongside MRP.

Orders, invoices and POS sales

Not readable. The sales and distribution section contains only creates, updates, authorisations and cancellations. There is no list endpoint, no get-by-id and no changed-since filter anywhere in the public reference.

Inventory

Not readable. Stock can be moved with POST /erp/gds/api/inv/Stockpoint/transfer and adjusted with POST /erp/gds/api/inv/miscentry, but no endpoint returns a stock balance by item and site.

Customers

Not readable. Customers appear as customerId on order creation, and Zwing documents an ERP to CRM customer field mapping, but there is no customer master endpoint in the public API.

Locations

Not readable as a list. Sites appear throughout as ownerSiteCode and destinationSiteCode, both numeric.

POS Management

Four operations, all writes, all about staff rather than sales:

POST /erp/gds/api/pos/User creates a POS user. This page does carry its full property table: employeeNo, fullName, userName, isLoginEnabled, remarks, address1 to address3, city, pincode, email, phoneNo1, phoneNo2, mobileNo, with lengths and mandatory flags.
PUT /erp/gds/api/pos/User updates one.
PUT /erp/gds/api/pos/User/assign-sites assigns a user to sites, with a matching un-assignment operation.

For actual store sales, the mechanism is the POS data sync, not an API. The knowledge hub documents configuring a data sync scheduler for POS, performing a sync at the store, and checking sent and received data, and its troubleshooting pages describe full and differential SQL Server backups moving between store and head office.

Writing back: listings, price and stock

This is where the API is strong. Reading it as "can we push sales orders, invoices and stock adjustments in", the answer is yes to all three, plus most of the rest of the retail document set.

Sales and distribution

Further documented operations in the same module cover delivery challans against order and against reservation with FIFO variants, sales invoice or transfer out against a delivery challan with charges, single and multiple sales returns with FIFO, LIFO or ad hoc costing, sales return against a store return, transfer in against transfer out, transfer in against store return, transfer in for an unmanaged site, and a service order.

Inventory and masters

Item creation and update is how price reaches Ginesys. There is no separate price endpoint: rsp, wsp and standardRate live on the item master.

Stock is never set to an absolute number. It moves through stockpoint transfers, miscellaneous entries, goods receipts and the sales document chain. Model a stock correction as a miscellaneous entry, and confirm with the customer which entry types their configuration permits.

Procurement, warehouse, production and finance

Purchase order create, cancel and authorise; goods receive challan; purchase invoice ad hoc, against a goods receive challan and FIFO, plus an authorise; goods return ad hoc and against goods receipt. Warehouse operations cover picklist generation, assignment and cancellation, and reservation create and cancel. Production covers job orders, job order cancellation and job receipts against order and FIFO, plus working plans. Finance covers general, debit and credit journals with create, update, status update and delete.

The response envelope

Every operation returns the same shape. Creates return 201 Created, reads 200 OK.

{
  "requestId": "",
  "status": 0,
  "timestamp": "2026-03-26T13:41:34.5075322+05:30",
  "message": "Sales credit note Created Successfully.",
  "result": {
    "isSuccess": true,
    "journalCode": 265041,
    "dataVersion": 4667275,
    "schemeDocNumber": "K99SJC25-26-0063"
  },
  "dataVersion": 4667275,
  "error": null,
  "success": true
}

status is 0 for success and 1 for failure, which is inverted from the usual convention. Check success and status rather than only the HTTP code. dataVersion is a monotonically increasing version identifier on the record, and is the only change-tracking primitive visible in the whole surface. The error object carries code, message, target (the offending field), detail and a nested innerError, so validation failures are field-addressable.

Idempotency and external references

There is no idempotency header, but there is something better in practice: most document creates accept integration reference fields. Sales order takes intgOrderId at header level and intgOrderDetailId plus channelB2COrderDetId per line; credit note takes intgInvoiceId and intgMainId; document adjustments take intgDocId. Every document also carries ten user-defined string fields, five numeric and five date fields (udfString01 through udfString10, udfNum01 to udfNum05, udfDate01 to udfDate05).

Use the integration reference fields for the external key and keep the user-defined fields in reserve. Whether Ginesys enforces uniqueness on intgOrderId is not documented and must be tested.

Webhooks and notifications

None. The public knowledge hub documents no event subscription, no callback URL, no signature scheme and no retry policy for the ERP public API.

Since there is also no read endpoint for transactional documents, polling is not an option either. The practical designs are:

Push only. Our system is the source of orders and pushes them into Ginesys. Nothing comes back except the create response, so the create response must be captured: journalCode, schemeDocNumber and dataVersion are the only handles you will get.
For anything that must flow the other way, negotiate a separate mechanism with the customer: the business intelligence module, a scheduled report extract, or a read replica of the head office database. All three need the customer's agreement and none is covered by the public API.
For e-commerce and marketplace orders, use Browntape, which has its own Orders, Inventory, Returns and Manifests APIs and an explicit limits page.

Rate limits and pagination

No rate limit, quota header or burst policy is published for the ERP public API. The knowledge hub's own overview page anticipates "higher usage limits" as a paid tier, which implies limits exist but does not state any.

There is no pagination anywhere, because there are no list endpoints. Every read is a single-record lookup by code.

Practical guidance until Ginesys supplies numbers: serialise writes per installation, retry on transport errors rather than on validation errors (the error object tells you which is which through target), and treat the customer's own server capacity as the limit, since the base URL is their installation.

Mapping to the unified model

Field names below are from the vendor's documented examples and responses. The full property tables are in a restricted space, so types, lengths and mandatory flags need confirming with Ginesys.

Gaps and open questions

No read for any transactional object. This is the defining limitation. Confirm with Ginesys whether read endpoints are planned, and in the meantime agree an extract route with the customer.
The field-level property tables are in a restricted DEV space and render as a permission error on the public pages. Request them, for every endpoint you will use.
Key issuance is not documented publicly. How a key is generated, whether it can be scoped, and whether it can be rotated are all unknown.
Charge codes drive tax, freight and discount and are customer-configured. There is no documented endpoint to list them, so the mapping has to be built by hand per customer.
No sandbox is documented.
No rate limit is published, although the vendor's own overview anticipates usage tiers.
Endpoint availability is tied to the customer's release: documented pages span 12.28.7 to 12.32.1. Check every endpoint against the customer's version.
Uniqueness and duplicate behaviour on intgOrderId is not documented. Test it before relying on it for idempotency.
Ginesys POS store sales reach head office through a scheduled data sync of SQL Server backups, not an API. Anything that needs near real time store sales is a custom arrangement.
Zwing, the cloud point of sale, is documented for configuration and operation but not for integration. Its knowledge hub has no API pages and its ERP link goes through an integration plugin that needs an on-premise server. If a brand runs Zwing rather than Ginesys POS, ask specifically what that plugin exposes.
Browntape has its own documented APIs including an explicit limits page and a Returns API version 0.11 sunsetting in September 2026. It deserves its own catalogue entry.
Typographical warnings from the vendor's own paths: /erp/gds/api/Logictic/gate-entry is spelled that way on the server, and casing is inconsistent (/inv/Stockpoint/transfer, /snd/SalesOrder/cancel, /pos/User). Copy paths exactly.

Sources

Ginesys One Knowledge Hub, read 2026-09-22. Public Confluence, spaces PUB (Ginesys ERP), GPOS (Ginesys POS), ZPOS (Cloud POS Zwing), BTKB (Browntape), GBI, EMG, EMR
Public API for Ginesys ERP overview page in the PUB space, read 2026-09-22. Source of the vendor's stated intent and the anticipated free and premium tiers
Individual endpoint pages in the PUB space, read 2026-09-22, including Create Sales Order, Create Sales Credit Note, Create Sales Debit Note, Get Item, Create Item, Update Item, Get Article, Get Item Set, Create Stockpoint Transfer, Create Miscellaneous Entry, Create POS User, Update POS User, User Site Assignment, Create Purchase Order, Create Goods Receive Challan, Generate Picklist, Create Reservation, Create Gate Entry, Delivery Challan Cancellation, Sales Order Cancel and Authorise, Get GST Rate Master, Get Batch Serial Master. Source of every path, header and example on this page. Ninety-seven pages sit under the public API section
Ginesys POS space pages on configuring the data sync scheduler, performing a sync at the store and checking sent and received data, read 2026-09-22
Cloud POS (Zwing) space pages on the ERP Integration Plugin configuration and on-premise server prerequisites for Zwing to Ginesys integration, read 2026-09-22
Browntape space API index in the same knowledge hub, read 2026-09-22: Browntape API, Orders API, Inventory API, Manifests API, Returns API, Returns API 0.11 and 0.12, Company API, GET SKU / Inventory Lookup API, API Limits
Ginesys product site, read 2026-09-22, for the product line and integration pages
DNS and HTTP probes on 2026-09-22: help.ginesys.in redirects to a Confluence instance on wiki.ginesys.in:8099 which was unreachable; kb.ginesys.in redirects to the hosted Atlassian knowledge hub, which is public