Sandbox

Applying for a test account and developing without touching live data.

The test environment runs the same build as production: every production release updates it at the same moment, and both environments report the same gitSha from /api/health. Only the data and the external services differ. Code that works here works in production; the only change is the base URL and the key.

Base URL and keys

Test environment

https://sandbox.supergelsin.com/api/partner/v1

Test keys start with ck_test_, live keys with ck_live_. A key sent to the wrong environment receives 401 environment_mismatch with a message naming the correct address. Every response carries an X-Api-Environment header (sandbox or production).

Applying for a test account

A test account is requested with the application form on the developer portal: on the Test hesabı başvurusu page you enter the firm name, an e-mail address and, optionally, the name of your integration software. The firm name is the name used in the X-Integrator header: 1–30 characters; letters, digits and spaces without Turkish characters. At most 5 applications per hour can be made from one IP address.

The application is received. The form confirms with the Turkish message shown on the page: the approval link is sent to your e-mail address once the application is approved.
The application is reviewed and approved by the platform administration. No e-mail is sent for a rejected application.
After approval a signed link is sent to your e-mail address. The link is valid for 24 hours.
The link opens the account in the test environment and shows the keys once. The page cannot be reopened; save the apiSecret values right away.

What the key page shows

{
  "baseUrl": "https://sandbox.supergelsin.com/api/partner/v1",
  "integrator": "Ornek POS",
  "restaurant": { "merchantId": "…", "apiKey": "ck_test_…", "apiSecret": "…" },
  "store":      { "merchantId": "…", "apiKey": "ck_test_…", "apiSecret": "…" }
}

The account contains a separate key pair for a test restaurant and for a test Çarşı business; no IP allow-list is defined. The integrator value is the firm name you entered in the application and goes into the X-Integrator header.

Applications are not accepted until the privacy notice shown on the application form is in force. The form carries the line "Aydınlatma Metni'ni okudum ve anladım" (in Turkish). There is no checkbox; the application does not depend on that line.

The first five minutes

Read the business with GET /merchant; vertical tells you whether the key belongs to a restaurant or to a Çarşı business.
With the restaurant key, pull the test menu with GET /menu (3 categories, items with option groups). With the Çarşı key, read the test products with GET /products; the test business also includes weighed items.
Register your webhook (Webhooks) and create an order with POST /orders/test; order.created reaches your address with a real signature.
Advance the status with POST /orders/{id}/status (Order lifecycle). Test orders are not cancelled automatically when the acceptance period expires; try the cancellation flow with the cancel action.
With the Çarşı key, try the picking flow (Picking and return).

Differences from production

Alan	Tip	Açıklama
`Code and version`	same	Same release; verify with `gitSha` in `/api/health`.
`Rate limits and caps`	same	See Service limits. Not relaxed in the test environment.
`Webhooks`	on	Real calls are made to your address; the https and public-address requirements apply unchanged.
`Scheduled jobs`	on	The dispute window, the bulk catalogue queue and invoice-link checks run at production cadence.
`Customers, couriers, notifications`	none	There are no real customers or couriers; no SMS, e-mail or mobile notifications are sent.
`Money`	none	Test orders are created as payment at the door; no settlement, commission or ledger is produced.
`Receipt image`	not stored	On picking, `receiptUrl` is validated but not stored; the response carries a `receipt_not_saved` warning.
`Data retention`	14 days	Orders and disputes are deleted after 14 days. Accounts, keys and catalogue changes remain.

Going live

Live keys are generated by the business from the partner console (Quick start). When switching, change only the base URL and the key; headers and bodies are identical. For a first check in production you can still use POST /orders/test; that order does not enter revenue either.

Read the base URL and key from configuration, not from code. Point-of-sale software that keeps both test and live configuration can choose the environment per business.

Base URL and keys

Test environment

https://sandbox.supergelsin.com/api/partner/v1

Applying for a test account

The application is received. The form confirms with the Turkish message shown on the page: the approval link is sent to your e-mail address once the application is approved.

The application is reviewed and approved by the platform administration. No e-mail is sent for a rejected application.

After approval a signed link is sent to your e-mail address. The link is valid for 24 hours.

The link opens the account in the test environment and shows the keys once. The page cannot be reopened; save the apiSecret values right away.

What the key page shows

{
  "baseUrl": "https://sandbox.supergelsin.com/api/partner/v1",
  "integrator": "Ornek POS",
  "restaurant": { "merchantId": "…", "apiKey": "ck_test_…", "apiSecret": "…" },
  "store":      { "merchantId": "…", "apiKey": "ck_test_…", "apiSecret": "…" }
}

The first five minutes

Read the business with GET /merchant; vertical tells you whether the key belongs to a restaurant or to a Çarşı business.

With the restaurant key, pull the test menu with GET /menu (3 categories, items with option groups). With the Çarşı key, read the test products with GET /products; the test business also includes weighed items.

Register your webhook (Webhooks) and create an order with POST /orders/test; order.created reaches your address with a real signature.

Advance the status with POST /orders/{id}/status (Order lifecycle). Test orders are not cancelled automatically when the acceptance period expires; try the cancellation flow with the cancel action.

With the Çarşı key, try the picking flow (Picking and return).

Differences from production

Alan	Tip	Açıklama
`Code and version`	same	Same release; verify with `gitSha` in `/api/health`.
`Rate limits and caps`	same	See Service limits. Not relaxed in the test environment.
`Webhooks`	on	Real calls are made to your address; the https and public-address requirements apply unchanged.
`Scheduled jobs`	on	The dispute window, the bulk catalogue queue and invoice-link checks run at production cadence.
`Customers, couriers, notifications`	none	There are no real customers or couriers; no SMS, e-mail or mobile notifications are sent.
`Money`	none	Test orders are created as payment at the door; no settlement, commission or ledger is produced.
`Receipt image`	not stored	On picking, `receiptUrl` is validated but not stored; the response carries a `receipt_not_saved` warning.
`Data retention`	14 days	Orders and disputes are deleted after 14 days. Accounts, keys and catalogue changes remain.

Going live

Read the base URL and key from configuration, not from code. Point-of-sale software that keeps both test and live configuration can choose the environment per business.