Merge pull request #45 from OpenSTFoundation/pranay/gh43/minorfixesondev

pranay/gh43/minorfixedondev

docs/0_02_START_ALPHA.md

@@ -4,13 +4,13 @@ title: This is an alpha release
 sidebar_label: Alpha
 ---
 
-OST KITα in its current release is not yet feature complete. This release is for early user testing. It does the ground work to help create a toolkit that meets the real needs of real businesses.
+OST KIT⍺ in its current release is not yet feature complete. This release is for early user testing. It does the ground work to help create a toolkit that meets the real needs of real businesses.
 
-OST KITα is a SaaS (software as a service) designed for both business people and developers. Anyone will be able to use OST KITα to design, create and manage their crypto economy, setup transactions and users, mint their tokens, simulate transactions, and more, without requiring them to have blockchain developers in-house).
+OST KIT⍺ is a SaaS (software as a service) designed for both business people and developers. Anyone will be able to use OST KIT⍺ to design, create and manage their crypto economy, setup transactions and users, mint their tokens, simulate transactions, and more, without requiring them to have blockchain developers in-house).
 
-For developers, OST KITα offers a robust set of APIs so that developers can integrate OST KITα into their existing apps and run operations on their own.
+For developers, OST KIT⍺ offers a robust set of APIs so that developers can integrate OST KIT⍺ into their existing apps and run operations on their own.
 
-### Key features in OST KITα include:
+### Key features in OST KIT⍺ include:
 * Design & Plan your Branded Token Economy 
 * Choose your token name, token symbol, and icon
 * Use our Token Economy Planner to set the value of your token and to decide how many tokens to mint

docs/2_00_API_OVERVIEW.md

@@ -6,7 +6,7 @@ sidebar_label: Overview
 
 OST KIT⍺ hosts RESTful APIs to help you manage your token economy on the OpenST utility blockchain.  OST KIT⍺ introduces `users` and `transaction-types` to easily integrate the token economy of your application with the blockchain.
 
-A `user` is an object that owns a branded token balance on the utility chain, while meta-data and caching information are kept off-chain to preserve user privacy and enable fast response times.  The end-user can exchange branded tokens with other users or the company through interactions within the application.  The end-user can always redeem her branded tokens for the equivalent amount of $OST⍺ through the OpenST protocol.
+A `user` is an object that owns a branded token balance on the utility chain, while meta-data and caching information are kept off-chain to preserve user privacy and enable fast response times.  The end-user can exchange branded tokens with other users or the company through interactions within the application.  The end-user can always redeem her branded tokens for the equivalent amount of OST⍺ through the OpenST protocol.
 
 Within OST KIT⍺, you can set up `transaction-types` to define advanced payments to tokenize your application. A transaction type is of a certain kind: `user_to_user`, `user_to_company`, or `company_to_user`. A transaction type's value is set in branded tokens ($BT) or in fiat ($USD). Note that OST KIT⍺ runs on a testnet and tokens have no market value.  For fiat payments, a price oracle is consulted on-chain to calculate the equivalent amount of branded tokens to transfer.  Lastly, for user-to-user payments, the company can set a transaction fee.
 
@@ -29,14 +29,14 @@ When you create a new `user` through the API, a `uuid` is returned that represen
 
 ### Awarding airdrop tokens to users
 
-To incentivise new or existing users, they can be airdropped tokens to get them started in the economy.  Airdropped tokens remain under ownership of the company, but the user has them available to spend within the application under token rules.  Airdropped tokens cannot be redeemed for $OST⍺ before they have been spent (at least once) within the economy.
+To incentivise new or existing users, they can be airdropped tokens to get them started in the economy.  Airdropped tokens remain under ownership of the company, but the user has them available to spend within the application under token rules.  Airdropped tokens cannot be redeemed for OST⍺ before they have been spent (at least once) within the economy.
 
 | users        |
 |----------------|
 | [/users/airdrop/drop](api_airdrop_drop.html)     |
 | [/users/airdrop/status](api_airdrop_status.html) |
 
-NOTE: for OST KIT⍺, users are represented by managed accounts (i.e., OST KIT⍺ stores the encrypted private keys) for the created users as it concerns $OST⍺ on Ropsten testnet.  In the future, we will support an on-chain decentralised key management solution to keep end-users self-sovereign owners of their tokens while allowing easy and secure integration of transfers within the application.  Follow us to hear about those updates soon.
+NOTE: for OST KIT⍺, users are represented by managed accounts (i.e., OST KIT⍺ stores the encrypted private keys) for the created users as it concerns OST⍺ on Ropsten testnet.  In the future, we will support an on-chain decentralised key management solution to keep end-users self-sovereign owners of their tokens while allowing easy and secure integration of transfers within the application.  Follow us to hear about those updates soon.
 
 >_last updated 14 March 2018_; for support see [help.ost.com](help.ost.com)
 >

docs/2_01_API_USERS_CREATE.md

@@ -37,7 +37,7 @@ For api calls to `/users/create` the `data.result_type` is the string "economy_u
 and the key `data.economy_users` is an array of `user` objects.
 On successful creation of the user, `economy_users` contains the created user as a single element.
 
-### User Object Attributes:
+### User Object Attributes
 
 | Parameter | Type   | Value  |
 |-----------|--------|--------|

docs/2_02_API_USERS_EDIT.md

@@ -38,7 +38,7 @@ For api calls to `/users/edit` the `data.result_type` is the string "economy_use
 and the key `data.economy_users` is an array of `user` objects.
 On successful edit of a user, `economy_users` contains the edited user as a single element.
 
-### User Object Attributes:
+### User Object Attributes
 
 | Parameter | Type   | Value  |
 |-----------|--------|--------|

docs/2_03_API_USERS_LIST.md

@@ -40,7 +40,7 @@ so that the full request query reads
 For api calls to `/users/list` the `data.result_type` is the string "economy_users"
 and the key `data.economy_users` is an array of the returned `user` objects (25 users per page). The field `data.meta.next_page_payload` contains the filter and order information and the `page_no` number for the next page; or is empty for the last page of the list.
 
-### User Object Attributes:
+### User Object Attributes
 
 | Parameter | Type   | Value  |
 |-----------|--------|--------|

docs/2_04_API_AIRDROP_DROP.md

@@ -1,6 +1,6 @@
 ---
 id: api_airdrop_drop
-title: OST KIT⍺ API Airdrop
+title: OST KIT⍺ | API Airdrop
 sidebar_label: /users/airdrop/drop
 ---
 
@@ -46,7 +46,7 @@ so that the full request uri and form reads
 On calling `/users/airdrop/drop` the `data.airdrop_uuid` is a string containing the airdrop reference id, that can be used to check the airdrop status using the AIRDROP STATUS API endpoint.
 
 
-#### Example Success Response
+### Example Success Response
 ```
 {
  "success": true,
@@ -56,7 +56,7 @@ On calling `/users/airdrop/drop` the `data.airdrop_uuid` is a string containing
 }
 ```
 
-#### Example Failure Response
+### Example Failure Response
 For a failed authentication the response is returned with status code 401 and the body can look like this,
 ```json
 {
@@ -89,7 +89,7 @@ however when a request is invalid the response is returned with status code 200
 ```
 
 
-#### Sample Code | Curl
+### Sample Code | Curl
 ```bash
 curl -i \
 -H "Accept: application/json" \

docs/2_05_API_AIRDROP_STATUS.md

@@ -1,12 +1,12 @@
 ---
 id: api_airdrop_status
-title: OST KIT⍺ API Aidrop Status
+title: OST KIT⍺ API | Airdrop Status
 sidebar_label: /users/airdrop/status
 ---
 
 
-Get from `/users/airdrop/status` to receive the airdrop status.
-
+Send a GET request to `/users/airdrop/status` to receive the airdrop status.
+ 
 Get the status of the airdrop of branded tokens. This API can be used to understand which stage the processing of airdropping the tokens are going through.  
 
 
@@ -24,7 +24,7 @@ where the signature is derived from the API secret key and the string to sign is
 
 so that the full request uri and form reads
 
-> POST - `https://playgroundapi.ost.com/users/airdrop/status?airdrop_uuid=AIRDROP_UUID&api_key=API_KEY&request_timestamp=EPOCH_TIME_SEC&signature=SIGNATURE`
+> GET - https://playgroundapi.ost.com/users/airdrop/status?airdrop_uuid=AIRDROP_UUID&api_key=API_KEY&request_timestamp=EPOCH_TIME_SEC&signature=SIGNATURE
 
 ### JSON Response Object
 
@@ -36,15 +36,15 @@ so that the full request uri and form reads
 
 On calling `/users/airdrop/status` the `data.airdrop_uuid` is a string containing the airdrop reference id. `data.current_status` is a string containing the present status of the airdrop request. `data.steps_complete` is an array explaining the steps which have been completed for the airdrop at the specific point in time of the API request.
 
-#### _current status_
+#### **_current status_**
 | Attribute | Type    | Description                                   |
 |-----------|---------|------------------------------------------|
 | _pending_   | String | The string to represent that airdrop is still in process.
 | _failed_  | String | The string to represent that the airdrop has failed.
 | _complete_   | String | The string to represent that the airdrop process is complete.|
 
 
-#### _steps complete_
+#### **_steps complete_**
 | Attribute | Type    | Description                                   |
 |-----------|---------|------------------------------------------|
 | _user_identified_   | String | The string to represent identification of the end-user for airdropping branded tokens.
@@ -53,7 +53,7 @@ On calling `/users/airdrop/status` the `data.airdrop_uuid` is a string containin
 | _allocation_done_   | String | The string to represent that the airdrop process is complete.|
 
 
-#### Example Success Response
+### Example Success Response
 ```
 {
  "success": true,
@@ -70,7 +70,7 @@ On calling `/users/airdrop/status` the `data.airdrop_uuid` is a string containin
 }
 ```
 
-#### Example Failure Response
+### Example Failure Response
 For a failed authentication the response is returned with status code 401 and the body can look like this,
 
 ```
@@ -100,7 +100,7 @@ however when a request is invalid the response is returned with status code 200
 }
 ```
 
-#### Sample Code | Curl
+### Sample Code | Curl
 ```bash
 curl -i \
 -H "Accept: application/json" \

docs/2_08_API_TRANSACTION-TYPES_LIST.md

@@ -8,7 +8,7 @@ Send a GET request on `/transaction-types/list` to receive a list of all transac
 
 Within OST KIT⍺ you can set up transaction-types to define advanced payments to tokenize your application. A transaction type is of a certain kind: user_to_user, user_to_company, or company_to_user. A transaction type's value is set in branded tokens ($BT) or in fiat ($USD). Note that OST KIT⍺ runs on a testnet and tokens have no market value. For fiat payments a price oracle is consulted on-chain to calculate the equivalent amount of branded tokens to transfer. Lastly for user to user payments the company can set a transaction fee to earn on a user-to-user payment.
 
-#### Input Parameters
+### Input Parameters
 | Parameter | Type | Value                                         |
 |-----------|------|-----------------------------------------------|
 | _api_key_           | string    | mandatory API key obtained from [kit.ost.com](https://kit.ost.com) |
@@ -68,7 +68,7 @@ For api calls to `/transaction-types` the `data.result_type` is the string "tran
 | _symbol_            | string | name of the symbol |
 | _symbol_icon_       | string | icon reference |
 | _conversion_factor_ | float  | conversion factor of the branded token to OST |
-| _token_erc20_address | address | prefixed hexstring address of the branded token erc20 contract on the utility chain |
+| _token_erc20_address_ | address | prefixed hexstring address of the branded token erc20 contract on the utility chain |
 | _airdrop_contract_addr_ | address | prefixed hexstring address of the airdrop / pricer contract that regulates payments of branded tokens with transaction types |
 | _simple_stake_contract_addr_ | address | prefixed hexstring address of the simple stake contract which holds the OST⍺ on Ethereum Ropsten testnet which has been staked to mint branded tokens |
 

docs/2_09_API_TRANSACTION-TYPES_EXECUTE.md

@@ -8,7 +8,7 @@ Send a POST request on `/transaction-types/execute` to execute a defined transac
 
 Within OST KIT⍺ you can set up transaction-types to define advanced payments to tokenize your application. A transaction type is of a certain kind: user_to_user, user_to_company, or company_to_user. A transaction type's value is set in branded tokens ($BT) or in fiat ($USD). Note that OST KIT⍺ runs on a testnet and tokens have no market value. For fiat payments a price oracle is consulted on-chain to calculate the equivalent amount of branded tokens to transfer. Lastly for user to user payments the company can set a transaction fee to earn on a user-to-user payment.
 
-#### Input Parameters
+### Input Parameters
 | Parameter           | Type   | Value                                               |
 |---------------------|--------|-----------------------------------------------------|
 | _api_key_           | string    | mandatory API key obtained from [kit.ost.com](https://kit.ost.com) |

docs/2_98_API_AUTHENTICATION.md

@@ -29,7 +29,7 @@ and all the inputs must be alphabetically sorted on the keys.  The keys are lowe
 
 When using the [<u>Ruby SDK</u>](3_01_SDK_RUBY.md) authentication is handled for you.  In other languages you can implement the signature generation by computing the `sha256` digest of the API secret and the query string.  The resulting signature must be then included in the request.
 
-### NodeJS Authentication Example
+### Node.js Authentication Example
 
 An example code snippet to generate the API signature given the API key and the API shared secret for a request can be implemented as follows: