Transport configuration

Server connection settings are described by the ChatTransportConfig model.

Detailed configuration

init(rest: String, webSocket: String, dataStore: String, dataStoreHTTPHeaders: [String: String]? = nil, newRoutesEnabled: Bool = true, apiVersion: APIVersion = .api17)

For full address configuration (for example, in-house installations) specify the URLs of the main server components:

Field	Type	Required	Description
rest	String	Yes	REST API URL of the backend (for example, https://your-host.edna.io)
webSocket	String	Yes	WebSocket gateway URL (for example, wss://your-host.edna.io/socket)
dataStore	String	Yes	Files and media storage URL (for example, https://your-host.edna.io/files)
dataStoreHTTPHeaders	[String: String]?	No (default nil)	HTTP headers for DataStore. After init stored as public var [String: String] (non-optional) — assign [:] to clear
newRoutesEnabled	Bool	No (default true)	Use the new REST endpoint path for message history. Set to false for servers with legacy routing
apiVersion	APIVersion	No (default .api17)	Backend API version. See the API versions table below

let chatTransportConfig = ChatTransportConfig(
    rest: "https://your-host.edna.io",
    webSocket: "wss://your-host.edna.io/socket",
    dataStore: "https://your-host.edna.io/files"
)

Cloud constructor

init(cloudHost host: String, apiVersion: APIVersion = .api17)

For cloud edna Chat Center customers a simplified constructor is available — only the host name is required:

Field	Type	Required	Description
cloudHost	String	Yes	Host name in name.edna.io format (without https://)
apiVersion	APIVersion	No (default .api17)	Backend API version

let chatTransportConfig = ChatTransportConfig(cloudHost: "your-host.edna.io")

The SDK builds the addresses automatically:

• REST: https://{host}
• WebSocket: wss://{host}/socket
• DataStore: https://{host}/files

Where to get connection parameters

Connection addresses and providerUid are issued during integration. If you don't have them — contact support@edna.io.

Invalid cloudHost fails silently

If cloudHost is given a string from which a valid URL cannot be built (typo, empty string, invalid characters), the SDK initializes without an explicit error, but authorize and all network requests fail silently — with no delegate events.

Validate cloudHost during testing and log chatTransportConfig.debugDescription right after creation. With a valid host the output is:

newRoutesEnabled: true
apiVersion: api17
dataStoreHTTPHeaders: [:]
restURL: https://your-host.edna.io
webSocketURL: wss://your-host.edna.io/socket
dataStoreURL: https://your-host.edna.io/files

With an invalid host the output contains file:// in restURL / webSocketURL / dataStoreURL — that is the indicator that validation failed.

In the detailed constructor (init(rest:webSocket:dataStore:...)) invalid URLs trigger assertionFailure (process crash) in debug builds. In release builds assertionFailure is silent and the SDK initializes with the same file:// placeholders. The cloud constructor does not crash in either debug or release.

Parameter availability

Parameter	Detailed constructor	Cloud constructor	Mutation after init
rest, webSocket, dataStore	✅ required	built from cloudHost automatically	❌ let, not allowed
apiVersion	✅ optional	✅ optional	✅ public var — mutate on the instance
dataStoreHTTPHeaders	✅ optional	❌ not via init	✅ public var — mutate on the instance
newRoutesEnabled	✅ optional	❌ not via init	✅ public var — mutate on the instance

Example of mutating dataStoreHTTPHeaders after creation via the cloud constructor:

var config = ChatTransportConfig(cloudHost: "your-host.edna.io")
config.dataStoreHTTPHeaders = ["X-Auth": "token"]

API versions

The apiVersion parameter selects the backend API version, which determines the available functionality. Refer to the edna ChatCenter server documentation to determine the required API version:

Value	Version	Functionality
.api17	17	Baseline (ChatCenter 6.x+)
.api18	18	Personal data notifications
.api19	19	Button-based surveys
.api20	20	Client unblock notification (CLIENT_UNBLOCKED)
.api21	21	Survey comments

API version compatibility

For a detailed description of API version compatibility with feature sets, see the edna ChatCenter server documentation.

How to determine the current API version on the server

The SDK does not auto-discover the API version — the client application must know it at build time. Ways to determine the version:

1. Ask edna during integration. Support will inform you of the required APIVersion for your tenant/environment.
2. Server documentation. The edna ChatCenter installation documentation lists the API version supported by the current server release.

What happens on mismatch

The headerdoc of APIVersion states only the general rule: "On mismatch some features may not work or respond with an error." The exact behavior (which endpoints return an error, which silently ignore unknown fields) is defined on the server side — see the edna ChatCenter documentation.

If, after a server upgrade in production, some features stop working — first verify that apiVersion in the SDK has been raised to the matching value and the app has been rebuilt with the new version.

---

Related sections

• Network settings — timeouts and SSL pinning
• SDK configuration — chat feature parameters
• SDK initialization settings — the ChatCenterUISDK constructor
• SDK initialization and setup — full example