The betaStats endpoint provides an aggregated view of a Free Fire player's gameplay performance. Instead of returning general account information, this endpoint is specifically designed to expose statistical data collected across supported match types. The response can contain separate statistics for Solo, Duo, and Squad gameplay, allowing applications to present a complete competitive profile or focus on a single game mode.
Each mode contains both high-level performance counters and a detailed statistics object. High-level counters describe the overall number of matches played, kills, and wins, while the detailed statistics provide deeper information such as total damage, deaths, distance travelled, headshot activity, item pickups, vehicle kills, survival time, top placements, knockdowns, and teammate revives where those values apply.
The endpoint is intended for applications that need structured gameplay statistics for player profiles, ranking systems, analytical dashboards, comparison tools, leaderboards, and other Free Fire integrations. The response is returned as JSON, making it suitable for browser applications, mobile applications, backend services, Discord bots, dashboards, and other systems capable of processing HTTP API responses.
The endpoint supports both complete statistics lookups and mode-specific lookups. A complete request returns the available statistics for every supported mode, while the optional stat parameter can be used to reduce the response to Solo, Duo, or Squad only. This makes the endpoint flexible for applications that either require a full player profile or only need one particular mode.
The betaStats service is exposed through a dedicated statistics endpoint. The player UID, developer credentials, region, and optional statistic mode are provided through the request parameters.
Complete GET request:
Filtered GET request:
The same endpoint also accepts POST requests with a JSON request body. POST requests are useful when the calling application already works with structured request payloads or when credentials and parameters should be supplied in the request body rather than appended to the URL.
The following parameters control the player lookup, developer authentication, regional resolution, and statistics filtering.
- uid - Required. The Free Fire player UID whose statistics should be retrieved.
- useruid - Required. The HL Gaming developer account UID used for authentication.
- api - Required. The API key associated with the developer account.
- region - Optional. The regional server code used when resolving the requested player.
- stat - Optional. Selects a single statistics mode instead of returning all supported modes.
The uid, useruid, and api parameters are required for every successful request. The region and stat parameters are optional, so an application can perform a standard lookup without them or provide both parameters for a more targeted request.
Supported region values are:
The endpoint supports three statistics modes. These values are used through the optional stat parameter when a request should return only one mode.
solostats represents the player's Solo statistics. Because Solo gameplay does not use teammate revival or knockdown mechanics in the same way as team modes, Solo responses do not include the knockdown and revives fields.
duostats represents the player's Duo statistics. In addition to the common match and gameplay counters, Duo data can include knockdowns and teammate revives.
quadstats represents the player's Squad statistics and provides the same general statistics structure as Duo, including knockdowns and revives where those values are available.
When stat is omitted, the endpoint returns all three supported mode objects together. When a valid mode is supplied, only that mode is returned.
The statistics response is divided into general mode-level counters and a nested detailedstats object. This structure keeps frequently used values such as matches, kills, and wins easy to access while grouping the larger collection of advanced gameplay measurements inside one dedicated object.
- accountid - Player account identifier associated with the statistics record.
- gamesplayed - Total number of completed matches recorded for the mode.
- kills - Total kills recorded for the mode.
- wins - Total wins recorded for the mode.
- detailedstats.damage - Total cumulative damage dealt.
- detailedstats.deaths - Total recorded deaths or eliminations suffered.
- detailedstats.distancetravelled - Total distance travelled in the upstream service's native measurement.
- detailedstats.headshotkills - Number of kills attributed specifically to headshots.
- detailedstats.headshots - Total registered headshot hits.
- detailedstats.highestkills - Highest number of kills achieved in a single match.
- detailedstats.pickups - Total number of item pickups.
- detailedstats.roadkills - Total vehicle-related kills.
- detailedstats.survivaltime - Cumulative survival time measured in seconds.
- detailedstats.topntimes - Number of matches ending within the tracked top-placement bracket.
- detailedstats.knockdown - Number of opponents knocked down in applicable team modes.
- detailedstats.revives - Number of teammate revives in applicable team modes.
Applications should treat detailed fields as numeric values and should not assume that every field exists in every mode. In particular, knockdown and revives should be handled as optional fields when processing Solo statistics.
A successful unfiltered request returns a top-level source, an endpoint identifier, the main result object, and a usage object. The result.meta object identifies the player and region associated with the statistics snapshot.
The meta.fetchedAt value identifies when the underlying statistics snapshot was generated, while meta.region and meta.uid provide the resolved player and regional context for the response.
Mode filtering is useful when an application displays one statistics category at a time. Instead of downloading the complete Solo, Duo, and Squad dataset, the client can specify the required mode using the stat parameter.
Solo request:
Duo request:
Squad request:
A filtered response places the selected mode directly inside the result object rather than wrapping it inside playerStats.
Every request must include a valid useruid and api credential pair. These values identify and authenticate the developer account making the request. The player uid is separate from the developer credentials and identifies the Free Fire account whose statistics are being requested.
The betaStats endpoint is restricted to developer accounts on an Essential plan or higher. Free-tier accounts, active Trial accounts, and accounts without an applicable paid plan are rejected even when the daily request quota has not been exhausted.
Plan validation is performed after the developer credentials are checked and before a plan-restricted request is counted against the daily API usage. Applications should therefore distinguish plan errors from authentication errors and quota errors rather than treating every failed request as the same condition.
Statistics responses are cached server-side for five minutes. The cache is associated with the requested player UID, region, and selected statistic mode, so separate combinations are treated as separate cached lookups.
When a request is served from cache, the returned source value identifies the cached response:
Cached responses preserve the previously generated statistics snapshot until the applicable cache window expires. Applications that require fresh upstream information should avoid repeatedly polling the same player and mode within the five-minute cache period.
Successful responses also contain a usage object showing the developer account's current daily usage.
Cache hits still count toward the account's daily request usage according to the endpoint's usage rules.
Applications should inspect both the HTTP status code and the structured JSON response when handling errors. The endpoint exposes different responses for malformed parameters, failed authentication, unavailable plans, quota exhaustion, missing players, upstream failures, and unexpected server errors.
Missing required parameters - HTTP 400
Invalid stat mode - HTTP 400
Invalid region - HTTP 400
Authentication failed - HTTP 403
Plan upgrade required - HTTP 402
Daily quota exceeded - HTTP 429
Player not found in region - HTTP 404
Upstream service failure - HTTP 502
Internal server error - HTTP 500
For application logic, stable error_code values such as PLAN_UPGRADE_REQUIRED and QUOTA_LIMIT_REACHED should be preferred over parsing human-readable error messages.
A typical integration should validate the required developer credentials and player UID before sending a request. The application should then optionally attach a region and statistic mode depending on the information it needs to display. Once the JSON response is received, the client can read the selected mode's counters and detailed statistics directly from the returned object.
Applications should not assume that every statistics mode contains exactly the same fields. Solo statistics do not include team-oriented values such as knockdown and revives, so client-side code should check for those fields before attempting to render them.
Applications that repeatedly display the same player's statistics should account for the five-minute cache window. Polling the same player and mode more frequently does not guarantee newer upstream statistics during the cache period. A longer refresh interval can reduce unnecessary requests while still keeping dashboards and profiles reasonably current.
For mobile applications and pages that display only one mode, using the stat filter is preferable to requesting the complete statistics dataset. This produces a smaller response and allows the application to parse a focused object without processing unused modes.
Developer API credentials should be kept private. Applications should avoid exposing permanent API keys in publicly accessible client-side source code whenever the integration architecture allows server-side credential handling.
JavaScript POST example:
betaStats endpoint. Provide your developer UID, API key, Free Fire player UID, and optional statistics filters.
Contact: Developers | Support
