Login monitor log

Every terminal sign-in is recorded by the trading server that hosts the account, and accepted and rejected attempts are both kept. Use the login monitor log to investigate shared credentials, resold accounts, and access from unexpected locations or devices.

What is recorded

Field	Notes
outcome	succeeded or failed. Rejected attempts are recorded with INVALID_CREDENTIALS.
accessMode	trade for the trading password, read_only for the investor password.
ipAddress	Client address as seen by the trading server.
countryCode	ISO 3166-1 alpha-2 country, when the deployment can resolve one.
deviceId	Stable identifier the terminal generates for one installation.
deviceName, devicePlatform, appVersion	Readable device description reported by the terminal.
userAgent	Raw user agent of the sign-in request.
resumed	true when the terminal signed in with a saved session instead of a password.
occurredAt	When the server recorded the attempt.

Saved-session sign-ins are recorded too. A terminal that never signs out still appears in the log, which is usually the interesting case.

Read the log

Two endpoints expose the log. Both require accounts:read.

GET /api/v1/management/servers/{serverId}/accounts/{accountNumber}/logins returns the newest-first page of attempts for one account, read from the server that hosts it.

GET /api/v1/management/servers/{serverId}/logins returns a recent-activity feed for every account on a server. This feed is kept in Koneth Main, not on the server, so its entries survive independently of the account’s own data. It accepts accountNumber, outcome, since, and limit filters.

# Everything that touched one account
curl "https://api.koneth.com/api/v1/management/servers/$SERVER_ID/accounts/$ACCOUNT_NUMBER/logins?limit=50" \
  -H "Authorization: Bearer $MANAGEMENT_KEY"

# Rejected attempts on the whole server in the last day
curl "https://api.koneth.com/api/v1/management/servers/$SERVER_ID/logins?outcome=failed&since=2026-09-14T00:00:00Z" \
  -H "Authorization: Bearer $MANAGEMENT_KEY"

Signals worth alerting on

• One deviceId or ipAddress used by many accounts.
• One account accessed from many countries in a short window.
• Repeated failed attempts for an account number, which usually means a guess or a stale saved password.
• Sign-ins outside the account’s normal working hours.

Correlate deviceId with ipAddress rather than relying on either alone: mobile networks change address often, and several traders can share one office address.

Country resolution

The server stores the country from an upstream country header when the deployment provides one (cf-ipcountry, x-country-code, or x-vercel-ip-country). Trading servers behind a plain HTTPS proxy set no such header, so the address is otherwise resolved through a geolocation lookup: the sign-in is recorded with the country of the address it came from, without any operator setup.

Set IP_GEO_LOOKUP_URL to resolve through a service of your own. Set it to off on a deployment that would rather not send trader addresses to a lookup service, and countryCode stays null. Either way the IP address is still recorded. Loopback and private addresses never resolve to a country, and a lookup failure never blocks a sign-in.

What the terminal reports

The Koneth Terminal sends a device identifier it generates on first launch and stores locally, together with the platform, operating system version, and app version. The identifier is not an advertising identifier (IDFA or GAID), a vendor identifier (IDFV), or a hardware serial, so it requires no tracking permission.

Note

The log contains personal data. Retrieve it only for a documented operational or security purpose, restrict the Management API keys that can read it, and include the practice in your organization’s privacy notice.