Fixing Session Expired Errors
Why sessions expire in Trust Leads, what the error looks like, and how to resolve it.
Why Sessions Expire
Trust Leads uses short-lived JWT tokens for session management. Access tokens expire after 1 hour. When an access token expires, the system automatically tries to refresh it using a refresh token. If the refresh succeeds silently, you will not notice any interruption. If the refresh fails (e.g. the refresh token was revoked or expired), you will be redirected to the sign-in page.
Refresh tokens expire after 7 days of inactivity. If you do not use the application for more than 7 days, your session will be invalid when you return and you will need to sign in again.
Session Expired After a Long Absence
If you open Trust Leads after not using it for a week or more and see the sign-in page instead of the dashboard, your session has expired. Simply sign in again with your email and password. Your data, job history, and settings are all intact — session expiry does not affect stored data.
If you use Trust Leads daily, you should rarely if ever see session expiry prompts because the refresh token is renewed on each active session. The 7-day expiry only affects users who open the application after an extended absence.
Tip
If you frequently see session expiry prompts while actively using the application, check whether your browser is blocking cookies for trustleads.ai. Session tokens are stored in HttpOnly cookies, which require cookie access to function. Verify that your browser privacy settings or extensions (like ad blockers) are not blocking first-party cookies.
SESSION_EXPIRED Error in the API
If you are using the API with a JWT session token (not an API key), you may see a 401 response with error code SESSION_EXPIRED. This is a sign that you should switch to API key authentication for server-side integrations — JWT tokens are designed for browser sessions, not server-to-server calls.
Switch to creating an API key at /app/api-keys and use the lfk_ prefixed key in your API calls. API keys do not expire and are the correct credential type for all programmatic access.
# Wrong — using a JWT token in server-side code (will expire)
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
# Correct — using a long-lived API key
Authorization: Bearer lfk_sk_your_api_key_hereWas this guide helpful?