HTTP Tweak
The panel, partner integrations, and mobile apps share a configuration model but use different request paths and credentials.
From panel to app
| Step | What happens |
|---|---|
| Author | The panel saves one configuration with independent server and tweak records. Client API writes change those same records. |
| Export | The exporter separates public names/routing from protected settings and credentials, then produces app import text. Business generation runs this exporter on in-memory resources. |
| Import | Android and iOS decode the envelope, verify identity and access, and store a local configuration. API authoring JSON is not itself an importable file. |
| Select | The app selects a tweak and filters servers by family, variant, carrier, accepted methods, and category. Even a direct connection needs a tweak with empty methods. |
| Connect | The app combines the selected pair, allowed local edits, and runtime preferences into the tunnel configuration. Remote services and credentials must already work. |
| Update | A saved configuration can deliver a same-key update. A Business generation creates a new identity for a new import. |
Public resource summaries deliberately omit secrets. They are suitable for selection and lists, not for round-tripping a complete connection. Use the Client detail endpoints to edit an owned resource; use exports for app import.
Client API request flow
- Your backend sends a Client API key and a configuration key.
- Middleware checks API availability, platform input, credential status, burst limits, and daily quota.
- The controller checks that the configuration belongs to the credential's owner.
- Validators check metadata and the public connection document. Resource batches run in a database transaction.
- Models save the changes and invalidate the affected configuration cache. Individual mutations return the resource; batch sync returns change counts and resource keys.
- The app obtains updated content through its authenticated fetch/import/update flow when an update source is configured, or through a new export/import. There is no push guarantee from a successful Client API write.
A Client key is account-wide. It is not a per-configuration password and must not be distributed to users who only need to import a configuration.
Saved configuration data
| Record | Relationship and purpose |
|---|---|
users |
Own configurations and API accounts; account limits govern saved resource counts |
client_api_accounts |
One credential account per user; stores key hash, preview, status, optional quota override, and last-used time |
configurations |
Belong to a user; carry a stable unique key, name, message, settings, owner and sharing data |
servers |
Belong to a configuration; store tunnel, carrier, settings, and accepted_methods JSON alongside metadata |
tweaks |
Belong to a configuration; store tunnels, carrier, and methods JSON alongside metadata |
configuration_device_ids |
Per-configuration allowed devices, activation, expiration, and consumption policy |
configuration_passwords |
Per-configuration reusable or one-time passwords and usage metadata |
configuration_blocked_device_ids |
Per-configuration device blocklist used by app access checks |
The API's unique keys are the integration identifiers for configurations, servers, and tweaks. Numeric IDs are used for password and allowed-device record edits. Internal database representation is not a substitute for the documented request body.
Business generation flow
- A separate Business credential authenticates the request against
business_api_accounts. - The account burst limiter runs, then the generation request validates its fields.
- Daily quota is consumed and the generator creates configuration, server, and tweak objects in memory.
- The exporter produces the app's encrypted import format with fresh keys and account-derived ownership.
- Optional Cloud Protect and cloud share delivery run, then the response returns plain text.
business_api_accounts stores credential and account metadata, status, limit overrides, and quota-request review state. Daily usage and rate windows are maintained by quota/cache services, rather than saved configuration rows.
Shares and protection
configuration_shares stores a share identifier, storage location, content hash, expiration, and one-time consumption state. The exported content lives on the configured storage disk. It is a snapshot, not an editable panel configuration.
protected_configuration_exports stores protection material, a configuration key, a key version, and last-imported time. Some records link to a saved configuration; generated exports do not require one. Cleanup policies can remove expired or unused delivery records.
Mobile identity and subscriptions
devices binds a device identity to its platform and signing key material. device_nonces provides short-lived, one-use challenges. Play Integrity sessions bind Android app integrity to the device, app version, and signing key.
Google Play and Apple purchases have separate purchase/entitlement records. Notifications update billing state through provider-authenticated callbacks, while signed app requests read or synchronize their entitlement state.
Public configuration discovery, public server catalogs, promotion campaigns, and analytics are additional platform features. Their routes are not Client API resource-management operations. See the mobile and callback route map.