What each log entry shows
Every row in the logs table corresponds to one auth session and includes the following fields:| Field | Description |
|---|---|
| Session ID | The unique identifier for this auth session. Reference this ID when contacting support or correlating with your own server logs. |
| Project | The name of the Bondify project that initiated this session. |
| Telegram user | The user’s display name, @username, and numeric Telegram ID. If the user has not set a username, the username column shows a dash. |
| Status | The current state of the session (see below). |
| Created at | When the session was initiated, displayed as a relative timestamp (e.g., 5m, 2h). |
| Confirmed at | The timestamp when the user approved the request in Telegram. Only present for confirmed and used sessions. |
Session statuses
Each session resolves to one of five statuses, colour-coded for quick scanning:| Status | Colour | Meaning |
|---|---|---|
confirmed | 🟢 Green | The user approved the auth request in Telegram. The session is valid and can be exchanged for a user identity. |
pending | 🟡 Yellow | The auth request has been sent to Telegram but the user has not yet responded. |
expired | 🟠 Orange | The session timed out before the user confirmed. The link or QR code is no longer valid. |
cancelled | 🔴 Red | The user explicitly rejected the request, or your server cancelled the session via the API. |
used | 🔵 Blue | The session was confirmed and subsequently consumed — the auth token has already been exchanged. |
Filtering sessions
Use the filter chips above the table to narrow the list to sessions of a specific status:- All — shows every session regardless of outcome (default).
- Confirmed — successful logins. This filter also surfaces
usedsessions (sessions that were confirmed and subsequently consumed), so you see the full picture of successful authentications in one view. - Pending — sessions still awaiting user action.
- Expired — sessions that timed out.
- Cancelled — sessions rejected or cancelled.
Underlying API
The Logs page is powered by the sessions endpoint. If you want to retrieve session data programmatically — for example to build your own audit tooling or export records — you can call it directly:sessions array. Each element maps directly to the fields shown in the dashboard table: id, project_id, project_name, telegram_id, telegram_name, telegram_username, status, created_at, and confirmed_at.
Debugging with logs
If users report authentication problems, the logs page is the fastest place to start your investigation:- Filter by
expired— a high proportion of expired sessions usually means users are not receiving the Telegram message. Verify your bot is active and that no Telegram API rate limits are in effect. - Filter by
cancelled— if users are cancelling, they may be confused by the confirmation prompt or reaching the wrong bot. Double-check your project’s bot mode and the message text your integration sends. - Look for
pendingsessions that never progress — if sessions stay pending indefinitely, your webhook may not be reachable. Confirm your webhook URL returns200 OKand is not behind a firewall or VPN. - Cross-reference
confirmed_at— compare thecreated_atandconfirmed_attimestamps to measure how long users take to confirm. Unusually long gaps may point to UX friction in your auth flow.
Log retention depends on your Bondify plan. Starter plans retain 7 days of session logs; Pro plans retain 90 days. Sessions older than your plan’s retention window are permanently removed and cannot be recovered. Upgrade your plan before the window expires if you need long-term audit records.
Related
Projects
Manage the projects that generate the sessions you see in your logs.
Analytics
See aggregated conversion rates and daily activity across all your projects.