Süper GelsinPartner APIv1.0.0
API Reference
TREN
Getting started
  • Quick start
  • Sandbox
  • Authorization
  • Service limits
  • Test hesabı başvurusu
Shared endpoints
  • Business
  • Order lifecycle
  • Order statuses
  • Tax document
  • Courier company integration
  • Customer disputes
  • Reviews
  • Webhooks
Food delivery
  • Menu & item mapping
Çarşı (retail)
  • Çarşı overview
  • Catalogue
  • Picking and return
Reference
  • Versioning & rate limits
  • Error codes & troubleshooting
  • Changelog
  • Frequently asked questions
  • API reference
Developer Portal/Çarşı (retail)

Çarşı overview

Catalogue, order and business integration for businesses that sell products.

Çarşı is the vertical for businesses that sell products: grocery, greengrocer, butcher, delicatessen, nuts, stationery, pet shop, florist. In the API this vertical is called store. It uses the same endpoints as a restaurant; the questions differ: food has menus and modifier groups, Çarşı has barcodes, stock and order picking. The Çarşı-specific endpoints exist only on this vertical; calling them with a restaurant key returns 404 not_available_for_vertical.

Integration in five steps

  1. Read the business: confirm with GET /merchant that vertical is store. Your key is bound to a single business; each business uses its own key.
  2. Fetch the categories: which category can a product attach to, and which fields does that category require?
  3. Upload the catalogue (asynchronous, up to 1,000 items per request).
  4. Day-to-day work: price and stock updates.
  5. Receive orders, write the picking and advance their status.

Authentication

HTTP Basic (apiKey:apiSecret) plus the X-Integrator header; the same as for a restaurant. See Authorization for details.

First request
curl "https://api.supergelsin.com/api/partner/v1/merchant" \
  -H "Authorization: Basic $(printf '%s:%s' "$API_KEY" "$API_SECRET" | base64)" \
  -H "X-Integrator: Ornek POS" \
  -H "X-Operator: kasiyer_01"

Bulk writes are asynchronous

Every bulk endpoint that writes products returns 202 Accepted with a batchId; you read the outcome from a separate endpoint. The response itself is not the result.

GET/batches/{id}
Batch status and per-item outcome.
Moving from a synchronous endpoint to an asynchronous one is a breaking change: response handling has to be rewritten around an identifier and a polling loop. The contract is therefore asynchronous from the first release.

Rate limits are per service group

The quota is counted per group, not per endpoint; the catalogue write and read, order, business and status groups are separate. A large catalogue upload does not block order acceptance. See Service limits for details.

PreviousMenu & item mappingNextCatalogue
On this page
  • Integration in five steps
  • Authentication
  • Bulk writes are asynchronous
  • Rate limits are per service group