Directs the user to a download link where he/she can download the latest version of the client application. The resource specifies whether the download is for the installer or the updater.

Gets the latest version number of the client app.

Requests player summary information. The response contains basic information about the user as well as all free statistical information and a small number of most recent tournament results.
The optional mode parameter introduces a flexible "versus User" functionality. There are three mode options: "vsuseronblocked", "normal", and "vsuser". If the user has set up a personal user group containing their players in various networks and there is a player specified for the network of the searched player, the default mode is "vsuseronblocked", otherwise the mode is set to normal in all cases.
If the user is blocked under the vsuseronblocked mode, only the tournaments where the player has played against the user are included. In "vsuser" mode there are two player response elements, one for the all tournaments (if the player is not blocked) and one for the tournaments against the user (if possible).
By default if the player is a group then the group inherits the most restrictive opt out mode of its members. E.g. if there is an opted out player in the group then the whole group is considered opted out and that player must be removed from the group to be able to view that groups statistics. Likewise if a member of the group is not opted in on PokerStars, then the financial statistics for that group will not be viewable until that player is removed or opts in. To exclude blocked or not opted in players from the group results to avoid this issue, use groupsExcludeOptedOut=true and/or groupsExcludeNotOptedIn=true.

Requests a specific number of recent tournaments. The response contains only up to the number of tournaments requested. The number of tournaments requested and the ordering is defined in the “order” parameter which is similar to the Limit constraint and takes the same arguments, with one addition: “player” ordering. When requesting tournaments for a group you may use player ordering (e.g. order=player,1~1000) to return the tournaments for each player in order. This is more efficient when requesting a large number of tournaments for a large number of users and you want to perform the request in chunks (i.e. order=player,1~1000 then order=player,1001~2000, etc.).

Requests a specific number of current (registering and running) tournaments. The response contains only up to the number of tournaments requested. The number of tournaments requested is defined in the “limit” parameter which is optional. If no limit is provided, all current tournaments are returned.
NB: You can achieve relative date ranges with the use of both inverted and nonUnknown Resourceinverted Date constrains can be used to. For example to retrieve all active tournaments that start in the next 10 minutes use the filter "Date:0S;Date!:Unknown Resource600S". This filter picks the tournaments that haven't started yet (with the Date:0s) and will start up to 600 seconds from now).

Requests all or a selection of the statistics. The response contains only the statistics requested (could be all) with no recent tournaments.

Requests a specific selection of statistics specified as a comma-separated list in the path parameter. The statistics parameter should contain a comma-separated list of statistic names (e.g., "Profit,Stake,Count"). The response contains only the statistics requested with no recent tournaments.

Requests a list of players starting with the player name (prefix) provided. The response is a SearchSuggestionsResponse.

Gets the user note on the specified player(s). The response contains the new user note.

Sets the user note on the specified player(s). The response contains the new user note.

Deletes the user note on the specified player(s). The response contains the new user note.

Request to opt out a player's statistics. The response contains the success or failure message. If the user has the networkadmin privilege for that network the email parameter is not required and the player is opted out immediately and any existing Optins or Resets are removed. Otherwise a confirmation email is sent to the user and any existing resets must be removed before an opt out can be processed. If no email parameter is supplied the username is used. Players who are on an active leaderboard cannot be Opted Out without the networkadmin privilege Unknown Resource in which case they will be automatically removed from any current leaderboards Unknown Resource but not from historic leaderboards.

Request to opt in a player's statistics and removes any existing resets or opt outs. The response contains the success or failure message. If the user has the networkadmin privilege for that network the email parameter is not required and the player is opted in immediately and all opt outs and resets are removed. Otherwise a confirmation email is sent to the user. The email address provided must be the same as the one used to create any existing opt out or resets. If no email address is supplied the username is used.

Request to reset a player statistics so that they start from a specific date and anything before that date is hidden from all users. The response contains the success or failure message. Resets are restricted to one per network unless the user has the networkadmin privilege for that network. Resets have no effect on leaderboard entries. If a reset exists, a user can only update that reset if the request email address matches the email address that was used to create the reset. Users with networkadmin privilege can update all resets. If no StartDateTime is provided the current date time is used.

Retrieves an image representing a player's current SharkScope status sometimes referred to as an Avatar. The image returned is in SVG format and therefore can be scaled to any size. The graphs can be requested in a range of types from small textUnknown Resourceonly plaques, up to large graphs similar to the profit graph on the SharkScope website.

The following table describes the currently supported graph types:

Graphs can be requested in a specific size although, as this is a vector format, this effect can be reproduced from a single size using the Browser's zoom functionality. The Freshness parameter specifies the interval in seconds after which the underlying data will be refreshed and thus another cost incurred. The default value is 10800 (3 hours). The graphs are currently only displayed in USD currency.

The request retrieves the player object which includes last activity timestamp of the player or group. Only valid for registered users with an active subscription.

The request retrieves the player's timeline with all events.

The request retrieves a player’s timeline event by its ID.

Returns predictions of a player's future performance and recommendations on how to increase profitability. Currency can be optionally provided for recommendations that include a specific currency amount and the timezoneOffset from GMT can be provided to assist recommendations that include the day of the week.

Requests a list of the user’s player groups. The response contains only basic information about the groups and does not include its members (which can be retrieved using 3.4.2). The personal group is not included in this list.

Requests the player group information. The response contains only basic information about the group and its members to allow adding, deleting and modifying group aspects.

Can be used to modify the flags or the name of the group. There are two group flags that can be modified, namely if it is public or private and if it is consolidated or not. If the group is public it appears when searching for groups. Consolidated groups behave as a single player, for example when requesting the summary of a consolidated group you will get all stats of all players consolidated. The values for the public and consolidated path parameters can be y/n or true/false. If any of the parameters missing, invalid or empty it will be ignored.

This request may be used to add a member to a group. If you attempt to add a player that already exists in the group with the same filter an error will be returned. You may add the same player multiple times with different filters to the group.
The request also sets the blog icon flag for the player for personal groups. If no blog icon is specified when adding a player to a personal group the initial value will be false.
A group is created by adding the first member. By default the groups are created as private and consolidated. Use the group modification request (3.4.3) to change these options.

This request may be used to modify the blog icon flag on a player for personal groups only. Note that the blog icon is set for all occurrences of the player in the group.

Removes a player from the group. Players can be removed one at a time. When the last player is removed the group is deleted.

Deletes the Player Group.

Requests a specific tournament by ID. The response contains a single tournament with the requested ID if it exists. If not found, an error response is returned.

If the tournament is a registering tournament and a last update from the previous retrieval is specified the response is a simple generic response with the text "unchanged". This can be used to avoid transferring large amount of data.

By default for multiUnknown Resourceentry tournaments each player's results are combined into a single result row. To return each entry as a separate row use expandMultiEntries=true (please note that not all networks support this parameter and will just return the combined results if not).

Requesting a tournament with the parameter noPlayers=true it will return the tournament element without the player elements.

For large tournaments you may wish to fetch the player entries in chunks using the optional Order parameter, which has the format OrderProperty,FirstRecord~LastRecord,OrderDirection e.g. order=Player,1~25,desc. The OrderProperty can be "Player" or "Position". If Position is request and not valid for that tournament i.e. the tournament is registering then the order will default to Player.

Requests specific number of registering tournaments based on an optional filter. The response contains only up to the number of registering tournaments requested. The number of tournaments requested is defined in the “limit” parameter. If no limit is supplied, all appropriate registering tournaments are returned. The resource accepts multiple networks.

Requests completed tournaments without individual player results but with tournament statistics. This resource will not include any tournaments older than 1 month. The number of tournaments requested and the ordering is defined in the "order" parameter which is similar to the Limit constraint and though the order is limited to First or Last. If no order parameter is provided, the default used is Last,1~10.

Requests player tournament results for up to 2,000 players. This resource is designed to be the most efficient way of retrieving mass player results from a known set of optedUnknown Resourcein players and requires a Commercial Gold Subscription. If no date filter is provided the resource returns data from the last 4 days by default. If a date filter is provided that is not within the last 4 days (21 days for GG networks) the cost of the request is the number of players (up to a maximum of 10) * the number of days in the date range requested.
E.g., if you requested data for 50 players from the 22nd February to 28th February, the cost would be 10 * 6 days = 60 searches.
The players parameter is a newline delimited list of player names.

Requests “bare” tournaments by their IDs. The response contains only the information about the tournaments themselves without any of their tournament entries that contain participant player information. The cost is 1 search for every 100 tournaments returned rounded up to the next hundred (or less depending on the request). For example a request for 101 tournaments will cost 2 searches. The tournaments IDs are provided either as a query parameter (for a GET request) or a form parameter (for POST requests). The IDs can be separated by newlines, commas, semicolons or tabs.
If the network is "any" (*) the tournament IDs are expected to contain the network IDs. The network applies to the IDs following the network ID (e.g. "pokerstars,1234,5678"). This means that the user can provide network/tournamentID pairs:
pokerstars,1234pokerstars.es,4567fulltilt,5678
Alternatively, multiple tournament IDs may be provided for each network:
pokerstars12344567fulltilt5678
… or as a continuous list:
pokerstars,1234,4567,fulltilt,5678
Specifically for PokerStars and its international networks you may use the "allpokerstars" specifier. This translates internally as "all:pokerstars,pokerstarsit,pokerstarsfr,pokerstarses". Note that using network specifiers in any other way is not accepted.
allpokerstars,1234,4567,8901,5432fulltilt,5678
For GET requests the last option is obviously easier.
The first item should be a network ID. Any tournament IDs that exist before the first network ID will be ignored.

Requests a single tournament by ID specifically to obtain the current chip counts of the tournament's players. When the initial REST request is made the tournament id is submitted to the system. Subsequent polling (with the identical request) is then required to check on the status of the submission. A response will contain a RunningChipsTournament with a state attribute of SUBMITTED, ERROR or COMPLETED:

A state of SUBMITTED means that the tournament has been requested or was already requested.

A state of ERROR means that the tournament data was unable to be retrieved.

A state of COMPLETED means that the response is populated with the tournament data.

A completed response contains limited information about the tournament itself but contains the name and chip count for each player in the tournament. The cost is 1 search.
Within the COMPLETED response the players are listed in order by highest to lowest chip counts with knockedUnknown Resourceout players appearing with zero chips and a finishing rank (in ascending rank order).
Not all networks are currently supported but support is onUnknown Resourcegoing. If a request is made for an unsupported network you will receive an immediate error response.
RunningChipsTournaments are cached for 5 minutes; therefore once you have received a response of either COMPLETED or ERROR, a request for the same game, within this time, will return the same data.
We recommend a polling interval of around 10 seconds. Polling should be abandoned if a COMPLETED or ERROR state is not received within 2 minutes.

Example response:

<RunningChipsResponse>
  <RunningChipsTournament network="pokerstars" tournamentId="1568330211" state="COMPLETED" name="$7.00 NL Hold'em [Turbo]" stake="6.45" rake="0.55">
    <players>
      <player name="simal64" chips="5914"/>
      <player name="Roll_Me_Now" chips="5671"/>
      <player name="gaita763" chips="1915"/>
      <player name="ImSingle6" chips="0" position="4"/>
      <player name="fclmdon92" chips="0" position="5"/>
      <player name="BronoCaetino" chips="0" position="6"/>
      <player name="sanrah1" chips="0" position="7"/>
      <player name="Y259066" chips="0" position="8"/>
      <player name="sinsa72" chips="0" position="9"/>
    </players>
  </RunningChipsTournament>
</RunningChipsResponse>

Requests the next chronological completed tournament of the same specific type as the supplied tournament ID. The response contains a single tournament if it exists. If not found, an error response is returned.

Requests the previous chronological completed tournament of the same specific type as the supplied tournament ID. The response contains a single tournament if it exists. If not found, an error response is returned.

Requests the yearly leaderboards by category. The response contains all the leaderboards for the year and category as a hierarchy.

Requests the yearly leaderboards by subcategory. The response contains all the leaderboards for the year and category and subcategory as a hierarchy.

Requests the private leaderboards. The response contains all the private leaderboards as a hierarchy.

Requests the private leaderboards. The response contains all the private leaderboards as a hierarchy.

Requests the yearly leaderboards. The response contains all the leaderboards for the year as a hierarchy.

Requests the yearly leaderboards. The response contains all the leaderboards for the year as a hierarchy.

Requests the network or networks coverage. The response contains all the coverage information for the specified networks. Network can be “*” to denote all networks.

Request to add missing game(s) using the game ids for the Pokerstars network(s). The response contains all the provided Game IDs with status of processed, pending (already reported), error, or existing. If the status is error the actual error message is also included.

The MissingTournamentsResponse contains the following attributes representing numbers of games: total, processed, existing, pending, error. Only relevant attributes appear, e.g. if there are no errors the attribute “error” will not be included. Example:

<MissingTournamentsResponse total=*"20"* processed=*"15"* existing=*"5">*

In the above example, out of 20 game IDs, 15 were processed and 5 already existing. No errors occurred and no pending games were provided. The parent element also contains one MissingTournament element for each game containing a gameID attribute and a status attribute. The status is one of “processed”, “pending”, “existing” or “error”. If the status is “error” then there is also an attribute containing the error details in text.

<MissingTournaments gameID=*"123457820"* status=*"processed" />*
<MissingTournaments gameID=*"12345782a"* status=*"error"*\
`             `error=*"Invalid game ID" />*

Performs a login confirmation. The response only contains the UserInfo element if successful.

Requests the user's preferences.

Requests the user's Blog URL. The blog URL is used only when the user sets up a personal group. The blog URL is then added as a blog icon to selected members of that group. When setting, the value must be URL encoded. To be able to set the blog URL the user must have the appropriate authorization.

Deletes the user's Blog URL. The blog URL is used only when the user sets up a personal group. The blog URL is then added as a blog icon to selected members of that group. When setting, the value must be URL encoded. To be able to set the blog URL the user must have the appropriate authorization.

Requests user-specific metadata information from the server.

Updates the value of one or more user preferences. If the value is empty the preference is removed.

Updates the value of one or more user preferences. If the value is empty the preference is removed.

Requests the user's payments

The optional affID parameter specifies the affiliation ID, the country specifies the user's country (if not specified it is determined by the IP address, and the emailOption parameter (Y/N) specifies if the user should be added to the sharkscope mailing list.
The password passed as part of the authentication should be encoded only once using MD5 and not encoded using the application key as described in section 1.4.

Example:

String password = “ab1234”;
byte[] defaultBytes = password.getBytes();
try {
  MessageDigest algorithm = MessageDigest.getInstance("MD5");
  algorithm.reset();
  algorithm.update(defaultBytes);
  byte messageDigest[] = algorithm.digest();
  StringBuffer hexString = new StringBuffer();
  for (int co = 0; co < messageDigest.length; co++) {
    hexString.append(Integer.toHexString(0xFF & messageDigest[co]));
  }
}

Request to get the saved filter list. The response contains the UserFilters element if there are any saved filters available for the logged in user.

Request to save the filter definition using a filter name. The response contains the UserFilters element.

Request to get the saved filter definition by name. The response contains the UserFilters element if there is any saved filters available by the given name.

Request to delete a saved filter definition. The response contains the UserFilters element.

Request to change the email of a registered user. The response only contains the UserInfo element if successful.

Request to change the password for registered user. The response only contains the UserInfo element if successful.

Requests the user-specific player classes a user. These are the combination of the non-overridden default and user-defined player classes.

Requests the user-defined player classes a user has previously saved.

Creates or modifies a user-defined player class. Also overrides a default player class. Returns the created/modified/overridden player class. The rules parameter is a string of semicolon separated entries of :~ values, one of which can be * for any (see example). The categories parameter is a string of semicolon separated entries and is used for grouping the classes into like groups for the Tournament player class summary field.

Deletes user-defined player class or default player class override and returns the remaining user-defined classes.

Returns, if present, all the reseller information, such as; Reseller packages bought, credit remaining, the discount level, a list of packages that have been assigned to users and a list of subscriptions that are available to purchase (with roleIDs).

Adds a subscription of a given role id to a given user's account, subtracting the cost from the resellers account. If the userEmail address is not found in the system, then an account is automatically created and the subscription assigned to that email.
Returns, if present, all the reseller information, such as; Reseller packages bought, credit remaining, the discount level, a list of packages that have been assigned to users and a list of subscriptions that are available to purchase (with roleIDs).

Sets the permission for a user to use a specific application - with an expiry date. This is for applications that do not have a specific reseller payment system and just give users time-limited permissions. This request can only be called by the designated application user administrator.
The expiry date must be in Unix format i.e. seconds since standard epoch of 1/1/1970. If it is null, the permission does not expire (i.e. it is perpetual).
You can set the expiry to any date in the future. The GenericReponse returned just contains the expiry date. If the permission is perpetual the text “Perpetual” is returned in the GenericResponse.

Gets the expiry for a user's permission to use a specific application. This is for applications that do not have a specific reseller payment system and just give users time-limited permissions. This request can only be called by the designated application user administrator.
The expiry date will be returned in Unix time format i.e. seconds since standard epoch of 1/1/1970. If the permission is perpetual the text “Perpetual” will be returned in the response. If the user does not have permission to use the application the text “No Permission” will be returned.

Deletes the permission for a user's permission to use a specific application. This is for applications that do not have a specific reseller payment system and just give users time-limited permissions. This request can only be called by the designated application user administrator.
The request returns “No Permission” in a GenericResponse i.e. the same response a GET would return for a user with no permission. If the deletion failed the text is “Unknown”.

The request allows the user to retrieve all user notes they have attached to players. It also allows setting, updating or deleting notes for players.
In the case of updating the notes post parameter should contain lines of text. The first line should be the network name, the second line should be the player name and the following lines should contain the notes. A line containing only a dot (‘.’) character denotes the end of the notes. If the notes are empty – i.e. the dot line is the only line any notes already assigned to the player will be deleted. Otherwise the notes will replace the notes already assigned to players.

The request allows the user to retrieve all user notes they have attached to players. It also allows setting, updating or deleting notes for players.
In the case of updating the notes post parameter should contain lines of text. The first line should be the network name, the second line should be the player name and the following lines should contain the notes. A line containing only a dot (‘.’) character denotes the end of the notes. If the notes are empty – i.e. the dot line is the only line any notes already assigned to the player will be deleted. Otherwise the notes will replace the notes already assigned to players.

Sets the manager account for the user. Managers are able to see the user's email address, subscription status and view and reset their personal player names.

Removes any existing manager the user has assign on their account

Sets the secondary manager account for the user. Managers are able to see the user's email address, subscription status and view and reset their personal player names. This feature is only for subscribers.

Removes any existing secondary manager the user has assign on their account

Returns the user's search usage history, broken down by date, network and action. Note this resource only updates every few minutes so please allow time for the latest usage to appear. Each request costs 1 search to prevent this resource from being overloaded.

Produces a report for market share by region.
Type can be SNGEntrants or MTTEntrants. The year and month parameters specify the date for the market share report. If no year or month is specified the current year and month are used. If only year is specified, all the year is included in the report. If only month is specified, that month from all available years will be included.

Similar to Market Share (by region) Report but the report is produced for the provided network.
See Market Share (by region) Report for information on parameters.

Produces a report for hourly scheduled tournaments for a specific region.
The request returns a number of HourlyMarketShare elements with the following attributes: structure, stake, region, rake, network, hour, game, flags, entrants, date, currency, avduration. The value of the element itself is the hourly market share.
Example:

<HourlyMarketShareResponse>
<HourlyMarketShare structure="NL" stake="0.4" region="IT" rake="0.1" network="MicroGame" hour="0" game="H" flags="T" entrants="6.0" date="2015-02-10" currency="EUR" avduration="1376">3</HourlyMarketShare>
<HourlyMarketShare structure="NL" stake="0.4" region="IT" rake="0.1" network="MicroGame" hour="0" game="H" entrants="9.0" date="2015-02-10" currency="EUR" avduration="3141">1</HourlyMarketShare>
<HourlyMarketShare structure="NL" stake="0.4" region="IT" rake="0.1" network="MicroGame" hour="0" game="H" flags="ST" entrants="12.0" date="2015-02-10" currency="EUR" avduration="1775">3</HourlyMarketShare>
</HourlyMarketShareResponse>

Produces a report for daily scheduled tournaments for a specific network.
This is similar to the same report by region; see Daily Scheduled Tournaments Report (by region) for information on parameters.

Produces a report listing the daily scheduled tournaments for a specific date and region.
The request returns a number of ScheduledTournament elements with the following attributes: structure, stake, region, rake, prizePool, avAbility, numRebuys, network, name, id, guarantee, game, flags, entrants, date, and currency. It excludes all tournaments under $5 and all Satellite tournaments with a stake under $15.
The last 3 days of data are available to all Commercial Gold subscribers and above. The date parameter uses the Pacific Time Zone.
Example:

<DailyScheduledTournamentResponse>
<ScheduledTournament structure="NL" stake="225.00" region="IT" rake="25.00" prizePool="14850.0" avAbility="62.53" network="iPoker.it" name="Explosive Sunday HighR 15.000€" id="624315649" guarantee="15000.0" game="H" flags="D" entrants="66" date="1391998616" currency="EUR"/>
<ScheduledTournament structure="NL" stake="63.00" region="IT" rake="7.00" prizePool="2520.0" avAbility="60.53" network="iPoker.it" name="SNAI PSP 3.500€ Gtd" id="624395120" guarantee="3500.0" game="H" flags="D" entrants="40" date="1391989802" currency="EUR"/>
<ScheduledTournament structure="NL" stake="4.20" region="IT" rake="0.80" prizePool="247.75" avAbility="58.93" numRebuys="59" network="iPoker.it" name="Sat Snai PSP 4.000€ Gtd. R/A" id="624415123" guarantee="200.0" game="H" flags="T,SAT,R" entrants="25" date="1392058336" currency="EUR"/>
</DailyScheduledTournamentResponse>

Produces a report listing the daily scheduled tournaments for a specific date and network.
This is similar to the same report by region; see Daily Scheduled Tournaments Report (by region) for information on parameters.

Request to add missing game(s) using tournament summary information from the Pokerstars network(s) email system, using the following root URL:

https://www.sharkscope.com/api/appname/reportmissinggamesbysummary

A Pokerstars tournament summary (as plain text) must be included in the body of this request, in the same format as the email received from Pokerstars when requesting a tournament summary from them.
Example tournament summary:

Tournament History for Tournament #1 requested by SomeUsername (SomeEmail@gmail.com)
PokerStars Tournament #1234578820, No Limit Hold'em
Buy-In: $2.82/$0.18 USD

The response contains the provided Game ID with status of processed, pending (already reported), error, or existing. If the status is error the actual error message is also included.
The MissingTournamentsResponse contains the same structure as for Game IDs, except in this case only one summary (a tournament summary email from Pokerstars) can be processed at a time.
Example response:

<MissingTournamentsResponse total=*"1"* processed=*"1">*
<MissingTournaments gameID=*"123457820"* status=*"processed" />*
</MissingTournamentsResponse>

The status is one of “processed”, “pending”, “existing” or “error”. If the status is “error” then there is also an attribute containing the error details in text.

<MissingTournaments gameID=*"123457820"* status=*"processed" />*
<MissingTournaments gameID=*"12345782a"* status=*"error" error=*"Invalid game ID" />*

Request to upload results from PokerCraft based sites (GGNetowrk and WSOP(CA-ON)). The provided filename is downloaded directly from the PokerCraft website. If the file is not available from that location (the files are typically only available for a few hours after they are created) the request will fail. The privacy parameter can be set to “public” so that anyone can view the uploaded data, or “private” where only the account that uploaded the data can see it.
The response contains a summary of the number of files processed and number of entries added.

Adds an account that is permitted to view uploaded private data on your account. The provided email address must correspond to an existing SharkScope account.

Adds an account that is permitted to view uploaded private data on your account. The provided email address must correspond to an existing SharkScope account.