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).

Returns a player's recent tournaments as a downloadable CSV file rather than XML. This is the CSV export of the same data described under Completed Tournaments; the number of tournaments and ordering are controlled by the same "order" parameter (see Completed Tournaments for details).
Each row represents one tournament, with columns for the standard tournament result fields. The response is delivered as a CSV attachment.

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.

Adds a tag to a player. Tags are free-text labels, private to the caller, used to organise
the players you follow; a player may carry several. The request is idempotent — adding a
tag the player already has succeeds and changes nothing, so a client can send its whole set
without working out the difference first. Tags are matched case-insensitively, so a tag
differing only in capitalisation is the same tag. A tag may be up to 30 characters, may not
be blank, and may not contain a slash. A player may carry up to 12. Tags cannot be set on
the Player Group pseudo-network — see Adding Group Tags for that. Subscriber only.

Removes a tag from a player. Removing a tag the player does not carry succeeds and changes
nothing. Subscriber only.

Records how many extra entries a player bought in one tournament - rebuys on a rebuy
tournament, re-entries on a re-entry tournament. "count" counts the entries beyond the first,
so a player who entered once and never re-entered is 0, and one who fired three bullets is 2.
Counts run from 0 to 50.

Only tournaments we receive no per-player count for accept a report. Those are the ones marked
individualRebuysUnknown="true" in the Completed Tournaments response; anything else is refused,
because the count held there came from the poker network and is not an estimate. Where no count
has been reported, SharkScope shares the tournament's total rebuys evenly across its entrants,
so a report replaces that estimate with what actually happened and the player's statistics are
recalculated from it.

The player must be one of your own player names - a screen name you have added to your account
as a personal player name. A rebuy count changes that player's investment, and so their profit
and ROI, so it is only taken from the person who played. Sending the same count again succeeds
and changes nothing. Counts SharkScope recorded itself cannot be overwritten.

Example response:

<RebuyResponse inserted="1" rebuys="2"/>

Withdraws a count reported earlier, putting the player back on the tournament average.
Withdrawing a count that was never reported succeeds and changes nothing. Counts SharkScope
recorded itself cannot be withdrawn. The player must be one of your own player names.

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. A PartyPoker real name cannot be opted in this way without the networkadmin privilege: the request fails with error 200112, because a real name is opted in only by its owner registering for the free Sharkscope Real Name Opt-In tournament in the PartyPoker client.

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.

Returns the timeline notification requests registered for a player — the
alerts a user has subscribed to for activity on that player's timeline.
Requires authentication.

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.

Creates a copy of an existing player group under a new name supplied in the
name query parameter. Requires an authenticated, subscribed user.

Transfers ownership of a player group to another user, identified by the
email query parameter. Requires an authenticated, subscribed user.

Adds a tag to a player group. Tags are free-text labels used to organise your
own groups; a group may carry several. The request is idempotent — adding a tag
the group already has succeeds and changes nothing, so a client can send its
whole set of tags without working out the difference first.
The caller must own the group. The personal group cannot be tagged and is
reported as not found.

Copies every player in {subgroup} into {playergroup} as ordinary members of
{playergroup}. This is a one-time copy: the two groups are not linked afterwards,
so later changes to {subgroup} do not appear in {playergroup}.
Players already in the target are skipped, so repeating the request succeeds and
changes nothing. You must own {playergroup}; {subgroup} only needs to be one you
can read, so copying from a public group is allowed. The personal group cannot be
used as either side and is reported as not found. Free accounts are still subject
to the member limit, measured against the total the copy would produce.

Links {subgroup} into {playergroup}. Unlike copying, this stays live: the linked
group's players count as members of the parent, and adding or removing players in
the linked group is reflected in the parent straight away.
You must own both groups. A group cannot link itself, cannot form a cycle, cannot
nest more than five levels deep, and cannot take the parent past 2000 players once
flattened; a private group cannot be linked into a public one. The personal group
cannot be used on either side. Linking a group that is already linked succeeds and
changes nothing.
memberCount continues to report only the players stored directly against the
parent; effectiveMemberCount reports the flattened total, and is what a search of
the group is priced on.

Removes a link from {playergroup} to {subgroup}. The linked group itself is not
changed and its players are not deleted — only the link is. Removing a link the
group does not hold succeeds and changes nothing.
Where the linked group has since been deleted its name can no longer be resolved,
so its numeric id may be given instead. You must own {playergroup}.

Removes a tag from a player group. Removing a tag the group does not carry
succeeds and changes nothing.
The caller must own the group. The personal group cannot be tagged and is
reported as not found.

Requests the alert rules configured on a player group, and the recent activity they
have produced. An alert rule watches the group's members for a condition — a cash
above an amount, a tournament win, a final table, a stake played above or below a
threshold, a format, a leaderboard placing, a newly linked screen name, or a period
of inactivity — and delivers what fires to the caller's connected destinations.
Reading this costs no searches: it returns stored rules and a delivery log, and
never touches tournament data. Pro subscription required.

Creates an alert rule on a player group. The trigger names the condition, and the
operands that condition needs are supplied as their own parameters — amount,
currency, minEntrants, formats, days, topN — rather than as a JSON body. Scope
selects who in the group the rule watches: every member, only members carrying a
given tag, or one named member. Channels name the destinations to deliver to, and
any destination listed in digestChannels instead receives one batched message a day
rather than a message per event. Capped per group and per user; the limits are
returned on every alerts response. Pro subscription required.

Changes an existing alert rule — its name, scope, operands, delivery channels, or
whether it is switched on. Channels that survive the change keep their delivery
history, so adding a destination does not make the existing ones re-send anything.
Pro subscription required.

Deletes an alert rule. The alerts it has already delivered are left in place — they
are a record of what was sent, and deleting the rule does not unsend them. Pro
subscription required.

Sends a clearly-labelled sample alert to every destination the rule delivers to, so
a newly connected webhook or address can be proven to work without waiting for a
real event. The test is not recorded as activity and does not affect which real
events the rule will go on to send. Returns the number of destinations that accepted
the message. Pro subscription required.

Marks delivered alerts as read, either for the whole group or for one rule when a
ruleID is supplied. Pro subscription required.

Requests the caller's private note on a player group. Notes are per-user, so two
people looking at the same group each see their own note and never each other's.
A note may be kept on any group the caller can see, not only groups they own.
Subscriber only.

Stores the caller's private note on a player group. The note is sent as the form
parameter "notes" in an application/x-www-form-urlencoded body; it is not a query
parameter, because note text may contain characters that are not safe in a URI.
An empty or whitespace-only value removes the note. Notes longer than 8192
characters are truncated to the first 8192. Subscriber only.

Removes the caller's private note on a player group. Removing a note that is not
there succeeds and changes nothing. Subscriber only.

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.

Completed tournaments can also be ordered by prize: "Prize" orders by the prize attribute (which includes any bounty), "BountyPrize" by the prizeBountyComponent attribute, and "PrizeExcludingBounty" by the prize paid for the finishing position (the prize less its bounty component), e.g. order=BountyPrize,1~25,desc. Entries without that figure come last in either direction, and equal figures are ordered by position. A registering or running tournament has no prizes, so these orders fall back to Player as Position does.

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.

The Tournament Edge for a list of players in one registering tournament: for each player, the expected ROI and profit per entry if they entered it, built from the player's own record at this stake and format, the strength of the field, the overlay and the rake, with the likely range and the evidence behind it. Name the players with repeated player parameters (exact, so a name containing a comma is safe) or one comma-separated players parameter; up to 20 across both. Costs one search however many players are named, and only when at least one of them had a profile to answer from: charged on the response says whether the search was spent. Gold and above, including the Pro plans.

Each Player element answers one name, in the order asked. Its state is OK with a figure; NO_PROFILE when the player has no profile yet, in which case queued="true" says one has just been queued and the response's retryAfterSeconds says when to ask again; STALE, BEYOND_RECORD, DIFFERENT_GAME or NO_STAKE when the record cannot price this tournament; NOT_FOUND when no player of that name exists on the network; NOT_AVAILABLE when the player's statistics are not shown. Profiles are built in the background from the player's results, never inside the request, so a first request for players nobody has asked about before returns their states and a second request a few minutes later returns their figures. Registering tournaments only: a completed tournament has a result, not a forecast.

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 via a POST request. This resource is designed to be the most efficient way of retrieving mass player results from a known set of opted-in players and requires a Commercial Gold Subscription. If no date filter is provided the resource returns data from the last 4 days by default (21 days for GG networks). 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, submitted as a form parameter.

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. The response contains all the leaderboards for the year as a hierarchy.

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.

Returns the poker-leaderboards landing view as rendered HTML — the index of
available leaderboards. Takes no parameters.

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.