Developers › Sandbox

Sandbox

A sandbox key lets you build the whole integration — filters, pagination, field groups, error handling — against real data, without being billed for anything. Ask for one and you can start the same day.

What is the same

Everything except the size of the register. Same base URL, same parameters, same validation, same error codes, same response shape including the billing block. Code that works against the sandbox works against production without changes — that is the entire point of having one.

What is different

The data is real

Sandbox companies are genuine Finnish companies with genuine phone numbers, addresses and named decision-makers. That is deliberate. Generated data would look tidier than the register actually is, and you would discover the difference in production: real titles are messy, some rows have a name and no role, some email addresses are derived from a pattern rather than published. You should meet all of that while it costs nothing.

The set spans dozens of industries and most regions, so filters return meaningful results — but it is fixed and small, so it is a place to test rather than a source of data.

Counts match rows

The sandbox restricts the whole register, not just the rows you fetch. A count in the sandbox tells you how many sandbox companies match — it will not promise 9 713 and then hand you three. If your code compares a count to the number of rows it received, that check keeps working.

curl -H "Authorization: Bearer $SYYNI_SANDBOX_KEY" \
  "https://syynilabs.fi/api/v1/companies/count"

{
  "companies": 100,
  "decision_makers": 877,
  "companies_with_decision_makers": 100,
  "billing": { "cost": "0.00", "currency": "EUR",
               "note": "Counts are free.", "mode": "sandbox" }
}

Billing responses still tell you the truth

A sandbox response carries the full billing block with mode: "sandbox" and cost: "0.00", but rows_billed and the per-group breakdown are computed exactly as in production. Use them to estimate what a run will cost before you point the same code at a live key.

"billing": {
  "mode": "sandbox",
  "note": "Sandbox key: nothing is charged. rows_billed shows what this call would have cost in production.",
  "rows_returned": 50,
  "rows_billed": 50,
  "cost": "0.00",
  "currency": "EUR",
  "vat": "excluded",
  "field_groups": {
    "core":  { "billed": 50, "empty": 0,  "free_repeat": 0 },
    "phone": { "billed": 41, "empty": 9,  "free_repeat": 0 }
  }
}

In this example 41 of 50 rows would have been charged for the phone group and 9 would not, because they had no number. Multiply by the unit prices on the pricing page to get the production figure.

Moving to production

1. 1

   Swap the key

   Replace the syyni_test_ key with your syyni_live_ key. No other change is needed.

2. 2

   Check your first response

   The billing.mode field disappears and cost becomes a real number. If it is still sandbox, you are using the wrong key — that is what the visible prefix is for.

3. 3

   Start small

   Run one page with a small page_size and read the billing block before you loop. Your key has a monthly spend cap; ask us to set it where a runaway loop would stop rather than surprise you.

Keys are not swapped in place: a sandbox key stays a sandbox key for its whole life, and production keys are issued separately. Nothing you do in the sandbox can start charging you by accident.