doc update (#491)

* fix doc indent

* up bouncer doc & arm doc

docs/faq.md

@@ -96,6 +96,7 @@ not exactly the same target as the debian named armhf port.
 
 The best way to have a crowdsec version for such an architecture is to
 do:
+
 1. install golang (all versions from 1.13 will do)
 2. `export GOARCH=arm`
 3. `export CGO=1`

docs/v1.X/docs/bouncers/index.md

@@ -1,11 +1,13 @@
 # Bouncers
 
 
-{{v1X.bouncers.Name}} are standalone software pieces in charge of acting upon blocked IPs.
+{{v1X.bouncers.Name}} are standalone software pieces in charge of acting upon a decision taken by crowdsec : block an IP, present a captcha, enforce MFA on a given user, etc.
 
 They can either be within the applicative stack, or work out of band :
 
-[nginx bouncer](https://github.com/crowdsecurity/cs-nginx-bouncer) will check every unknown IP against the database before letting go through or serving a *403* to the user, while a [firewall bouncer](https://github.com/crowdsecurity/cs-firewall-bouncer) will simply "add" malevolent IPs to nftables/ipset set of blacklisted IPs.
+[nginx bouncer](https://github.com/crowdsecurity/cs-nginx-bouncer) will check every unknown IP against the local API before letting go through or serving a *403* to the user, while a [firewall bouncer](https://github.com/crowdsecurity/cs-firewall-bouncer) will simply "add" malevolent IPs to nftables/ipset set of blacklisted IPs.
+
+Bouncers rely on [crowdsec's Local API](/Crowdsec/v1/localAPI/) to be able to get informations about a given IP or such.
 
 
 You can explore [available {{v1X.bouncers.name}} on the hub]({{v1X.hub.bouncers_url}}).

docs/v1.X/docs/getting_started/concepts.md

@@ -16,7 +16,7 @@ Then, {{v1X.bouncers.htmlname}} can "consume" those decisions (via the very same
 
 ## Crowd sourced aspect
 
- [[References](/Crowdsec/v1/getting_started/crowd-power)]
+ [[References](https://crowdsecurity.github.io/api_doc/index.html?urls.primaryName=CAPI)]
 
 Whenever the {{v1X.lapi.htmlname}} receives an alert with associated decisions, the meta information about the alert are shared with our central api :
 
@@ -24,7 +24,16 @@ Whenever the {{v1X.lapi.htmlname}} receives an alert with associated decisions,
  - The scenario that was triggered
  - The timestamp of the attack
 
-These are the only information that are sent to our API. Those are then processed on our side to be able to redistribute relevant blocklists to all the participants.
+These are the only information that are sent to our API. Those are then processed on our side to be able to redistribute relevant blocklists to all the participants. You can check the central API documentation in the references link to have an exhaustive view of what might be shared between your instance and our services.
+
+## Bouncers
+
+[[References](/Crowdsec/v1/bouncers/)]
+
+Bouncers are standalone software pieces in charge of acting upon IPs that triggered alerts.
+To do so, bouncers are going to query the local API to know if there is an existing decisions against a given IP, range, username etc. [You can find a list of existing bouncers on the hub]({{v1X.bouncers.url}})
+
+
 
 # Configuration items
 

docs/v1.X/docs/localAPI/index.md

@@ -7,6 +7,8 @@ The Local API (LAPI) is a core component of {{v1X.crowdsec.name}} and has a few
  - Allow `cscli` to view add or delete decisions
 
 
+[You can find the swagger documentation here](https://crowdsecurity.github.io/api_doc/index.html?urls.primaryName=LAPI)
+
 ## Authentication
 
 There is two kinds of authentication to the local API :