Quickstart

From a key to a customer that Kleos can tell you the truth about, in four requests.

1. Get a key

Sign in to console.kleos.click and create a test key. Choose the permissions you actually need — the console lists them in plain English next to their code names. The secret is shown once; it is stored hashed and nobody at Kleos can read it back to you.

2. Check it works

curl https://api.kleos.click/v1/me \
  -H "Authorization: Bearer kls_test_..."

This needs no permission beyond a valid key, so it is the fastest way to tell a typo apart from a permissions problem. The response tells you which account the key belongs to, which mode it is in, and what it may do.

3. Create a customer

curl https://api.kleos.click/v1/customers \
  -H "Authorization: Bearer kls_test_..." \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: signup-8842" \
  -d '{
    "external_ref": "crm-8842",
    "name": "Vandeputte Plumbing",
    "country": "BE",
    "timezone": "Europe/Brussels",
    "website_url": "https://vandeputte.be"
  }'

external_ref is your own id for them. Send it and you never have to store ours: every endpoint that takes a customer id takes your reference just as happily.

4. Ask what is in the way

curl https://api.kleos.click/v1/customers/crm-8842/readiness \
  -H "Authorization: Bearer kls_test_..."

You will get ready_for_live_calls: false and a list of coded blockers. That is the correct answer on day one, and it is the same list the call endpoint would refuse on — so you can build your onboarding UI against it immediately and trust it later.

Then what

• Test mode — what is real and what is suppressed.
• Going live — clearing the blockers.
• Your brand — making the whole thing read as you.