docs

docs/Clients.md

@@ -3,6 +3,8 @@ title: General usage
 nav_order: 2
 ---
 
+## How to use the library
+
 Each implementation generally provides two different clients, which will be the access point for the API's. First of the rest client, which is typically available via [ExchangeName]Client, and a socket client, which is generally named [ExchangeName]SocketClient. For example `BinanceClient` and `BinanceSocketClient`.
 
 ## Rest client

docs/FAQ.md

@@ -3,6 +3,8 @@ title: FAQ
 nav_order: 11
 ---
 
+## Frequently asked questions
+
 ### I occasionally get a NullReferenceException, what's wrong?
 You probably don't check the result status of a call and just assume the data is always there. `NullReferenceExecption`s will happen when you have code like this `var symbol = client.GetTickersAync().Result.Data.Symbol` because the `Data` property is null when the call fails. Instead check if the call is successful like this:
 ```csharp

docs/Glossary.md

@@ -2,6 +2,7 @@
 title: Glossary
 nav_order: 10
 ---
+## Terms and definitions
 
 |Definition|Synonyms|Meaning|
 |----------|--------|-------|
@@ -19,7 +20,7 @@ nav_order: 10
 |Ticker|Stats|Statistics over the last 24 hours|
 |Client implementation|Library|An implementation of the `CrytpoExchange.Net` library. For example `Binance.Net` or `FTX.Net`|
 
-### Other naming constraints
+### Other naming conventions
 #### PlaceOrderAsync
 Methods for creating an order are always named `PlaceOrderAsync`, with and optional additional name for the type of order, for example `PlaceMarginOrderAsync`.
 

docs/Interfaces.md

@@ -3,6 +3,7 @@ title: Common interfaces
 nav_order: 5
 ---
 
+## Shared interfaces
 Clients have a common interface implementation to allow a shared code base to use the same functionality for different exchanges. The interface is implemented at the `API` level, for example:
 ```csharp
 var binanceClient = new BinanceClient();

docs/Logging.md

@@ -3,6 +3,7 @@ title: Log config
 nav_order: 4
 ---
 
+## Configuring logging
 The library offers extensive logging, for which you can supply your own logging implementation. The logging can be configured via the client options (see [Client options](https://github.com/JKorf/CryptoExchange.Net/wiki/Options)). The examples here are using the `BinanceClient` but they should be the same for each implementation.
 
 Logging is based on the `Microsoft.Extensions.Logging.ILogger` interface. This should provide ease of use when connecting the library logging to your existing logging implementation.

docs/Migration Guide.md

@@ -3,7 +3,10 @@ title: Migrate v4 to v5
 nav_order: 9
 ---
 
-Changes from 4.x to 5.x:
+## Migrating from version 4 to version 5
+When updating your code from version 4 implementations to version 5 implementations you will encounter a fair bit of breaking changes. Here is the general outline for changes made in the CryptoExchange.Net library. For more specific changes for each library visit the library migration guide.
+
+*NOTE when updating it is not possible to have some client implementations use a V4 version and some clients a V5. When updating all libraries should be migrated*
 
 ## Client structure
 The client structure has been changed to make clients more consistent across different implementations. Clients using V4 either had `client.Method()`, `client.[Api].Method()` or `client.[Api].[Topic].Method()`.  

docs/Options.md

@@ -3,7 +3,7 @@ title: Client options
 nav_order: 3
 ---
 
-## Setting options
+## Setting client options
 
 Each implementation can be configured using client options. There are 2 ways to provide these, either via `[client].SetDefaultOptions([options]);`, or in the constructor of the client. The examples here use the `BinanceClient`, but usage is the same for each client.
 

docs/Orderbooks.md

@@ -3,6 +3,7 @@ title: Order books
 nav_order: 6
 ---
 
+## Locally synced order book
 Each implementation provides an order book implementation. These implementations will provide a client side order book and will take care of synchronization with the server, and will handle reconnecting and resynchronizing in case of a dropped connection.
 Order book implementations are named as `[ExchangeName][Type]SymbolOrderBook`, for example `BinanceSpotSymbolOrderBook`. 
 

docs/RateLimiter.md

@@ -3,6 +3,7 @@ title: Rate limiting
 nav_order: 7
 ---
 
+## Rate limiting
 The library has build in rate limiting. These rate limits can be configured per client. Some client implementations where the exchange has clear rate limits will also have a default rate limiter already set up.
 Rate limiting is configured in the client options, and can be set on a specific client or for all clients by either providing it in the constructor for a client, or by using the `SetDefaultOptions` on a client.
 
@@ -51,6 +52,8 @@ A rate limit for the total amount of requests for all requests send from the cli
 A rate limit for all requests send to a specific endpoint. Requests that do not fully match the endpoint will not be counted to this limit.
 
 ### AddPartialEndpointLimit
+|Parameter|Description|
+|---------|-----------|
 |endpoint|The partial endpoint this limit is for. Partial means that a request will match this limiter when a part of the request URI path matches this endpoint|
 |limit|The request weight limit per time period. Note that requests can have a weight specified. Default requests will have a weight of 1|
 |perTimePeriod|The time period over which the limit is enforced|
@@ -61,6 +64,8 @@ A rate limit for all requests send to a specific endpoint. Requests that do not
 A rate limit for a partial endpoint. Requests will be counted towards this limit if the request path contains the endpoint. For example request `/api/v2/test` will match when the partial endpoint limit is set for `/api/v2`.
 
 ### AddApiKeyLimit
+|Parameter|Description|
+|---------|-----------|
 |limit|The request weight limit per time period. Note that requests can have a weight specified. Default requests will have a weight of 1|
 |perTimePeriod|The time period over which the limit is enforced|
 |onlyForSignedRequests|Whether this rate limit should only be counter for signed/authenticated requests|