SyyniProvenance by construction
YrityslistatPäättäjälistatJulkisen sektorin päättäjälistatHinnastoPalvelutMerkkivalvontaKetkä mainitsevat meidät?HakusanahakuKustomoitu datanhakuAnalyysityökaluKohderyhmäraporttiRatkaisutKaikki ratkaisutMyyntijohdolleMarkkinoinnilleRiskienhallintaanStrategiaanHankintaanYrittäjälleJulkiselle sektorilleSijoittajalleTelemarkkinointiinSähköpostimarkkinointiinPaperiseen suoramarkkinointiinAineistoSähköpostilistatPäättäjälistatYrityslistatAineisto ja lähteetToimialatKunnatKonkurssitAmmattinimikkeetRajapintaDevelopers (API-dokumentaatio)YritysTietoa meistäBlogiVastuullisuusYhteystiedotKäyttöehdotSopimusehdotTietosuojaselosteEvästeetUlkoasu

Developers › Authentication

Authentication

One mechanism: a bearer token in the Authorization header. There is no OAuth flow, no session and no signup form — keys are issued by us.

http
GET /api/v1/companies?municipality=091 HTTP/1.1
Host: syynilabs.fi
Authorization: Bearer syyni_live_Xk3nP9qR2vT8wZ5yB1cF4hJ7mN0sD6gA

Key format

A key looks like syyni_live_ followed by 32 characters. The first eight characters after the prefix are the key prefix: we store them in clear text so we can identify a key without knowing it. You will see the prefix in our admin view and can quote it in support requests — it is not a secret, and it is safe to log.

The rest is stored only as a scrypt hash. We cannot recover your key, and neither can anyone who reads our database. If you lose it, we rotate it.

Two environments

The prefix tells you which one you are holding: syyni_live_ is production and bills, syyni_test_ is the sandbox and never does. A key keeps its environment for life — a sandbox key cannot be promoted, and production keys are issued separately, so nothing you do while testing can start charging you.

The prefix must match the key. Sending a sandbox secret with the syyni_live_ prefix returns 401 unauthorized rather than quietly working — that mismatch almost always means a key was copied into the wrong environment's configuration.

Where not to put the key

  • Not in a query parameter. The API rejects keys passed any way other than the header. Query strings end up in browser history, proxy logs and shared links, and they are the most common way a key leaks.
  • Not in browser code. CORS allows browser calls because blocking them would protect nothing — but anything shipped to a browser is public. Call the API from your server.
  • Not in a repository. Read it from the environment; every example on this site does.

Rotation

Ask us and we issue a new secret for the same key. The old one stops working immediately — there is no overlap period, so schedule it. Your usage history and current billing period are unaffected, because the key keeps its identity; only the secret changes.

Pausing and revocation

A key can be paused or closed, and the difference matters:

  • Paused is reversible. Calls return 403 key_paused. We use it when something needs to stop quickly — a suspected runaway loop, an unpaid invoice, or because you asked.
  • Closed is permanent. Calls return 403 key_revoked, and the key can never be reopened or rotated. This is the correct action for a leaked key, and it is why it cannot be undone.

Account state

Billing is monthly in arrears, so a credit decision is required before the first billable call. Until it is in place, a valid key returns 403 customer_not_approved. If you see that code on a key that used to work, it is an account matter and not a technical one — write to us.

Multiple keys

Ask for as many as you find useful: one per environment, one per integration, one per team. Limits, spend caps and usage are tracked per key, so separate keys make it possible to cap a test environment without touching production — and to close one without disrupting the rest.

The 30-day free repeat window is also per key. If two keys fetch the same row, both pay; if you want to share a cache, share the key.

Error reference →

Aloita kohderyhmän rajaus