Ana içeriğe geç

API Portal Login Logs

Info

The API Portal Login Logs page allows portal administrators to view and analyze all user login attempts, successful and failed logins, IP addresses, and error messages in detail. This page is a critical tool for security monitoring, user activity tracking, and system health analysis.

For per-portal database and external connector settings for login logs, see Login Log Connector Configuration (Portal Settings → Login Log tab).

These are developer/portal-user sign-in and sign-out records only. Administrator sign-ins to the Management Console have their own, separate screen — see Login Records — and never appear here.

What are API Portal Login Logs?

API Portal Login Logs, is an audit system that maintains detailed records of all login attempts to the API Developer Portal. Through this system, you can:

  • User Login Activity: Track when each user logged in and from which IP address
  • Security Monitoring: Detect suspicious activities, failed login attempts, and potential security threats
  • System Analysis: Analyze portal usage statistics, login trends, and system health
  • Compliance: Store and report log records for legal requirements

Importance of Login Logs

Security Monitoring

Detect brute force attacks, suspicious IP addresses, and unauthorized access attempts

User Tracking

Monitor user activities, identify most active users, and analyze usage patterns

Troubleshooting

Understand why users cannot log in and quickly provide solutions

Compliance and Audit

Maintain detailed log records to meet legal requirements

Accessing the Page

To access the API Portal Login Logs page, follow these steps:

Login to Manager Interface

Log in to Apinizer Manager interface with administrator privileges

Go to Portal Tab

Click on Portal tab in the top menu bar

Go to API Portal Settings

Click on the relevant portal from the portal list or go to Portal → Settings menu

Access Login Logs Page

Click on "Login Logs" or "Giriş Kayıtları" option from the left menu or settings page

  • Alternatively, you can follow the path: Portal → Accounts/Developers → Login Logs
API Portal Login Logs Screen
API Portal Login Logs Screen

What Can You Do with Login Logs?

Login Tracking

Track when users logged in and from which IP addresses. Analyze login times, frequency, and geographic distribution.

Success Analysis

View whether logins were successful or failed. Calculate success rates and track trends.

Error Review

Review error messages in failed logins in detail. Understand why users cannot log in and resolve issues.

Advanced Filtering

Search and filter by specific user, IP address, or date range to perform detailed analysis.

Security Monitoring

Detect suspicious activities, brute force attacks, and unauthorized access attempts.

User Activity Reporting

Create and share user activity reports for specific periods.

Filtering and Search Features

The Login Logs page offers various options to filter and search records. These features allow you to quickly access the information you need from thousands of records.

1. Setting Login Date and Time Range

You can set a date range to filter user login or transaction activities within a specific period. This feature is very useful for analyzing activities in a specific period.

Date Range Filtering Features:

FeatureDescription
Start Date (From)Select the start date for filtering. Records before this date are not shown.
End Date (To)Select the end date for filtering. Records after this date are not shown.
Date FormatDate format: YYYY-MM-DD (Example: 2025-01-15)
Time SupportTime information can also be selected in the date picker (optional)
Select Start Date

Enter the start date you want to filter in the From (Start Date) field or select it from the date picker.

Example: 2025-01-01 - Shows records from January 1, 2025 onwards

Select End Date

Enter the end date you want to filter in the To (End Date) field or select it from the date picker.

Example: 2025-01-31 - Shows records up to January 31, 2025

Apply Filtering

After selecting the date range, the system automatically applies the filter or click the "Apply" / "Filter" button.

View Results

Only records within the specified date range will be displayed in the table. Records outside the date range are hidden.

Tip

Performance Tip: When selecting date range, a maximum 90-day period is recommended for performance. Pagination is used for longer periods.

Info

When no date range is selected, the system displays the last 30 days of records by default. This optimizes page load performance.

2. Search by Email Address

You can search by email to examine a specific user's activities. This feature is very useful for seeing a user's complete login history.

email(string)

You can search by entering the user's email address in the Search by email field. With this filtering, only records belonging to the relevant user will be listed.

Email Search Features:

FeatureDescription
Exact MatchYou must enter the complete email address (partial search is not supported)
Case InsensitiveEmail address is not case sensitive
Automatic FilteringFiltering is automatically applied when email is entered

Example Usage Scenarios:

User Login History Check

To check a user's last login time and successful/failed login attempts:

  • Email: john.doe@example.com
  • Date Range: Last 30 days
  • Result: All login attempts for the user are listed
Account Lockout Issue Investigation

To understand why a user's account was locked:

  • Email: user@example.com
  • Status: FAILURE
  • Result: Failed login attempts and error messages are displayed

Example Email Addresses:

  • john.doe@example.com
  • developer@company.com
  • test.user@apinizer.com

3. Search by IP Address

You can use IP-based search to filter by the IP address from which login was made. This feature is critical for security analysis and suspicious activity detection.

ipAddress(string)

Enter the relevant IP address in the Search by IP address field. This displays activities from a specific IP.

IP Address Search Features:

FeatureDescription
IP FormatIP address in IPv4 format (Example: 192.168.1.100)
Exact MatchYou must enter the complete IP address
Multiple ResultsAll login attempts from the same IP are listed
Warning

Security Warning: A large number of failed login attempts from the same IP address in a short time may be a sign of a potential brute force attack. In this case:

  • Block the IP address
  • Inform the user
  • Notify the security team
  • Add additional security layers

IP Address Analysis Scenarios:

Suspicious IP Detection

To examine all login attempts from a specific IP address:

  • IP Address: 192.168.1.100
  • Date Range: Last 7 days
  • Result: All login attempts from this IP are listed
Info

If there are many failed attempts from this IP, security measures should be taken.

Geographic Distribution Analysis

To analyze access from different IP addresses:

  • Search each IP address separately
  • Compare successful and failed login rates
  • Detect suspicious locations

Example IP Addresses:

  • 192.168.1.100 (Local network)
  • 10.0.0.50 (Private network)
  • 203.0.113.45 (Public IP)

Table Columns and Information

The Login Logs table displays the following information. Each column provides different information about the login attempt.

Table Structure

ColumnDescriptionFormatExample
StatusResult of the operation (Success/Failed)BadgeSUCCESS, FAILURE
EmailEmail address of the user attempting to log inStringuser@example.com
Account NameUser's account nameStringJohn Doe
DateDate and time when the operation occurredDateTime2025-01-15 14:30:25
EventThe specific session event this row records — sign-in, sign-out, or an account disabled by the inactivity job. See Event Types below. Rows written before this column existed show the event derived from Status (Success → Login Succeeded, Failure → Login Failed).Translated labelLogin Succeeded
ReasonFor a failed sign-in (and for the inactivity job's disable event), a machine-readable code for why. Empty on a successful sign-in or sign-out. See Reason Codes below.Translated labelWrong email or password
IP AddressIP address where the operation was performedString192.168.1.100
User AgentThe browser/client User-Agent string sent with the request, capped at 256 characters. Empty on rows written before this column existed.StringMozilla/5.0 (Windows NT 10.0; Win64; x64) ...
MessageError message or operation detailsStringAuthentication failed -> DISABLED

Status

The Status column in the table indicates the result of the operation. This column shows whether the login attempt was successful or failed.

SUCCESS(badge)

Successful: The operation was completed successfully. The user entered the correct email and password and logged into the portal.

When It Appears:

  • When user logs in with correct email and password
  • When account is active and approved
  • When email verification is completed

Message: When Status is SUCCESS, the Message column is usually empty.

FAILURE(badge)

Failed: The operation failed. Failed login attempts, authorization errors, or other operation errors appear in this status.

When It Appears:

  • When wrong password is entered
  • When account is disabled
  • When email verification is not done
  • While waiting for admin approval
  • When account is rejected

Message: When Status is FAILURE, a detailed error message is displayed in the Message column.

Message

Error or warning messages related to failed operations are located in this column. These messages explain why the user could not log in.

Message Column Features:

StatusMessage ContentDescription
SUCCESS(Empty)Messages are usually empty for successful logins
FAILUREError messageDetailed error message is shown for failed logins
Info

Error messages in the Message column are very important for troubleshooting and user support. By carefully examining these messages, you can quickly resolve user issues.

Email

email(string)

Email: The email address of the user on whom the operation was performed. This is the email address the user uses to log into the portal.

Email Column Features:

  • Email address is displayed in full
  • You can filter all records for that user by clicking on this column
  • Email address is used to identify the user

Account Name

accountName(string)

Account Name: The user's account name or display name. This is the name defined in the user's profile.

Account Name Column Features:

  • User's full name or display name is shown
  • Unlike email address, it provides a more readable identity
  • May be empty in some cases (if user name is not defined)

Date

date(datetime)

Date: The date and time when the operation occurred. This shows the exact time of the login attempt.

Format: YYYY-MM-DD HH:mm:ss

Example: 2025-01-15 14:30:25

Date Column Features:

  • Date and time information is displayed in full
  • Time information shows the exact time of the login attempt
  • Records are listed in date order (newest at top)

IP Address

ipAddress(string)

IP Address: The IP address where the operation was performed. This is the IP address of the device or network from which the user logged in.

Format: XXX.XXX.XXX.XXX (IPv4)

Example: 192.168.1.100

IP Address Column Features:

  • IP address is shown in IPv4 format
  • You can filter all login attempts from that IP by clicking on this column
  • Critical information for security analysis
Warning

Where this address comes from — and when it can be trusted. The value recorded here is the client address the API Portal resolved for the browser session, read from the X-Forwarded-For header of the request that reached the portal and then forwarded to Apinizer. It is therefore only as trustworthy as the network in front of the portal:

  • If the API Portal is published through a reverse proxy or ingress that overwrites X-Forwarded-For with the address of the connection it accepted, this column shows the real client address.
  • If the portal is reachable directly, or sits behind a proxy that only appends to the header, any client can send an X-Forwarded-For of its choosing and that value is what appears here — as well as in the SIEM event (actor.ip) and in anything keyed on it, such as brute-force correlation or a block list.

Run the API Portal behind a proxy that overwrites the header, and do not expose it directly.

Event Types and Reason Codes

Every row carries an Event — which session event this is — and, for a failure or a system-initiated disable, a Reason. Both are also the field names an external SIEM destination sees for this stream; see SIEM & Log Forwarding.

Event types

EventMeaningStatus
Login SucceededA developer signed in successfully.SUCCESS
Login FailedA sign-in attempt was rejected — see the Reason column for why.FAILURE
LogoutA developer signed out.SUCCESS
Account DisabledThe account was disabled — today, only by the inactive-account job (Reason: Account inactive for too long).SUCCESS
Account LockedThe account was locked after too many failed sign-in attempts — see Password Policy & Account Lockout.FAILURE
Account UnlockedAn administrator cleared a lockout from Accounts/Developers — row Unlock. Never written when a lock simply expires on its own, or when re-approving a Disabled account happens to clear the same state; only the explicit Unlock action produces this row.SUCCESS
Password ChangedThe account's password was changed — self-service, by an administrator, via a reset link, or because a forced/expired password had to be replaced. See the Reason column for which.SUCCESS
Password Change RequiredWritten alongside a successful Login Succeeded row whenever the sign-in that just occurred must be followed by a password change before anything else can be done.SUCCESS
Password Reset RequestedA "forgot password" reset e-mail was requested for the account.SUCCESS
Password Policy ViolationA password submitted at registration, self-service change, reset, or an administrator's save did not meet the portal's password policy and was rejected. The password value itself is never recorded — only which rule it broke.FAILURE

Reason codes

Shown for Login Failed, Account Locked, Account Unlocked, Password Changed, Password Change Required, Password Policy Violation, and the automatic Account Disabled event; empty for a plain Login Succeeded, Logout, or Password Reset Requested row.

EventReason codeMeaning
Login FailedWrong email or passwordThe e-mail exists but the password did not match.
Login FailedAccount disabledThe account's status is Disabled — by an administrator, or by the inactive-account job. No longer written for a lockout: a locked account rejects the attempt with Account locked below instead.
Login FailedAccount not approvedThe account exists but has not been approved yet, for a reason other than the two below.
Login FailedEmail confirmation neededThe account was registered but its e-mail address has not been confirmed.
Login FailedWaiting for approvalRegistration requires administrator approval and it has not happened yet.
Login FailedAccount rejectedAn administrator rejected the registration.
Login FailedNo account with this emailNo account exists with the e-mail address that was submitted.
Login FailedAccount belongs to another portalThe e-mail and password are valid, but for an account registered on a different portal — portal accounts are isolated per portal.
Login FailedAccount lockedThe attempt was refused because the account is already locked — the password is never even compared. A burst of these, right after a burst of Wrong email or password, is someone still guessing after the lock took hold.
Account DisabledAccount inactive for too longWritten by the inactive-account job, never on a login attempt.
Account LockedFailed-attempt thresholdThe configured Max Failed Login Attempts was exceeded.
Account UnlockedAdministratorThe only reason code this event produces — it is always an explicit administrator action.
Password ChangedChanged by the account holderSelf-service change from the account's own profile/settings screen.
Password ChangedChanged by an administratorAn administrator set the password from Accounts/Developers.
Password ChangedChanged via a password reset linkCompleted through a "forgot password" e-mail link.
Password ChangedChanged after a forced expiryThe account signed in with an expired or administrator-forced password and changed it as required, before doing anything else.
Password Change RequiredPassword expiredPassword Validity Period has been exceeded.
Password Change RequiredReset by an administratorForce Password Change After Administrator Reset applied the last time an administrator set this account's password.
Password Policy Violation(the violated rule's name)One of the policy's own field names — minimum/maximum length, a required character class, the minimum number of character classes, or password history reuse. The submitted password is never written anywhere.

API Portal Login Error Messages

Users attempting to log into the API Portal may fail for various reasons. Below, all possible error conditions and their meanings are explained in detail.

1. Waiting for Admin Approval (WAITING_FOR_APPROVEMENT)

When It Appears:

  • User has registered on the portal
  • Has verified email address
  • But admin has not yet approved the account
  • Portal Settings → Security → "Auto Approve Account" = PASSIVE

Error Message:

Authentication failed -> WAITING_FOR_APPROVEMENT

Message Shown to User: "Your account is waiting for administrator approval. You will be able to log in after approval."

Solution:

  • Portal administrator should approve the user from Portal Management → Developer Accounts section
  • Or activate the "Auto Approve Account" feature in Portal Settings → Security
Info

This is part of the manual approval process. Users cannot log into the portal while waiting for admin approval.

2. Email Verification Not Done (CONFIRMATION_NEEDED)

When It Appears:

  • User has registered on the portal
  • But has not clicked the link in the email to verify email address
  • If email verification is required

Error Message:

Authentication failed -> CONFIRMATION_NEEDED

Message Shown to User: "Please verify your email address. You can verify your email address by clicking the link in the registration email."

Solution:

  • User should click the verification link in the email received during registration
  • If email did not arrive, can use "Resend Email" feature
Warning

Users cannot log into the portal without email verification. This is an important step for security.

3. Account Disabled (DISABLED)

When It Appears:

  • Manually disabled by an administrator
  • Automatically disabled by the inactive-account job after too many days without a sign-in

Error Message:

Authentication failed -> DISABLED

Message Shown to User: "Your account has been disabled. Please contact the administrator."

Solution:

  • Portal administrator can re-approve the account from Portal → Accounts/Developers
  • User can request account activation by contacting the administrator
Info

Too many wrong passwords in a row no longer disables the account — it locks it instead (see the next entry), which is independent of this Disabled status and does not need an administrator's re-approval unless Lock Duration is set to unlimited.

3b. Account Locked (LOCKED)

When It Appears:

  • The account went over the portal's Max Failed Login Attempts (5 by default) in a row

Error Message:

Authentication refused -> the account is locked

Message Shown to User: "Your account has been locked due to too many failed sign-in attempts."

Solution:

  • Wait for Lock Duration to pass, if the portal has a non-zero one configured
  • Otherwise ask a portal administrator to click Unlock on Accounts/Developers
Warning

Automatic lockout is a security measure against brute force attacks, not a punishment for the account holder — a correct password submitted while the account is locked is still refused, without being compared, so it is never counted as a fresh failed attempt. Full configuration: Password Policy & Account Lockout.

4. Application Rejected (REJECTED)

When It Appears:

  • User's registration application has been rejected by admin
  • Admin has rejected the user from Portal Management → Developer Accounts section

Error Message:

Authentication failed -> REJECTED

Message Shown to User: "Your account application has been rejected. Please contact the administrator for detailed information."

Solution:

  • User can make a new application
  • Or contact the administrator to get information about the rejection reason
Info

Rejected accounts remain in the system but cannot log into the portal. Administrator can approve the account again if necessary.

5. Account Not Approved (NOT_APPROVED)

When It Appears:

  • Account has not passed the approval process
  • Email verification is done but admin approval is pending
  • Or auto approval feature is passive and admin has not yet approved

Error Message:

Authentication failed -> NOT_APPROVED

Message Shown to User: "Your account has not yet been approved. Please wait for the approval process to complete."

Solution:

  • Portal administrator should approve the account
  • Or activate the "Auto Approve Account" feature in Portal Settings → Security
6. Wrong Password

When It Appears:

  • When user enters wrong password
  • Email address is correct but password is wrong

Error Message:

Authentication failed after 1 failed sign-in attempts

Message Shown to User: "Email or password is incorrect."

⚠️ Important Security Mechanism:

Each wrong password increases the account's failed-attempt count by one; a correct password resets it to zero. The attempt that pushes the count past the portal's Max Failed Login Attempts (5 by default, configurable per portal) locks the account immediately — the attempt that only reaches the limit does not lock it. Once locked, every further attempt is refused as Account Locked above without comparing the password at all, so it is not counted as another failed attempt.

Solution:

  • User should enter the correct password
  • If forgot password, can use "Forgot Password" feature
  • If the account is locked, wait for Lock Duration to pass or ask an administrator to Unlock it
Warning

Automatic Account Lockout: the exact threshold and lock duration are configured per portal — see Password Policy & Account Lockout.

7. User Not Found (Account Not Found)

When It Appears:

  • Entered email address is not registered in the system
  • User has not yet registered on the portal
  • Email address was entered incorrectly

Error Message:

Authentication failed -> account not found

Message Shown to User: "No user registered with this email address was found. Please check your email address or register."

Solution:

  • User should check the email address
  • If not registered, should register by clicking "Register" button
  • If entered email incorrectly, should enter the correct email address
✅ 8. Successful Login (Success)

When It Appears:

  • When email and password are correct
  • When account is active and approved
  • When email verification is completed
  • When admin approval is given (if required)

Error Message: None (message is empty)

Status: SUCCESS

Shown to User: User is redirected to the portal home page and has successfully logged into the portal.

Info

Successful logins are displayed with SUCCESS status in Login Logs. These records are important for user activity tracking.

📋 Error Messages Summary Table

The following table summarizes all error conditions and solutions:

StatusWhenError MessageShown to UserSolution
WAITING_FOR_APPROVEMENTWaiting for admin approvalAuthentication failed -> WAITING_FOR_APPROVEMENT"Your account is waiting for administrator approval"Admin should approve account
CONFIRMATION_NEEDEDEmail not verifiedAuthentication failed -> CONFIRMATION_NEEDED"Please verify your email address"Click email verification link
DISABLEDManual, or inactivity jobAuthentication failed -> DISABLED"Your account is disabled"Admin should activate account
LOCKEDToo many wrong passwords in a rowAuthentication refused -> the account is locked"Your account has been locked"Wait for Lock Duration, or admin Unlock
REJECTEDApplication rejectedAuthentication failed -> REJECTED"Your account application has been rejected"New application can be made
NOT_APPROVEDNot approvedAuthentication failed -> NOT_APPROVED"Your account has not yet been approved"Admin should approve account
Wrong PasswordPassword wrongAuthentication failed after N failed sign-in attempts"Email or password is incorrect."Enter correct password
Account Not FoundEmail not foundAuthentication failed -> account not found"No user found with this email"Register or check email
SuccessfulEmail+password correct(empty)Redirect to home page-

Usage Scenarios and Examples

You can perform analysis and troubleshooting in various scenarios using the Login Logs page. Below, the most common usage scenarios are explained in detail.

Scenario 1: User Activity Check

To check a user's login activities and learn their last login time:

Select Date Range

Select date range to check a specific user's login activities:

  • From: 2025-01-01 (Start date)
  • To: 2025-01-31 (End date)
Info

You can use the default date range to see last 30 days of activity.

Filter User

Enter the user's email address in the Search by email field:

  • Example: john.doe@example.com

The system automatically filters all records for this user.

Review Results

You can see the following information in the table:

  • Last Login Time: Date and time of the last successful login
  • Login Frequency: How often the user logs in
  • Success/Failure Rate: Percentage of successful ones in total login attempts
  • IP Addresses: Which IP addresses the user logged in from
Tip

You can easily distinguish successful (SUCCESS) and failed (FAILURE) logins from the Status column.

Detailed Analysis

Analyze the user's activity pattern:

  • Which hours are more active?
  • Which IP addresses are they logging in from?
  • Are there failed login attempts?
  • When was the last login?

Scenario 2: Failed Login Analysis and Troubleshooting

To analyze failed login attempts and resolve user issues:

Apply Status Filter

To see only failed logins in the table:

  • Look at the Status column and examine records with FAILURE status
  • Or narrow down failed logins with date range and email filter
Info

Failed logins are marked with a red FAILURE badge.

Review Error Messages

Analyze failure reasons from the Message column:

Common Error Types:

  • WAITING_FOR_APPROVEMENT → Waiting for admin approval
  • CONFIRMATION_NEEDED → Email not verified
  • DISABLED → Account disabled (admin, or the inactive-account job)
  • LOCKED → Account locked by the failed-attempt threshold
  • Wrong Password → Wrong password
Warning

Immediate intervention may be required for accounts in DISABLED or LOCKED status.

Provide User Support

Apply appropriate solution according to error type:

Waiting for Admin Approval:

  • Go to Portal Management → Developer Accounts section
  • Find the user and click [Approve] button

Email Not Verified:

  • Tell user to resend email verification link
  • Or you can skip email verification as admin

Account Locked:

  • Go to Portal Management → Developer Accounts section
  • Find the user and activate the account
  • You can send password reset link to the user

Wrong Password:

  • Recommend user to use "Forgot Password" feature
  • Or perform password reset as admin
Trend Analysis

Analyze failed login trends:

  • Are there continuous failed attempts for a specific user?
  • Are there many failed attempts from a specific IP address?
  • Did the number of failed attempts increase in a specific time period?
Tip

This analysis helps you detect security threats and system issues early.

Scenario 3: Security Violation Detection and Prevention

To detect suspicious activities and take security measures:

IP-Based Search

View all logins from a suspicious IP address:

  • Enter IP address in the Search by IP address field
  • Example: 192.168.1.100

The system lists all login attempts from this IP.

Check Failed Attempt Count

Check if there are many failed login attempts from the same IP:

Suspicious Activity Indicators:

  • 10+ failed attempts in a short time (e.g., within 1 hour)
  • Attempts made with different email addresses
  • Systematically increasing attempt count
Warning

Brute Force Attack Indicator: A large number of failed login attempts from the same IP in a short time may be a sign of a potential brute force attack. In this case, immediate security measures should be taken.

Take Security Measures

When suspicious activity is detected:

1. Block IP Address:

  • Block IP address from firewall or security settings
  • Or apply IP restriction at API Gateway level

2. Protect User Accounts:

  • Check affected user accounts
  • If necessary, make password change mandatory

3. Notify Security Team:

  • Inform security team about suspicious activity
  • Share log records with security team

4. Additional Security Layers:

  • Add CAPTCHA
  • Apply rate limiting
  • Make two-factor authentication (2FA) mandatory
Reporting and Documentation

Document security incidents:

  • Record suspicious IP addresses
  • Note incident time and details
  • Document measures taken
  • Create regular security reports

Scenario 4: System Health and Performance Analysis

To analyze portal login statistics and evaluate system health:

View General Statistics

Analyze general statistics for a specific period:

  • Total Login Attempts: Total number of login attempts made
  • Successful Login Rate: Percentage of successful logins
  • Failed Login Rate: Percentage of failed logins
  • Most Active Users: Users who log in most frequently
Trend Analysis

Analyze trends over time:

  • Daily/weekly/monthly login counts
  • Changes in success rate
  • Peak hours (busiest login hours)
  • Seasonal or periodic changes
Performance Metrics

Evaluate system performance:

  • Average login success rate
  • Most common error types
  • User satisfaction indicators

Best Practices and Recommendations

Follow these recommendations to use the Login Logs page effectively:

Regular Review

Review Login Logs regularly (daily or weekly). Detect suspicious activities early.

Automatic Alerts

Set up automatic alerts for critical security events (e.g., 10+ failed attempts).

Log Retention

Retain logs for sufficient period for compliance requirements (e.g., 90 days, 1 year).

Reporting

Create and share regular security and usage reports.

User Education

Inform users about secure password usage and login security.

Security Policies

Create and implement security policies (e.g., password complexity, 2FA).

Important Reminders

Warning

Repeated Wrong Passwords = Automatic Lockout

An account is automatically locked — not disabled — after too many wrong passwords in a row. The threshold (5 by default) and how long the lock lasts before opening on its own are configured per portal; see Password Policy & Account Lockout. This is a critical security measure against brute force attacks.

Administrator Action:

  • Regularly check locked accounts on Accounts/Developers
  • Inform users about account lockout
  • Unlock the account if necessary — no need to re-approve it, a lock does not touch Enabled/Disabled status
Info

Log Retention

portal_login_logs is not deleted automatically by default — the collection keeps growing until you turn on Portal Login Logs cleanup under Administration → Auditing & Compliance → Application Log Cleanup Tasks (off, and 30 days once enabled, are only the defaults; both are configurable). While the setting stays off, nothing here is ever deleted, regardless of how far back you keep browsing.

Different retention periods may be required for different industries once you do enable it:

  • General: 90 days
  • Finance: 1 year or longer
  • Healthcare: According to legal requirements
  • Public: According to legal requirements
Tip

Regular Reporting

Create regular reports to track security and usage trends:

  • Daily: Critical security events
  • Weekly: General activity summary
  • Monthly: Detailed analysis and trend report
  • Yearly: Annual security and usage report

Conclusion

The API Portal Login Logs page is a powerful tool for monitoring portal security, tracking user activities, and analyzing system health. By using this page regularly, you can:

✅ Detect security threats early
✅ Quickly resolve user issues
✅ Optimize system performance
✅ Meet compliance requirements
✅ Perform detailed analysis and reporting

User Tracking

Track all user login attempts in detail and analyze most active users

Security Monitoring

Quickly detect suspicious activities and security violations, monitor failed login trends

System Analysis

Report portal login statistics, performance metrics, and system health

Compliance

Store log records and create regular reports to meet legal requirements

Geographic Distribution

Analyze access from different IP addresses and location-based activities

Automatic Protection

Ensure security with automatic, per-portal-configurable account lockout after repeated wrong passwords