Troubleshooting & error reference

Start here

1. 1
   Open Dashboard → Integrations. Each connection shows its status, a tick or cross per capability, and the last error in full.
2. 2
   Press Test (connectors) or Connect & test (Account Connect) to re-run the check with the test customer — nobody is contacted.
3. 3
   Find the exact message in the tables below.
4. 4
   Check your Activity Log: every connect, test and disconnect is recorded.
5. 5
   Still stuck? Email support@siluxcall.co.uk with the connection name and the message (never the key).

HTTP status codes

Verification messages

These are the exact message strings returned by the platform’s connector endpoints (/api/connect/{id}/…). Your own Account Connect implementation should use the same wording; the reference implementations do.

Error body shapes

Normal “no” answers are flat JSON. A 401 raised by the platform is wrapped in FastAPI’s detail envelope. Code that reads the reply should accept both:

{"success": false, "message": "That code is not correct."}

{"detail": {"success": false, "message": "Session expired — please verify again."}}

When you build your own endpoints, either shape is fine for a 401 — the platform acts on the status code.

Dashboard connect errors

Vendor errors

How connection tests work

• When you connect, press Test, or the daily check runs, the platform makes a real, read-only call for every capability using a customer who does not exist: connection-test@example.com, mobile 07700900999.
• Working credentials give an empty answer (or a 404 “not found”), which counts as a pass. Wrong or revoked credentials give a refusal, which counts as a fail.
• The connection shows working if at least one capability passes; the per-capability ticks show exactly which ones work. It shows failing only when none do.
• When the bot’s chained test sends the test customer (Test Customer / TE5 7ST) through a connector, it runs this probe instead of looking anyone up, issues code 123456, and the account endpoints reply with "test": true and no customer data.

Account Connect test failures

Failed steps stay switched off, so the bot never uses a half-working chain. The full specification is in Build your own Account Connect endpoints.

Empty results

“We could not match those details” or an empty list for a customer you know exists usually has one of these causes:

KEY=demo-account-connect-key
V=https://www.siluxchat.com/api/account-connect-demo/v1/vendor

# A customer who isn't there: an empty list, not an error (this is what a passing connection test looks like)
curl -s "$V/customers?email=nobody@example.com" -H "X-API-Key: $KEY"

# The same customer by mobile in international format: phone numbers match on the last ten digits
curl -s "$V/customers?phone=%2B447700900001" -H "X-API-Key: $KEY"

{"customers":[]}
{"customers":[{"id":"C1002","first_name":"Jane","last_name":"Demo","email":"jane.demo@example.com","phone":"07700900001","address":{"postcode":"SW1A 1AA"}}]}

Codes not arriving

• Where it goes: by text to the mobile on the record where your plan includes SMS; otherwise, or if the text cannot be sent, by email to the address on the record. The reply says which (“Code sent by a text to the mobile ending 123”, or a masked email).
• No contact details on the record produce the “no mobile or email” message — add one in your system.
• Old number on file: the code goes to the number your system holds, never one the customer types. Update the record.
• Demo and test customers are never contacted; their code is always 123456.
• Your own endpoints: check your SMS provider’s delivery log and sender-ID rules.

OAuth sign-in results

After signing in with a vendor you are returned to /dashboard?tab=integrations&connector=…:

Daily health check

Every active connection is re-tested once a day. If a connection that was working starts failing — typically a revoked key or an expired sign-in — the account owner receives one email: “Your <Name> connection has stopped working”, with the reason. Until it is reconnected the bot tells customers it can’t check their account right now, rather than implying they have nothing on record.

Diagnostics with curl

Run these against the demo to see correct behaviour, then set BASE and KEY to your own Account Connect address and key and compare.

BASE=${BASE:-https://www.siluxchat.com/api/account-connect-demo/v1}
KEY=${KEY:-demo-account-connect-key}

# 1. Is the platform reachable?  (expect 200)
curl -s -o /dev/null -w "%{http_code}\n" https://www.siluxchat.com/api/connectors/catalogue

# 2. Missing key  (expect 401)
curl -s -w " %{http_code}\n" -X POST $BASE/verify-identity \
  -H "Content-Type: application/json" -d '{"full_name":"Test Customer","postcode":"TE5 7ST"}'

# 3. The test customer  (expect success:true and an otp_token)
curl -s -w " %{http_code}\n" -X POST $BASE/verify-identity -H "X-API-Key: $KEY" \
  -H "Content-Type: application/json" -d '{"full_name":"Test Customer","postcode":"TE5 7ST"}'

# 4. Wrong details  (expect 200 with success:false)
curl -s -w " %{http_code}\n" -X POST $BASE/verify-identity -H "X-API-Key: $KEY" \
  -H "Content-Type: application/json" -d '{"full_name":"Test Customer","postcode":"AB1 2CD"}'

# 5. Unknown or expired code token  (expect 200 with success:false)
curl -s -w " %{http_code}\n" -X POST $BASE/verify-otp -H "X-API-Key: $KEY" \
  -H "Content-Type: application/json" -d '{"otp_token":"expired-or-made-up","otp_code":"123456"}'

# 6. Unknown or expired session  (expect 401)
curl -s -w " %{http_code}\n" -X POST $BASE/orders -H "X-API-Key: $KEY" \
  -H "Content-Type: application/json" -d '{"session_token":"expired-or-made-up"}'

200
{"detail":{"success":false,"message":"Missing or wrong X-API-Key"}} 401
{"success":true,"otp_token":"eyJrIjoib3RwIiwiYyI6IkMxMDAxIiwi…","message":"Code sent to mobile ending 000"} 200
{"success":false,"message":"We could not match those details to an account."} 200
{"success":false,"message":"That code has expired — please ask for a new one."} 200
{"detail":{"success":false,"message":"Session expired — please verify again."}} 401

FAQ

Why does my connection say working when orders show a cross?

A connection is working if any capability passes. Orders failing usually means the key lacks the orders read permission — grant it and press Test.

Will a failed test text or email anyone?

No. Tests use a made-up customer or the test customer, and neither is ever contacted.

The bot asked the customer to verify again mid-conversation.

Sessions last 30 minutes. After that, account endpoints return 401 and the bot starts a fresh verification.

We rotated our vendor key and the bot stopped answering.

Enter the new key: disconnect and reconnect the connector (the old key is destroyed), or re-run Connect & test for Account Connect.

Can I see what the vendor actually returned?

The dashboard shows the last error in full. For your own endpoints, your server logs are the source of truth — log status codes and outcomes, never codes or tokens.

Get help