Frequently Asked Questions

This page organizes the most common issues during integration. Start with the symptom closest to what you see; endpoint schemas, parameters, and complete error lists remain in the reference documentation.

Find By Symptom

What you see	Start here
You do not have an API key and do not know where to create one	The API call does not work yet
Token issuance fails, or requests return 401 / 403	The API call does not work yet
A device is missing, or its state does not look current	Device data does not look right
You want to continuously monitor peripherals, offline state, or power loss	Device data does not look right
A command was accepted, but the device did not respond or timed out	A device operation did not complete as expected
WebSocket cannot connect, disconnects often, or has event gaps	The real-time connection is unstable
You are not sure whether to use REST API or WebSocket	REST API vs WebSocket
Requests return 429, 503, or gateway unavailable	Requests are limited or the service is temporarily unavailable
The issue remains after following the documentation	Prepare troubleshooting details

The API call does not work yet

How do I create an API client and obtain credentials?

Create an API client in the WLTE Developer Console.

1. Sign in to the Developer Console: https://developer.svnwi.com/wlte
2. Open an application and go to API client management.
3. Create an API client and select the minimum permissions required by the integration.
4. Save the generated clientId and clientSecret.

Creating an API client provides a clientId and clientSecret, which are used together to obtain an access token.

clientSecret is displayed only when created or rotated. Store it immediately in server-side secret storage. If it is lost, rotate the secret because the original value cannot be viewed again. See Get API Keys.

Access token issuance fails

Check these items in order:

1. The API client exists and is enabled.
2. clientId and clientSecret belong to the same client.
3. The application and account are active.
4. The URL, method, and request body match Create Access Token.

Do not retry invalid credentials indefinitely, because authentication rate limits may apply.

The response code is AUTH_INVALID

The credentials or their current owner state are invalid. Common causes are incorrect credentials, a disabled or deleted API client, a disabled application, or an invalid account state.

If the secret was recently rotated, verify that you are using the new secret. Branch on code, not message.

The response code is AUTH_SCOPE_DENIED

The API client does not have the permission required by the endpoint. data.requiredScope identifies the missing permission.

Add that permission in the Developer Console, save the change, obtain a new token, and retry. See Permissions.

Can an old token still be used after an API client is disabled or deleted?

No. Protected endpoints validate the current API client, application, and account state instead of checking JWT expiration alone.

New tokens cannot be issued, and existing tokens are rejected after the client is disabled or deleted.

Can clientSecret be stored in a website or mobile app?

No. clientSecret is a server credential. Browser assets, application packages, and client logs cannot protect it reliably.

Keep credentials on a server you control. Do not write clientSecret, access tokens, or WebSocket tickets to frontend code, public repositories, or logs.

Device data does not look right

A device is missing from the device list

First confirm that the device belongs to the current account and that the API client is allowed to access it.

If the device appears in the Developer Console but not in the API, check device grants and the device:read scope. If the cause remains unclear, record the requestId before contacting support.

Device list state does not match the physical device right now

The device list returns device state already synchronized by the platform. It does not actively refresh every physical device for each list request and is intended for list views, dashboards, and bulk reads.

For an explicit user refresh or before and after an operation, use Get Device or a WebSocket status request.

Can I poll HTTP frequently for peripheral, offline, or power-loss state?

Not recommended. Peripheral state, offline state, and power-loss notifications are real-time-oriented data. Tight HTTP polling increases device refresh pressure and is more likely to hit rate limits.

Recommended approach:

1. Use List Devices for device lists, dashboards, and background synchronization.
2. Use Get Device or WebSocket device.state.get when a user explicitly refreshes one device detail page.
3. Use WebSocket events for continuous monitoring of offline, power-loss, and peripheral-state changes; after reconnecting, confirm critical state again with HTTP or device.state.get.

Do not call the real-time refresh endpoint every few seconds for every device. It does not guarantee lossless event delivery and may affect other normal requests under the same account.

deviceType is UNSUPPORTED

The platform does not yet provide a usable device type definition for that device. The device may still belong to the account, but clients must not assume its state schema or control capabilities are available.

Do not infer capabilities from the device ID prefix.

How do I know whether a device supports an operation?

Read List Device Type Definitions and inspect capabilities.supportedOperations.

Only listed operations should be displayed or called. For example, do not show RS485 transceive unless device.rs485.transceive is present.

A device operation did not complete as expected

The response is COMMAND_ACCEPTED, but the device has not moved

COMMAND_ACCEPTED means the platform accepted the request. It does not mean the device completed the operation.

Use the command status: SUCCESS means the device confirmed the operation; TIMEOUT means no final confirmation arrived in time. Use Get Command Result when recovering an earlier command state.

The command is TIMEOUT. Did the device definitely not execute it?

Not necessarily. The device may not have received the command, or it may have executed it while the confirmation was delayed or lost.

Do not repeat the command blindly. Read current device state first, especially for operations that are unsafe to duplicate.

The response code is COMMAND_REJECTED

Check two things first:

1. The device type definition includes the requested operation.
2. Parameters match the device capability, such as a valid relay index.

If both are correct, check device connectivity and the underlying device path.

Should a retry use a new Idempotency-Key?

Reuse the original key when retrying the same business operation after a network failure. Different devices, target states, or business operations require different keys.

Do not use one fixed key for all requests. See HTTP Behavior.

The real-time connection is unstable

WebSocket cannot establish a connection

Confirm that the access token is valid, then create a new wsTicket. A ticket is short-lived and single-use and should not be cached or reused.

Check Create WebSocket Ticket, then Establish Connection.

How should the client recover after a disconnect?

Reconnect with backoff and create a new ticket for every new connection. After reconnecting, reload required state instead of assuming events from the disconnected period will be replayed completely.

See Heartbeat and Reconnection.

Events are duplicated, or some events appear to be missing

Event handling must be idempotent. WebSocket notifies clients about changes and should not be the only permanent state source.

After a page reload, reconnect, or detected state gap, query state through REST API or a WebSocket status request to establish a new baseline.

Requests are limited or the service is temporarily unavailable

The response is HTTP 429

Stop immediate retries. Read Retry-After and retry after the allowed time. Coordinate backoff across service instances to avoid another synchronized burst.

Real-time refresh and device control are more strictly limited than snapshot queries. See Rate Limits and Retries.

The response is 503 or GATEWAY_UNAVAILABLE

The real-time device path is temporarily unavailable. Record the requestId and retry a limited number of times with backoff.

If the condition persists, stop retrying and prepare troubleshooting details for support.

Prepare troubleshooting details

If the issue remains, collect:

Information	Example or guidance
requestId	Request trace ID from the API response
API client ID	Never include clientSecret
Request method and path	GET /wlte/v1/devices
UTC timestamp	Exact time of the issue
HTTP status and business code	For example, 403 / AUTH_SCOPE_DENIED
Sanitized parameters	Remove passwords, tokens, and personal information

Then submit the issue through Contact Support.