Testing with the live demo

A complete, public implementation of the Account Connect endpoints runs on our servers with fictional customers. Every request on this page works exactly as written — copy it into a terminal and run it.
7 min readhttps://www.siluxchat.comcurl · Python · PHP · Node.js

Overview

The demo behaves like a real customer system with two deliberate differences: the one-time code is always 123456, and no text message or email is ever sent. Use it to learn the flow, to test your HTTP client, and to see Auto Trainer’s chained test pass in your own dashboard before your endpoints exist.

What you will run
verify-identity  {full_name + postcode/email/mobile}  → otp_token      (code "sent" — really 123456)
verify-otp       {otp_token, otp_code: "123456"}      → session_token  (valid 30 minutes)
account-summary  {session_token}                      → account
orders           {session_token}                      → orders[]
invoices         {session_token}                      → invoices[]

Demo details

SettingValue
Base addresshttps://www.siluxchat.com/api/account-connect-demo/v1
API key headerX-API-Key
API keydemo-account-connect-key
One-time code123456 (never sent)
Code lifetime10 minutes
Session lifetime30 minutes

Test customers

NamePostcodeEmailMobileAccountData
Test CustomerTE5 7STtest@example.com07700900000C1001Business Phone Line, £19.95/month, balance £0.00; one dispatched order (ORD-50231, Royal Mail Tracked 48); two paid invoices
Jane DemoSW1A 1AAjane.demo@example.com07700900001C1002Unlimited Calls Bundle, £29.95/month, balance £29.95; no orders; one unpaid invoice (INV-7790, £29.95)

Match on the full name plus any one of the postcode, email or mobile. Case and spaces are ignored, so test customer / te57st also match.

The same test customer everywhere

Test Customer / TE5 7ST / code 123456 is also the customer your own Account Connect implementation must recognise — it is how the dashboard tests your chain without texting anyone.

End-to-end scripts

Each script verifies a customer, exchanges the code for a session and reads the account, orders and invoices. All four were run against the live demo before publishing. The bash version uses python3 to read JSON; substitute jq -r .otp_token if you prefer.

Full verification and account read
#!/usr/bin/env bash
set -euo pipefail
BASE=https://www.siluxchat.com/api/account-connect-demo/v1
KEY=demo-account-connect-key

# 1. Verify identity: full name + one more detail
OTP=$(curl -s -X POST "$BASE/verify-identity" \
  -H "X-API-Key: $KEY" -H "Content-Type: application/json" \
  -d '{"full_name":"Test Customer","postcode":"TE5 7ST"}' \
  | python3 -c 'import sys,json; print(json.load(sys.stdin)["otp_token"])')
echo "otp_token: ${OTP:0:24}..."

# 2. Verify the one-time code (always 123456 in the demo)
SESSION=$(curl -s -X POST "$BASE/verify-otp" \
  -H "X-API-Key: $KEY" -H "Content-Type: application/json" \
  -d "{\"otp_token\":\"$OTP\",\"otp_code\":\"123456\"}" \
  | python3 -c 'import sys,json; print(json.load(sys.stdin)["session_token"])')
echo "session_token: ${SESSION:0:24}..."

# 3. Read the verified customer's data
for EP in account-summary orders invoices; do
  echo "== $EP"
  curl -s -X POST "$BASE/$EP" \
    -H "X-API-Key: $KEY" -H "Content-Type: application/json" \
    -d "{\"session_token\":\"$SESSION\"}"
  echo
done
Output (bash version)
otp_token: eyJrIjoib3RwIiwiYyI6IkMx...
session_token: eyJrIjoic2Vzc2lvbiIsImMi...
== account-summary
{"success":true,"account":{"account_number":"C1001","status":"active","plan":"Business Phone Line — 12 months","monthly_price":"£19.95","contract_end":"2027-03-31","balance_due":"£0.00","name":"Test Customer"}}
== orders
{"success":true,"orders":[{"order_number":"ORD-50231","placed":"2026-09-20","status":"dispatched","courier":"Royal Mail Tracked 48","tracking":"TT123456789GB"}]}
== invoices
{"success":true,"invoices":[{"invoice":"INV-7781","date":"2026-09-01","amount":"£19.95","status":"paid"},{"invoice":"INV-7702","date":"2026-08-01","amount":"£19.95","status":"paid"}]}

Step by step

1. Verify identity

curl -s -X POST "https://www.siluxchat.com/api/account-connect-demo/v1/verify-identity" \
  -H "X-API-Key: demo-account-connect-key" \
  -H "Content-Type: application/json" \
  -d '{"full_name":"Jane Demo","email":"jane.demo@example.com"}'
Response (200)
{
  "success": true,
  "otp_token": "eyJrIjoib3RwIiwiYyI6IkMxMDAyIiwiZXhwIjoxNzkwNDE2NTc2LjIyOTcxNjN9.962dec66dc64f449593e38db62894354",
  "message": "Code sent to mobile ending 001"
}

2. Verify the code

# export OTP=<otp_token from step 1>
: "${OTP:?export OTP first}"
curl -s -X POST "https://www.siluxchat.com/api/account-connect-demo/v1/verify-otp" \
  -H "X-API-Key: demo-account-connect-key" \
  -H "Content-Type: application/json" \
  -d "{\"otp_token\":\"$OTP\",\"otp_code\":\"123456\"}"
Response (200)
{
  "success": true,
  "session_token": "eyJrIjoic2Vzc2lvbiIsImMiOiJDMTAwMiIsImV4cCI6MTc5MDQxNzc3Ni4yNTc3NTE1fQ.738a53355bc2bbce104f1f4f422428b9"
}

3. Read the account, orders and invoices

# export SESSION=<session_token from step 2>
# The same body works for /account-summary and /orders.
: "${SESSION:?export SESSION first}"
curl -s -X POST "https://www.siluxchat.com/api/account-connect-demo/v1/invoices" \
  -H "X-API-Key: demo-account-connect-key" \
  -H "Content-Type: application/json" \
  -d "{\"session_token\":\"$SESSION\"}"
/account-summary — Jane Demo
{
  "success": true,
  "account": {
    "account_number": "C1002",
    "status": "active",
    "plan": "Unlimited Calls Bundle — 24 months",
    "monthly_price": "£29.95",
    "contract_end": "2028-01-15",
    "balance_due": "£29.95",
    "name": "Jane Demo"
  }
}
/orders and /invoices — Jane Demo
{"success": true, "orders": []}

{
  "success": true,
  "invoices": [
    {"invoice": "INV-7790", "date": "2026-09-01",
     "amount": "£29.95", "status": "unpaid"}
  ]
}

An empty list is a valid, successful answer: the bot tells Jane she has no orders rather than guessing.

The demo vendor API

Alongside the Account Connect endpoints, the demo exposes a small read-only “vendor” API shaped like a typical shop platform. It is what the Silux Demo Store connector reads, and it is a convenient target for testing your own HTTP tooling. All three are GET requests with the same X-API-Key.

GET/vendor/customers?email=… or ?phone=…X-API-Key

Finds customers by exact email, or by the last 10 digits of a phone number.

curl -s "https://www.siluxchat.com/api/account-connect-demo/v1/vendor/customers?phone=07700900000" \
  -H "X-API-Key: demo-account-connect-key"
Response (200)
{
  "customers": [
    {"id": "C1001", "first_name": "Test", "last_name": "Customer", "email": "test@example.com",
     "phone": "07700900000", "address": {"postcode": "TE5 7ST"}}
  ]
}
GET/vendor/orders?customer_id=…X-API-Key

Orders for a customer ID. An unknown ID returns {"orders": []}, not an error.

curl -s "https://www.siluxchat.com/api/account-connect-demo/v1/vendor/orders?customer_id=C1001" \
  -H "X-API-Key: demo-account-connect-key"
Response (200)
{
  "orders": [
    {"order_number": "ORD-50231", "placed": "2026-09-20", "status": "dispatched",
     "courier": "Royal Mail Tracked 48", "tracking": "TT123456789GB"}
  ]
}
GET/vendor/invoices?customer_id=…X-API-Key

Invoices for a customer ID.

curl -s "https://www.siluxchat.com/api/account-connect-demo/v1/vendor/invoices?customer_id=C1002" \
  -H "X-API-Key: demo-account-connect-key"
Response (200)
{"invoices": [{"invoice": "INV-7790", "date": "2026-09-01", "amount": "£29.95", "status": "unpaid"}]}

The demo connector

To see the complete connector experience — connection test, customer verification and live answers — in your own dashboard:

  1. 1
    Open Dashboard → Integrations → Connectors and search for Silux Demo Store (try it).
  2. 2
    Enter the key demo-account-connect-key and press Connect & test. You should see “Connected — a real call to the vendor worked” with ticks for Verify customers, Orders and Invoices.
  3. 3
    If you have no other customer verification set up, it is used to verify customers automatically; otherwise press Use to verify customers.
  4. 4
    Open your chat widget and ask “have I paid my last invoice?”. Give the name Jane Demo and the email jane.demo@example.com, then the code 123456. The bot reads back the unpaid £29.95 invoice.
  5. 5
    Disconnect it when you have finished so your real system takes over.
The demo connector is the only connector tested live, end to end, by the platform. Every other connector is Documented-API tested, then tested for real against your account when you connect it.

Negative tests

A good integration handles “no” answers as carefully as “yes” answers. All of these were captured from the live demo.

TestStatusResponse
Name only, no second detail200{"success":false,"message":"We could not match those details to an account."}
Right name, wrong postcode200{"success":false,"message":"We could not match those details to an account."}
Wrong code200{"success":false,"message":"That code is not correct."}
Expired or made-up otp_token200{"success":false,"message":"That code has expired — please ask for a new one."}
Missing or wrong X-API-Key401{"detail":{"success":false,"message":"Missing or wrong X-API-Key"}}
Expired or made-up session_token401{"detail":{"success":false,"message":"Session expired — please verify again."}}
Right name, wrong postcode
curl -s -X POST "https://www.siluxchat.com/api/account-connect-demo/v1/verify-identity" \
  -H "X-API-Key: demo-account-connect-key" \
  -H "Content-Type: application/json" \
  -d '{"full_name":"Jane Demo","postcode":"XX1 1XX"}'
Made-up session token (401)
curl -s -X POST "https://www.siluxchat.com/api/account-connect-demo/v1/account-summary" \
  -H "X-API-Key: demo-account-connect-key" \
  -H "Content-Type: application/json" \
  -d '{"session_token":"nope"}'

The demo does not count wrong codes — yours must

The demo’s tokens are signed and stateless, so it cannot count attempts. Your implementation must allow at most 5 wrong codes per otp_token and then refuse it. Connections made through our connectors enforce this for you. See Customer identity verification & OTP.

Pacing and good practice

  • Keep automated tests gentle: a few requests per second at most, and back off if you ever receive 429.
  • Do not load-test the demo. It exists for learning and functional testing.
  • Never put real customer data into the demo — it only knows its two fictional customers.
  • The otp_token and session_token values are opaque: store and send them back exactly, and never parse them. Your own tokens may look completely different.
  • Set a client timeout (15 seconds is what the platform itself uses) and treat a timeout as “can’t check right now”, never as “no account”.

Get help

If a demo request behaves differently from this page, or you would like us to watch a test run against your own endpoints, email support@siluxcall.co.uk.

PreviousAuthenticationNext Customer identity verification & OTP

Need help with your integration?

Our integration team can review your endpoints, help you choose the right connector and check a test run with you. Tell us which system you use and what you would like the bot to answer.

support@siluxcall.co.uk