The Client API works with configurations already saved in your panel account. It can list and delete them, manage their resources and cloud access, and read or change their message. Create configurations and edit configuration-level settings in the panel.
All endpoints on this page require your Client API key. For terminal examples, set API_BASE, CLIENT_API_KEY, and CONFIG_KEY as shown in your first request.
List configurations
GET /api/v1/configs
curl --fail-with-body "$API_BASE/configs" \
--header 'Accept: application/json' \
--header "X-API-Key: $CLIENT_API_KEY"
Returns configurations, total, max_configurations, and remaining_configurations. Each entry includes id, name, unique_key, servers_count, tweaks_count, is_cloud_hwid_lock, is_cloud_password, created_at, and updated_at. The cloud booleans describe whether those access modes are enabled.
The list includes all configurations belonging to the account, ordered by most recently updated, then highest ID. This endpoint does not paginate.
List a configuration's resources
GET /api/v1/configs/{config_key}/resources
curl --fail-with-body "$API_BASE/configs/$CONFIG_KEY/resources" \
--header 'Accept: application/json' \
--header "X-API-Key: $CLIENT_API_KEY"
Returns configuration_id, configuration_name, config_unique_key, servers, and tweaks alongside success and message.
These are summary lists. Connection credentials, full profiles, and method values are omitted. Carrier and method settings may appear as empty objects. Use the individual server or tweak endpoint for editable details; do not submit a summary as a replacement document.
Read the message
GET /api/v1/configs/{config_key}/message
curl --fail-with-body "$API_BASE/configs/$CONFIG_KEY/message" \
--header 'Accept: application/json' \
--header "X-API-Key: $CLIENT_API_KEY"
The message is returned as config_message, with configuration_id, configuration_name, and config_unique_key.
Update the message
PUT /api/v1/configs/{config_key}/message
curl --fail-with-body --request PUT "$API_BASE/configs/$CONFIG_KEY/message" \
--header 'Accept: application/json' \
--header 'Content-Type: application/json' \
--header "X-API-Key: $CLIENT_API_KEY" \
--data '{"message":"Welcome to my configuration."}'
| Field | Required | Meaning |
|---|---|---|
message |
Yes, may be null | Message text; the installation's configured message length limit applies. Send null to clear it. |
Returns the updated config_message and the same configuration identifiers. Text placeholders such as {config_name}, {server_count}, and {server_list} are resolved during export; the message endpoint stores the template.
Message placeholders use curly braces only, such as {config_name}.
Delete a configuration
DELETE /api/v1/configs/{config_key}
This permanently removes the saved configuration and its dependent resources. Only call it when you intend to delete the configuration.
curl --fail-with-body --request DELETE "$API_BASE/configs/$CONFIG_KEY" \
--header 'Accept: application/json' \
--header "X-API-Key: $CLIENT_API_KEY"
Returns success: true, configuration_deleted: true, and a configuration object containing the deleted record's id, name, and unique_key. For multiple configurations, see batch deletion.
Message placeholders
Use these tokens in either a saved configuration message or a Business generation request's message. Placeholders are case-sensitive. Unknown tokens remain unchanged; empty server or tweak lists resolve to an empty string. The Client message endpoint stores and returns the template unchanged. Business generation resolves it before returning encrypted import text.
| Token | Replaced with |
|---|---|
{config_name} |
Configuration name. |
{created_at} |
Creation date and time in YYYY-MM-DD HH:mm:ss format. |
{created_date} |
Creation date in YYYY-MM-DD format. |
{updated_at} |
Last-updated date and time in YYYY-MM-DD HH:mm:ss format. |
{updated_date} |
Last-updated date in YYYY-MM-DD format. |
{server_count} |
Number of servers included in the generated configuration. |
{tweak_count} |
Number of tweaks included in the generated configuration. |
{server_list} |
Server names in alphabetical order, separated by commas. |
{tweak_list} |
Tweak names in alphabetical order, separated by commas. |
Get panel changes into the app
The panel stores the source configuration; an app import stores a local copy. A server or tweak is identified by its own unique_key inside that configuration. Updating an existing key preserves that identity; deleting and recreating without the key creates a different resource.
- Create the configuration in the panel and add its servers and tweaks in the panel or through the Client API.
- In the panel, enable cloud updates if this configuration should follow saved changes. Export the configuration and import it into the app so the update setting is included.
- Change the existing resources through the Client API. Resource changes also update the parent configuration's timestamp and invalidate its cached export.
- Let the app perform its configured update check, or use its update action. Automatic updates depend on app preferences and lifecycle; the API response is not a device delivery receipt.
Without an update source, export and import the changed configuration again. A cloud share is an export snapshot: making a share does not itself enable cloud updates. If you enable updates after distributing a file with updates disabled, distribute a new export containing that setting.
Both Android and iOS require the remote configuration's unique_key to match the imported one. They compare updated_at to detect a change; increasing a displayed revision alone is not the update contract. A custom URL must serve a valid app configuration with the same key, not a Client API resource-list response. Changes to live tunnel settings take effect when the app builds a new connection.
Business generation creates fresh keys and therefore cannot replace this saved-configuration update workflow.