Business

Business information

GET /merchant is the first call and the regular monitoring call. You can measure the difference between your clock and serverTime in the response.

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"

Open or closed status

curl -X PUT "https://api.supergelsin.com/api/partner/v1/merchant/status" \
  -H "Authorization: Basic $(printf '%s:%s' "$API_KEY" "$API_SECRET" | base64)" \
  -H "X-Integrator: Ornek POS" \
  -H "X-Operator: kasiyer_01" \
  -H "Content-Type: application/json" \
  -d '{ "status": "busy", "busyMinutes": 20, "busyExtraMinutes": 15 }'

PUT /merchant/status returns the current business information (the same body as GET /merchant).

• Closing and reopening a Çarşı business resets the busy setting.
• A restaurant whose setup is incomplete cannot be opened: 400 setup_incomplete; the message names what is missing.
• Writing open does not remove the automatic pause; autoPaused does not change. Only re-establishing the connection removes the pause (below).

Working hours

PUT /merchant/working-hours is a partial update: only the days you send change. The workingHours value from GET /merchant can be sent to this endpoint as is. If the closing time is earlier than the opening time the shift crosses midnight and runs into the next day (for example 22:00–02:00). Working hours are a weekly schedule; use PUT /merchant/status for a temporary closure. For a business with no time restriction, GET returns workingHours: null; this endpoint does not accept null at the top level, so write the days one by one.

{
  "workingHours": {
    "mon": { "open": "09:00", "close": "23:00" },
    "sat": { "open": true, "shifts": [{ "open": "10:00", "close": "14:00" }, { "open": "17:00", "close": "23:00" }] },
    "sun": { "open": false },
    "tue": null
  }
}

Errors: 400 bad_request for an invalid day key (accepted: mon…sun), for a wrong time format and for equal opening and closing times. If the restaurant is not found: 404 not_found (message: Restoran bulunamadı.); on a Çarşı business the message of the 404 response is empty.

Connection notice

curl -X POST "https://api.supergelsin.com/api/partner/v1/reachability" \
  -H "Authorization: Basic $(printf '%s:%s' "$API_KEY" "$API_SECRET" | base64)" \
  -H "X-Integrator: Ornek POS" \
  -H "X-Operator: kasiyer_01" \
  -H "Content-Type: application/json" \
  -d '{ "status": "reachable" }'

POST /reachability reports that the point-of-sale software is running; status is reachable or unreachable, and it is used on both verticals. Automatic pause starts when recent orders go unanswered in a row.

Only re-establishing the connection removes the pause. A reachable notice counts as re-establishing the connection in three cases: unreachable was reported earlier, 15 minutes or more have passed since the previous notice, or it is the first notice. A reachable notice arriving less than 15 minutes after the previous one does not remove the pause; it is suitable for regular polling. An unreachable notice is recorded as a connection loss.

Multiple storefronts (virtual brands)

A restaurant owner can open several storefronts from the same kitchen with different product ranges. For the integration the rule is: each key pair is bound to a single storefront, and each storefront generates its own key in the partner console. The webhook address is per storefront too; it is written for the storefront the key is bound to.

Opening a second storefront requires a different menu. Thresholds: the menu must differ from the business's other storefronts by at least 60%; at least 5 items must belong only to that storefront; at a volume of at least 20 orders the business rating must be at least 4.3 and the rate of business-caused issues at most 5%. Changing only the name, photo or price does not count as differentiation; the comparison normalises item names. The menu rule does not apply to the first storefront.