חשבוניות SLK
פתיחת חשבון
All API pages

API reference

Sandbox

נסו ב-Playground
On this page

Build and test an integration without issuing a single real document.

Two ways to be in sandbox#

  1. A developer sandbox account — a free, isolated test business you open yourself. Sandbox mode is locked on.
  2. Sandbox mode on a real business — the owner flips "מצב Sandbox ל-API" on /billing/settings. Reversible; meant for testing a Zapier/Make flow before going live.

Open a developer sandbox#

http
POST /api/developers/sandbox
Content-Type: application/json
json
{ "email": "[email protected]", "password": "a-long-passphrase", "name": "דנה" }

(A form post works too, and the page /developers/sandbox does it for you.) Response 201:

json
{
  "tenantId": "3c8f…",
  "apiKey": "bk_9f2c…",
  "baseUrl": "https://invoice.slk.co.il/api/billing/v1",
  "hookUrls": {
    "shopify": "https://invoice.slk.co.il/api/billing/ecommerce/shopify/8d1f…",
    "wix": "https://invoice.slk.co.il/api/billing/ecommerce/wix/2b7e…",
    "generic": null
  },
  "loginUrl": "/login",
  "expiresAt": "2026-10-29T10:00:00.000Z"
}
  • apiKey is shown once. Only its hash is stored. Save it now.
  • hookUrls.generic is null until the universal webhook connector is enabled on the deployment.
  • The response also signs you in (session cookie), so "open the dashboard" at /billing works straight away. Later, sign in at /login with the same email and password.
  • password must be at least 10 characters; disposable-inbox domains are refused; the email must not already be registered.

What you get: a business named Sandbox — <your email> on the Pro trial (every feature, including the API, webhooks and e-commerce connectors, is on), 3 demo customers, 5 demo items and 2 demo SBX- documents.

Lifecycle: it expires 30 days after creation and is then removed together with its key and login, so the same email can open a fresh one. No email verification is needed, because nothing real can be issued.

Errors: 400 (invalid email / short password / disposable domain, with a code), 409 {"code":"exists"} (Hebrew message: the email is already registered), 429 (too many signups from your IP this hour, Retry-After header in seconds).

What SBX mode does#

In sandbox, POST /create-document (both shapes):

  • runs input validation and the same totals engine as production, so a malformed request fails the same way;
  • writes nothing to the books — the request is mirrored into a separate sandbox table;
  • returns a fake number: docNumber: "SBX-000003" (Invoice4U shape: DocumentNumber: "SBX-000003"), status: 0, sandbox: true, no viewUrl;
  • honours apiIdentifier idempotency (alreadyExisted: true on a repeat);
  • fires document.issued webhooks with "sandbox": true and an sbx_… document id;
  • bypasses the dormant-account refusal.

Also in sandbox: inbound store orders from a Shopify or Wix hook produce a fake SBX- document too (the order log shows it as issued with an sbx_… id), and refunds go through the same path. The MCP issue_document tool is refused in a sandbox account (drafts are still allowed); use create-document to test issuing.

What is not evaluated in sandbox: rules that need stored documents or the full engine — credit-note/receipt reference checks, payments = total, subject/customerName presence, currency/exchange-rate rules. A payload that passes sandbox can still be refused by production with a 422, so also run your final request through POST /calculate and review the validation table.

Unaffected: POST /calculate, GET /documents, GET /customers, POST /customers behave as in production (the demo customers are real cards in the sandbox business; GET /documents does not list SBX- documents).

Toggle protection#

A developer sandbox cannot turn sandbox mode off — the dashboard toggle refuses with a Hebrew message. To issue real documents, open a normal business at /signup.

Test-fire a connector#

The dashboard's connector screens (/billing/ecommerce) have a "שליחת הזמנת בדיקה" button that pushes a realistic sample order (for example a Shopify orders/paid) through the real receiver in-process, signed with your saved secret. In a sandbox account it produces an SBX- document. Real platforms post to the hookUrls above.

  1. Open a sandbox, keep the apiKey in your secret store.
  2. Build against baseUrl; use POST /calculate to check your totals.
  3. Register a webhook endpoint (/billing/settings/webhooks) and use "שליחת אירוע בדיקה", then issue SBX- documents to see live events.
  4. Switch to a real business's key when you go live: same code, only the key (and base URL, if different) changes.
Sandbox — SLK Invoices API