This page details how the end user can interact with this API.
The API is designed to be accessed via HTTP GET requests. The output is a JSON page.
A typical query will look something like
The API comes with an AJAX query builder to help users quickly create and test queries. A live version can be seen at the bottom of the page at sc-api.com.
It is highly recommended that new users try the query builder out to get an idea of what queries look like and how the returned data is formatted.
The query parameters can be added in any order but are case sensitive and must be URL encoded. Many parameters are optional and will default to common values if left out of the query string.
|This specifies the internal source of the data, where "cache" requests that data be gathered from the database and "live" requests that it be gathered from the original website.|
|This is used to specify the external source of the data for systems that can access sites other than just RSI.|
|This specifies the high-level system that should be accessed. Accounts accesses information about user accounts. Organizations accesses information about organizations (guilds). Forums accesses information about forums, threads, and posts.|
|This specifies the exact action that should be performed within the overarching system.|
|target_id||user supplied string||This is the subject of interest for actions that operate on one object. For instance, the handle of a user, the SID of an organization, or the number and title of a thread.|
|start_date||user supplied unix timestamp||This specifies the earliest date in the database to start building the history from. For instance, setting the start_date to one week ago would ignore any data collected before that date.|
|end_date||user supplied unix timestamp||This specifies the latest date in the database to build the history to. For instance, setting the end_date to one week ago would ignore any data collected after that date.|
|start_page||user supplied unsigned integer||This specifies the beginning page for multi-page queries. For instance, if querying a forum thread, the start_page determines the page of the thread where the query will begin. This pagination is determined by the target website's pagination. If the start_page is higher than the number of pages in the target, the query will return null.|
|end_page||user supplied unsigned integer||This specifies the ending page for multi-page queries. For instance, if querying a forum thread, the end_page determines the page of the thread where the query will end. This pagination is determined by the target website's pagination. If the end_page is higher than the number of pages in the target, the query will return after the last page in the target.|
|items_per_page||user supplied unsigned integer||This specifies the number of items that should be accessed by each page of a multi-page query. The pagination is determined by the target site and this parameter is a request rather than a rule. For instance, asking the RSI site to return all_organizations using 200 items_per_page will return 200 items per page ( 200 * (end_page - start_page) ). However, asking it to return 500 results is outside of its allowed range on RSI so it will default to 32, despite our request.|
|This determines the column on which the data should be ordered. Currently, these only work for the live all_organizations query from RSI.|
|This specifies whether the data should be sorted in ascending or descending order. Currently, these only work for the live all_organizations query from RSI.|
|This determines if Scrapers are allowed to call additional Scrapers. For instance, when scraping a user's organization memberships, the default behavior is for the dossier scraper to call org scrapers for each org found. This increases the reliability of our cache but also increases request times. This parameter can be set to 1 (true) to skip those piggy-back Scraper calls.|
This is the base query for all of the info on a user including dossier, forum profile, and organization memberships.
This is the same query as above except using the live source instead of the cache. This means the API will need to visit the user's dossier, org memberships, and forum profile which will take significantly longer than using the cache.
This will return the data for only the user's dossier. The same can be done for the "forum_profile" and "memberships". This only works for the live query.
This will return a list of every user on record in the database. Due to how our database is structured, this will currently only return their handles.
This returns all the posts within the specified thread on the RSI site. The start_page and end_page parameters match the pagination of the thread. The target_id parameter is the thread ID number found in it's URL.
This returns a list of all the threads contained in a specified forum on the RSI site. The start_page and end_page parameters match the pagination of the RSI forum. The target_id parameter is the title of the forum found in it's URL.
This returns all the forums on the RSI site.
This returns all the profile data of a single organization (the data found on the front page of it's spectrum page). The target_id is the org's SID.
This returns all the member data of a single organization (the data found on the Members page of it's spectrum page). The target_id is the org's SID. The live version of this query will insert entries for each "Redacted" member but the cache version will simply ignore them.
This returns a list of all visible organizations on the RSI site. The cache version of this query is HIGHLY RECOMMENDED as it will only take a second to return. The live version will respect the pagination and sort settings found on the RSI List All org page. The cache version will currently only return org SIDs due to how our database is structured (To keep server load down) while the live version will return all the data visible on the List All page.