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. Each member that is keeping the group's financial statistics hidden carries optinrequired="true" in the group's member list (Players/Player), and an opted out member carries optedout="true". A member reported as optedin="false" on an opt-out-filtered network such as iPoker is still counted, with a filter applied, and does not hide the group's statistics.

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.

The state attribute of an active tournament is one of Announced (the poker site lists the tournament but has not opened registration yet, so nobody is registered), Registering, Late Registration or Running. Treat a value you do not recognise as an active tournament: states may be added. Where the poker site publishes it, regOpenDate is when registration opens, in the same Unix-time format as scheduledStartDate; it is omitted when unknown, and on a tournament still Announced a time already past only means the change to Registering has not been seen yet.

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.

With the network "Player Group" it lists player groups instead: your own groups first, then groups shared with you, then other people's public groups, up to limit of each. Each group carries a section attribute (yours, shared or public), and a PlayerGroupTotals element gives how many groups match under each in all. Your own and shared groups need your Username and Password headers and match from one character; public groups need three.

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.

Advice repeats each recommendation with a target naming where it can be checked: stakes (results by stake), positions (finish positions), streaks, weekdays (results by day of the week), types (the player's results in each tournament type it lists, with avoid true for a type to stay away from) or selector (the Tournament Selector). A recommendation with no target leads nowhere in particular. Currency gives the ISO code of the stake amounts.

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.
By default the response is the group's attributes (name, memberCount, public, consolidated and so on) without the Players list, because for a large group the list is a lot of data on every call. Pass noPlayers=false to receive the whole group, every member included, as this request answered before revision 1.0.133. The group is changed in exactly the same way either way. The parameter has no effect on the personal group, which is always returned with its members.

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.
As for the other member requests (see Adding Players and Creating Groups), the response leaves the Players list out unless you pass noPlayers=false. The personal group, which is the only group this request changes anything in, is always returned with its members.

Removes a player from the group. Players can be removed one at a time. When the last player is removed the group is deleted.
By default the response is the group's attributes without the Players list. Pass noPlayers=false to receive the group as it is after the removal, every remaining member included, as this request answered before revision 1.0.133. The group is changed in exactly the same way either way. The parameter has no effect on the personal group, which is always returned with its members.

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.

The state attribute of an active tournament is one of Announced (the poker site lists the tournament but has not opened registration yet, so nobody is registered), Registering, Late Registration or Running. Treat a value you do not recognise as an active tournament: states may be added. Where the poker site publishes it, regOpenDate is when registration opens, in the same Unix-time format as scheduledStartDate; it is omitted when unknown, and on a tournament still Announced a time already past only means the change to Registering has not been seen yet. A completed tournament's is Completed.

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.

repeats says how often the tournament runs, measured from the last four weeks it ran: several (more than once a day; repeatsPerDay gives the average), daily, somedays (two to six days a week), weekly, monthly, irregular (keeps running at no steady time) or oneoff (ran once and is not scheduled again). For weekly and somedays, repeatSlots lists the hours of the week it starts in, in UTC, 0 being Sunday 00:00 UTC; convert them to your own time zone to name the days. repeats is omitted for a tournament with too little history to say, such as a new one; treat a value you do not recognise as omitted. The filter Recurrence:DAILY,WEEKLY selects on it, and Recurrence!:ONEOFF leaves one-offs out.

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 state attribute of an active tournament is one of Announced (the poker site lists the tournament but has not opened registration yet, so nobody is registered), Registering, Late Registration or Running. Treat a value you do not recognise as an active tournament: states may be added. Where the poker site publishes it, regOpenDate is when registration opens, in the same Unix-time format as scheduledStartDate; it is omitted when unknown, and on a tournament still Announced a time already past only means the change to Registering has not been seen yet. Announced tournaments are listed too; the filter State:ANNOUNCED selects only them, and State:REGISTERING,LATEREG leaves them out.

repeats says how often the tournament runs, measured from the last four weeks it ran: several (more than once a day; repeatsPerDay gives the average), daily, somedays (two to six days a week), weekly, monthly, irregular (keeps running at no steady time) or oneoff (ran once and is not scheduled again). For weekly and somedays, repeatSlots lists the hours of the week it starts in, in UTC, 0 being Sunday 00:00 UTC; convert them to your own time zone to name the days. repeats is omitted for a tournament with too little history to say, such as a new one; treat a value you do not recognise as omitted. The filter Recurrence:DAILY,WEEKLY selects on it, and Recurrence!:ONEOFF leaves one-offs out.

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.
The optional maxResponseSize parameter caps the tournament list at that many characters of JSON. Tournaments that would go past it are left out and not charged, and the response then has truncated="true"; ask again from the next position for the rest. A tournament takes from under 1,000 characters (a Sit & Go) to around 8,000 (a scheduled tournament with thousands of entrants).

repeats says how often the tournament runs, measured from the last four weeks it ran: several (more than once a day; repeatsPerDay gives the average), daily, somedays (two to six days a week), weekly, monthly, irregular (keeps running at no steady time) or oneoff (ran once and is not scheduled again). For weekly and somedays, repeatSlots lists the hours of the week it starts in, in UTC, 0 being Sunday 00:00 UTC; convert them to your own time zone to name the days. repeats is omitted for a tournament with too little history to say, such as a new one; treat a value you do not recognise as omitted. The filter Recurrence:DAILY,WEEKLY selects on it, and Recurrence!:ONEOFF leaves one-offs out.

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 Pro subscription (any plan from Pro 5K up). If no date filter is provided the resource returns the tournaments that finished in the last 4 days (21 days for GG networks), as if the filter were EndDate:4D. Date filters on when a tournament started and EndDate on when it finished, so a tournament that ran for more than a day can finish inside a Date window that its start is outside of. The date attribute of each tournament is when it finished, and duration is how long it ran in seconds. 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 the current chip counts of a running tournament's players, by tournament ID. The first request submits the tournament to be read; repeat the identical request to poll until the chips are ready. Each response contains a RunningChipsTournament whose status attribute is:

SUBMITTED: the tournament has been submitted, or is being read. Poll again.

COMPLETED: the request has completed and the response carries the chip counts. It describes the request, not the tournament, which is still running.

If the chips cannot be read, an error is returned instead.

Each COMPLETED response costs 1 search. A COMPLETED response is cached for 10 seconds: the same request within that time returns the same chips. We recommend polling every few seconds, and abandoning the request if it has not COMPLETED within 2 minutes. Not every network is supported; a request for one that is not returns an error immediately.

A COMPLETED tournament carries the tournament's name, currency (the ISO code every amount in the response is in), stake and rake, startingStack, the chips each entrant starts with (where the network publishes it), and chipsTime, when its chips were read, in epoch seconds. incomplete="true" means some players still in could not have their chips read.

Its players are listed from the biggest stack to the smallest, then the players who are out, with zero chips, in order of their finishing position. A player still in has a chips attribute, and a tableId where the network gives one. A player who is out has position, their finishing place, and prize, what that place paid.

On networks that send their payout table (888poker, Global Poker, Stake, partypoker, Chico, PokerMatch, WPN, PokerStars, CoinPoker, QQPK and iPoker), the response also lists it in a payouts element. Each payout gives the range of finishing places from-to and the prize per place, with ticket="true" where those places win a ticket; its prize is then the ticket's value, or 0 when the network does not give one. The table can still change while late registration is open. Some tournaments have none even on those networks: PokerStars publishes its table only once late registration closes, and Day 1 flights, steps tournaments and satellites whose seat value is unknown have none.

With a payout table, each player still in also carries:
- icmEquity: their ICM (Malmuth-Harville) equity, the prize they can expect from the places still to be decided, given their share of the chips.
- chipRank: their rank by chips now, 1 for the biggest stack. Equal stacks share a rank.
- prizeIfEndedNow: what their chip rank pays if the tournament ended now. Equal stacks share the average of the places they span, so two players tied for 2nd each get the average of 2nd and 3rd. It is only a potential, as the places are not decided yet.

All three are left out after a deal, and when the roster returned is incomplete. On a knockout or mystery-bounty tournament, the payouts, icmEquity and prizeIfEndedNow cover the regular prize pool only: bounties are paid as players are knocked out and are not part of them.

Where the tournament's statistics are available, a StillInStatistics element gives the same entry statistics as the tournament's Statistics element, for the players still in, so the two can be compared. Players who have opted out of SharkScope are left out of it.

On networks that send the blind level (PokerStars, partypoker scheduled tournaments, iPoker, CoinPoker, QQPK, Stake and Clubs Poker), a blinds element gives the level being played when the chips were read: level, its number (left out where the network gives the blinds but not the number), and smallBlind, bigBlind and ante, in chips (ante is per player, 0 when the level has none). startingStackBigBlinds is the starting stack divided by the big blind, to one decimal: the big blinds a player registering late would start with. It is left out when the starting stack is not known. Divide a player's chips by bigBlind for their stack in big blinds.

Example response:

<RunningChipsResponse>
  <RunningChipsTournament network="pokerstars" tournamentId="1568330211" status="COMPLETED" name="$7.00 NL Hold'em [Turbo]" currency="USD" stake="6.45" rake="0.55" startingStack="1500" chipsTime="1791853205" incomplete="false">
    <blinds level="9" smallBlind="100" bigBlind="200" ante="25" startingStackBigBlinds="7.5"/>
    <payouts>
      <payout from="1" to="1" prize="29.03"/>
      <payout from="2" to="2" prize="17.42"/>
      <payout from="3" to="3" prize="11.61"/>
    </payouts>
    <StillInStatistics>
      <Statistic id="AvAbility">63</Statistic>
      <Statistic id="CombinedAvROI">4.5</Statistic>
      ...
    </StillInStatistics>
    <players>
      <player name="simal64" chips="5914" icmEquity="21.51" chipRank="1" prizeIfEndedNow="29.03" tableId="1"/>
      <player name="Roll_Me_Now" chips="5671" icmEquity="21.23" chipRank="2" prizeIfEndedNow="17.42" tableId="1"/>
      <player name="gaita763" chips="1915" icmEquity="15.32" chipRank="3" prizeIfEndedNow="11.61" tableId="1"/>
      <player name="ImSingle6" chips="0" position="4" prize="0.0"/>
      <player name="fclmdon92" chips="0" position="5" prize="0.0"/>
      <player name="BronoCaetino" chips="0" position="6" prize="0.0"/>
      <player name="sanrah1" chips="0" position="7" prize="0.0"/>
      <player name="Y259066" chips="0" position="8" prize="0.0"/>
      <player name="sinsa72" chips="0" position="9" prize="0.0"/>
    </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" />*