more doc changes

10 files changed, 441 insertions, 313 deletions

diff --git a/documentation/docs/api_overview.md b/documentation/docs/api_overview.md
index 845150a..eec562d 100644
--- a/documentation/docs/api_overview.md
+++ b/documentation/docs/api_overview.md
@@ -86,14 +86,16 @@ to map these responses to native exception types or signals in your language of
 choice. See [the full error page](errors.md) for details.
 
 
+<br><br>
 # Authorization
-
+------
 ## check_auth
 
-### Args:
-**target_user**: string: either a user_name or a user_id
+**Arguments:**
+
+ * __target_user__: string: either a user_name or a user_id
 
-**target_hash**: string: sha256 hash for the password to check
+ * __target_hash__: string: sha256 hash for the password to check
 
 
 
@@ -101,17 +103,17 @@ Takes the arguments `target_user` and `target_hash`, and
 returns boolean true or false whether the hash is valid.
 
 
-
---------
-
+<br>
+<br><br>
 # Threads & Messages
-
+------
 ## delete_post
 
-### Args:
-**thread_id**: string: the id of the thread this message was posted in.
+**Arguments:**
+
+ * __thread_id__: string: the id of the thread this message was posted in.
 
-**post_id**: integer: the id of the target message.
+ * __post_id__: integer: the id of the target message.
 
 
 
@@ -126,16 +128,19 @@ success.
 
 If the post_id is 0, the whole thread is deleted.
 
+
+<br>
 ## edit_post
 
-### Args:
-**thread_id**: string: the thread the message was posted in.
+**Arguments:**
+
+ * __thread_id__: string: the thread the message was posted in.
 
-**post_id**: integer: the target post_id to edit.
+ * __post_id__: integer: the target post_id to edit.
 
-**body**: string: the new message body.
+ * __body__: string: the new message body.
 
-**OPTIONAL: send_raw**: boolean: set the formatting mode for the target message.
+ * __OPTIONAL: send_raw__: boolean: set the formatting mode for the target message.
 
 
 
@@ -156,12 +161,15 @@ endpoint `set_post_raw` instead.
 
 Returns the new message object.
 
+
+<br>
 ## edit_query
 
-### Args:
-**thread_id**: string: the id of the thread the message was posted in.
+**Arguments:**
 
-**post_id**: integer: the id of the target message.
+ * __thread_id__: string: the id of the thread the message was posted in.
+
+ * __post_id__: integer: the id of the target message.
 
 
 
@@ -172,10 +180,13 @@ message. Requires the arguments `thread_id` and `post_id`
 Returns the original message object without any formatting
 on success. Returns a descriptive code 4 otherwise.
 
+
+<br>
 ## message_feed
 
-### Args:
-**time**: int/float: epoch/unix time of the earliest point of interest
+**Arguments:**
+
+ * __time__: int/float: epoch/unix time of the earliest point of interest
 
 
 
@@ -206,14 +217,17 @@ You may optionally provide a `format` argument: this is treated
 the same way as the `thread_load` endpoint and you should refer
 to its documentation for more info.
 
+
+<br>
 ## set_post_raw
 
-### Args:
-**thread_id**: string: the id of the thread the message was posted in.
+**Arguments:**
+
+ * __thread_id__: string: the id of the thread the message was posted in.
 
-**post_id**: integer: the id of the target message.
+ * __post_id__: integer: the id of the target message.
 
-**value**: boolean: the new `send_raw` value to apply to the message.
+ * __value__: boolean: the new `send_raw` value to apply to the message.
 
 
 
@@ -231,12 +245,15 @@ You may optionally set this value as well when using `edit_post`,
 but if this is the only change you want to make to the message,
 using this endpoint instead is preferable.
 
+
+<br>
 ## set_thread_pin
 
-### Args:
-**thread_id**: string: the id of the thread to modify.
+**Arguments:**
+
+ * __thread_id__: string: the id of the thread to modify.
 
-**value**: boolean: `true` to pin thread, `false` otherwise.
+ * __value__: boolean: `true` to pin thread, `false` otherwise.
 
 
 
@@ -247,14 +264,17 @@ has admin status on their account.
 
 Returns the same boolean you supply as `value`
 
+
+<br>
 ## thread_create
 
-### Args:
-**body**: string: The body of the first message
+**Arguments:**
 
-**title**: string: The title name for this thread
+ * __body__: string: The body of the first message
 
-**OPTIONAL: send_raw**: boolean: formatting mode for the first message.
+ * __title__: string: The title name for this thread
+
+ * __OPTIONAL: send_raw__: boolean: formatting mode for the first message.
 
 
 
@@ -264,10 +284,13 @@ string arguments `body` and `title`.
 If the argument `send_raw` is specified and has a non-nil
 value, the OP message will never recieve special formatting.
 
+
+<br>
 ## thread_index
 
-### Args:
-**OPTIONAL: include_op**: boolean: Include a `messages` object with the original post
+**Arguments:**
+
+ * __OPTIONAL: include_op__: boolean: Include a `messages` object with the original post
 
 
 
@@ -278,14 +301,17 @@ Optionally, you may supply the argument `include_op`, which, when
 non-nil, will include a "messages" key with the object, whose sole
 content is the original message (post_id 0).
 
+
+<br>
 ## thread_load
 
-### Args:
-**thread_id**: string: the thread to load.
+**Arguments:**
+
+ * __thread_id__: string: the thread to load.
 
-**OPTIONAL: op_only**: boolean: include only the original message in `messages`
+ * __OPTIONAL: op_only__: boolean: include only the original message in `messages`
 
-**OPTIONAL: format**: string: the formatting type of the returned messages.
+ * __OPTIONAL: format__: string: the formatting type of the returned messages.
 
 
 
@@ -297,14 +323,17 @@ Currently only "sequential" is supported.
 You may also supply the parameter `op_only`. When it's value
 is non-nil, the messages array will only include post_id 0 (the first)
 
+
+<br>
 ## thread_reply
 
-### Args:
-**thread_id**: string: the id for the thread this message should post to.
+**Arguments:**
+
+ * __thread_id__: string: the id for the thread this message should post to.
 
-**body**: string: the message's body of text.
+ * __body__: string: the message's body of text.
 
-**OPTIONAL: send_raw**: boolean: formatting mode for the posted message.
+ * __OPTIONAL: send_raw__: boolean: formatting mode for the posted message.
 
 
 
@@ -315,19 +344,19 @@ If the argument `send_raw` is specified and has a non-nil
 value, the message will never recieve special formatting.
 
 
-
---------
-
+<br>
+<br><br>
 # Tools
-
+------
 ## db_validate
 
-### Args:
-**key**: string: the identifier for the ruleset to check.
+**Arguments:**
+
+ * __key__: string: the identifier for the ruleset to check.
 
-**value**: VARIES: the object for which `key` will check for.
+ * __value__: VARIES: the object for which `key` will check for.
 
-**OPTIONAL: error**: boolean: when `true`, will return an API error response instead of a special object.
+ * __OPTIONAL: error__: boolean: when `true`, will return an API error response instead of a special object.
 
 
 
@@ -351,12 +380,15 @@ If bool == false, description is a string describing the
 problem. If bool == true, description is null and the
 provided value is safe to use.
 
+
+<br>
 ## format_message
 
-### Args:
-**body**: string: the message body to apply formatting to.
+**Arguments:**
+
+ * __body__: string: the message body to apply formatting to.
 
-**format**: string: the specifier for the desired formatting engine
+ * __format__: string: the specifier for the desired formatting engine
 
 
 
@@ -364,96 +396,113 @@ Requires the arguments `body` and `format`. Applies
 `format` to `body` and returns the new object. See
 `thread_load` for supported specifications for `format`.
 
+
+<br>
 ## user_map
 
-### Args:
-__No arguments__
+_requires no arguments_
 
 Returns an array with all registered user_ids, with the usermap
 object populated by their full objects.
 
 
-
---------
-
+<br>
+<br><br>
 # Users
-
+------
 ## get_me
 
-### Args:
-__No arguments__
+_requires no arguments_
 
 Requires no arguments. Returns your internal user object,
 including your authorization hash.
 
+
+<br>
 ## is_admin
 
-### Args:
-**target_user**: string: user_id or user_name to check against.
+**Arguments:**
+
+ * __target_user__: string: user_id or user_name to check against.
 
 
 
 Requires the argument `target_user`. Returns a boolean
 of whether that user is an admin.
 
+
+<br>
 ## user_get
 
-### Args:
-**target_user**: string: either a user_name or a user_id
+**Arguments:**
+
+ * __target_user__: string: either a user_name or a user_id
 
 
 
 Retreive an external user object for the given `target_user`.
 Can be a user_id or user_name.
 
+
+<br>
 ## user_is_registered
 
-### Args:
-**target_user**: string: either a user_name or a user_id
+**Arguments:**
+
+ * __target_user__: string: either a user_name or a user_id
 
 
 
 Takes the argument `target_user` and returns true or false
 whether they are in the system or not.
 
+
+<br>
 ## user_register
 
-### Args:
-**user_name**: string: the desired display name
+**Arguments:**
+
+ * __user_name__: string: the desired display name
+
+ * __auth_hash__: string: a sha256 hash of a password
 
-**auth_hash**: string: a sha256 hash of a password
 
 
+Register a new user into the system and return the new user object
+on success. The returned object includes the same `user_name` and
+`auth_hash` that you supply, in addition to all the default user
+parameters. Returns code 4 errors for any failures.
 
-Register a new user into the system and return the new object.
-Requires the string arguments `user_name` and `auth_hash`.
-Do not send User/Auth headers with this method.
 
+<br>
 ## user_update
 
-### Args:
-**Any of the following may be submitted:**: 
+**Arguments:**
 
-**user_name**: string: a desired display name
+ * __Any of the following may be submitted__: 
 
-**auth_hash**: string: sha256 hash for a new password
+ * __user_name__: string: a desired display name
 
-**quip**: string: a short string that can be used as a signature
+ * __auth_hash__: string: sha256 hash for a new password
 
-**bio**: string: a user biography for their profile
+ * __quip__: string: a short string that can be used as a signature
 
-**color**: integer: 0-6, a display color for the user
+ * __bio__: string: a user biography for their profile
 
+ * __color__: integer: 0-6, a display color for the user
 
 
-Receives new parameters and assigns them to the user_object
-in the database. The following new parameters can be supplied:
-`user_name`, `auth_hash`, `quip`, `bio`, and `color`. Any number
-of them may be supplied.
 
-The newly updated user object is returned on success.
+Receives new parameters and assigns them to the user object.
+This method requires that you send a valid User/Auth header
+pair with your request, and the changes are made to that
+account.
 
+Take care to keep your client's User/Auth header pair up to date
+after using this method.
 
+The newly updated user object is returned on success,
+including the `auth_hash`.
 
---------
 
+<br>
diff --git a/documentation/docs/errors.md b/documentation/docs/errors.md
index 5daa714..4144fbd 100644
--- a/documentation/docs/errors.md
+++ b/documentation/docs/errors.md
@@ -1,10 +1,12 @@
-Errors in BBJ are separated into 6 different codes to help
-ease handling a little bit. Errors are all or nothing, there
-are no "warnings". If a response has a non-false error field,
-then data will always be null. An error response from the api
-looks like this...
+## Handling Error Responses
 
-```
+Errors in BBJ are separated into 6 different codes, to allow easy mapping to
+native exception and signaling systems available in the client's programming
+language. Errors are all or nothing, there are no "warnings". If a response has
+a non-false error field, then data will always be null. An error response from
+the api looks like this...
+
+```javascript
 {
   "error": {
       "code": // an integer from 0 to 5,
@@ -15,13 +17,18 @@ looks like this...
 }
 ```
 
-The codes split errors into a few categories. Some are oriented
+The codes split errors into categories. Some are oriented
 to client developers while others should be shown directly to
 users.
 
-  * 0: Malformed but non-empty json input. An empty json input where it is required is handled by code 3. This is just decoding errors. The exception text is returned as description.
-  * 1: Internal server error. A short representation of the internal exception as well as the code the server logged it as is returned in the description. Your clients cannot recover from this class of error, and its probably not your fault if you encounter it. If you ever get one, file a bug report.
-  * 2: Server HTTP error: This is similar to the above but captures errors for the HTTP server rather than BBJs own codebase. The description contains the HTTP error code and server description. This notably covers 404s and thus invalid endpoint names.
-  * 3: Parameter error: client sent erroneous input for its method. This could mean missing arguments, type errors, etc. It generalizes errors that should be fixed by the client developer and the returned descriptions are geared to them rather than end users.
-  * 4: User error: These errors regard actions that the user has taken that are invalid, but not really errors in a traditional sense. The description field should be shown to users verbatim, in a clear and noticeable fashion. They are formatted as concise English sentences and end with appropriate punctuation marks.
-  * 5: Authorization error: This code represents an erroneous User/Auth header pair. This should trigger the user to provide correct credentials or fall back to anon mode.
+  * **Code 0**: Malformed but non-empty json input. An empty json input where it is required is handled by code 3. This is just decoding errors. The exception text is returned as description.
+
+  * **Code 1**: Internal server error. A short representation of the internal exception as well as the code the server logged it as is returned in the description. Your clients cannot recover from this class of error, and its probably not your fault if you encounter it. If you ever get one, file a bug report.
+
+  * **Code 2**: Server HTTP error: This is similar to the above but captures errors for the HTTP server rather than BBJs own codebase. The description contains the HTTP error code and server description. This notably covers 404s and thus invalid endpoint names. The HTTP error code is left intact, so you may choose to let your HTTP library or tool of choice handle these for you.
+
+  * **Code 3**: Parameter error: client sent erroneous input for its method. This could mean missing arguments, type errors, etc. It generalizes errors that should be fixed by the client developer and the returned descriptions are geared to them rather than end users.
+
+  * **Code 4**: User error: These errors regard actions that the user has taken that are invalid, but not really errors in a traditional sense. The description field should be shown to users verbatim, in a clear and noticeable fashion. They are formatted as concise English sentences and end with appropriate punctuation marks.
+
+  * **Code 5**: Authorization error: This code represents an erroneous User/Auth header pair. This should trigger the user to provide correct credentials or fall back to anon mode.
diff --git a/documentation/docs/validation.md b/documentation/docs/validation.md
index 5f7ac56..b039941 100644
--- a/documentation/docs/validation.md
+++ b/documentation/docs/validation.md
@@ -1,6 +1,8 @@
+## Implementing good sanity checks in your client.
+
 The server has an endpoint called `db_validate`. What this does is take
-a `key` and a `value` and compares `value` to a set of rules specified by
-`key`. This is the same function used internally by the database to scan
+a `key` and a `value` argument, and compares `value` to a set of rules specified by
+`key`. This is the same function used internally by the database to check
 values before committing them to the database. By default it returns a
 descriptive object under `data`, but you can specify the key/value pair
 `"error": True` to get a standard error response back. A standard call
@@ -67,7 +69,6 @@ The following keys are currently available.
 The descriptions returned are friendly, descriptive, and should be shown
 directly to users
 
-## Implementing good sanity checks in your client
 
 By using this endpoint, you will never have to validate values in your
 own code before sending them to the server. This means you can do things
@@ -78,17 +79,16 @@ This is used in the elisp client when registering users and for the thread
 title prompt which is shown before opening a composure window. The reason
 for rejection is displayed clearly to the user and input window is restored.
 
-```
+```lisp
 (defun bbj-sane-value (prompt key)
   "Opens an input loop with the user, where the response is
 passed to the server to check it for validity before the
 user is allowed to continue. Will recurse until the input
 is valid, then it is returned."
   (let* ((value (read-from-minibuffer prompt))
-         (response (bbj-request! 'db_validate
-                     'value value 'key key)))
+         (response (bbj-request! 'db_validate 'value value 'key key)))
     (if (alist-get 'bool response)
-        value
+        value ;; return the user's input back to the caller
       (message (alist-get 'description response))
       (sit-for 2)
       (bbj-sane-value prompt key))))
diff --git a/documentation/site/api_overview/index.html b/documentation/site/api_overview/index.html
index 912576a..70168f7 100644
--- a/documentation/site/api_overview/index.html
+++ b/documentation/site/api_overview/index.html
@@ -189,19 +189,35 @@ and the json object that <code>error</code> contains should be inspected. (see t
 visualation) Errors follow a strict code system, making it easy for your client
 to map these responses to native exception types or signals in your language of
 choice. See <a href="../errors/">the full error page</a> for details.</p>
+<p><br><br></p>
 <h1 id="authorization">Authorization</h1>
+<hr />
 <h2 id="check_auth">check_auth</h2>
-<h3 id="args">Args:</h3>
+<p><strong>Arguments:</strong></p>
+<ul>
+<li>
 <p><strong>target_user</strong>: string: either a user_name or a user_id</p>
+</li>
+<li>
 <p><strong>target_hash</strong>: string: sha256 hash for the password to check</p>
+</li>
+</ul>
 <p>Takes the arguments <code>target_user</code> and <code>target_hash</code>, and
 returns boolean true or false whether the hash is valid.</p>
-<hr />
+<p><br>
+<br><br></p>
 <h1 id="threads-messages">Threads &amp; Messages</h1>
+<hr />
 <h2 id="delete_post">delete_post</h2>
-<h3 id="args_1">Args:</h3>
+<p><strong>Arguments:</strong></p>
+<ul>
+<li>
 <p><strong>thread_id</strong>: string: the id of the thread this message was posted in.</p>
+</li>
+<li>
 <p><strong>post_id</strong>: integer: the id of the target message.</p>
+</li>
+</ul>
 <p>Requires the arguments <code>thread_id</code> and <code>post_id</code>.</p>
 <p>Delete a message from a thread. The same rules apply
 here as <code>edit_post</code> and <code>edit_query</code>: the logged in user
@@ -210,12 +226,23 @@ or have admin rights. The same error descriptions and code
 are returned on falilure. Boolean true is returned on
 success.</p>
 <p>If the post_id is 0, the whole thread is deleted.</p>
+<p><br></p>
 <h2 id="edit_post">edit_post</h2>
-<h3 id="args_2">Args:</h3>
+<p><strong>Arguments:</strong></p>
+<ul>
+<li>
 <p><strong>thread_id</strong>: string: the thread the message was posted in.</p>
+</li>
+<li>
 <p><strong>post_id</strong>: integer: the target post_id to edit.</p>
+</li>
+<li>
 <p><strong>body</strong>: string: the new message body.</p>
+</li>
+<li>
 <p><strong>OPTIONAL: send_raw</strong>: boolean: set the formatting mode for the target message.</p>
+</li>
+</ul>
 <p>Replace a post with a new body. Requires the arguments
 <code>thread_id</code>, <code>post_id</code>, and <code>body</code>. This method verifies
 that the user can edit a post before commiting the change,
@@ -229,18 +256,28 @@ set the message's formatting flag. However, if this is the
 only change you would like to make, you should use the
 endpoint <code>set_post_raw</code> instead.</p>
 <p>Returns the new message object.</p>
+<p><br></p>
 <h2 id="edit_query">edit_query</h2>
-<h3 id="args_3">Args:</h3>
+<p><strong>Arguments:</strong></p>
+<ul>
+<li>
 <p><strong>thread_id</strong>: string: the id of the thread the message was posted in.</p>
+</li>
+<li>
 <p><strong>post_id</strong>: integer: the id of the target message.</p>
+</li>
+</ul>
 <p>Queries the database to ensure the user can edit a given
 message. Requires the arguments <code>thread_id</code> and <code>post_id</code>
 (does not require a new body)</p>
 <p>Returns the original message object without any formatting
 on success. Returns a descriptive code 4 otherwise.</p>
+<p><br></p>
 <h2 id="message_feed">message_feed</h2>
-<h3 id="args_4">Args:</h3>
-<p><strong>time</strong>: int/float: epoch/unix time of the earliest point of interest</p>
+<p><strong>Arguments:</strong></p>
+<ul>
+<li><strong>time</strong>: int/float: epoch/unix time of the earliest point of interest</li>
+</ul>
 <p>Returns a special object representing all activity on the board since
 the argument <code>time</code>, a unix/epoch timestamp.</p>
 <p>{
@@ -263,11 +300,20 @@ out visually.</p>
 <p>You may optionally provide a <code>format</code> argument: this is treated
 the same way as the <code>thread_load</code> endpoint and you should refer
 to its documentation for more info.</p>
+<p><br></p>
 <h2 id="set_post_raw">set_post_raw</h2>
-<h3 id="args_5">Args:</h3>
+<p><strong>Arguments:</strong></p>
+<ul>
+<li>
 <p><strong>thread_id</strong>: string: the id of the thread the message was posted in.</p>
+</li>
+<li>
 <p><strong>post_id</strong>: integer: the id of the target message.</p>
+</li>
+<li>
 <p><strong>value</strong>: boolean: the new <code>send_raw</code> value to apply to the message.</p>
+</li>
+</ul>
 <p>Requires the boolean argument of <code>value</code>, string argument
 <code>thread_id</code>, and integer argument <code>post_id</code>. <code>value</code>, when false,
 means that the message will be passed through message formatters
@@ -279,59 +325,106 @@ and the same error objects are returned for violations.</p>
 <p>You may optionally set this value as well when using <code>edit_post</code>,
 but if this is the only change you want to make to the message,
 using this endpoint instead is preferable.</p>
+<p><br></p>
 <h2 id="set_thread_pin">set_thread_pin</h2>
-<h3 id="args_6">Args:</h3>
+<p><strong>Arguments:</strong></p>
+<ul>
+<li>
 <p><strong>thread_id</strong>: string: the id of the thread to modify.</p>
+</li>
+<li>
 <p><strong>value</strong>: boolean: <code>true</code> to pin thread, <code>false</code> otherwise.</p>
+</li>
+</ul>
 <p>Requires the arguments <code>thread_id</code> and <code>value</code>. <code>value</code>
 must be a boolean of what the pinned status should be.
 This method requires that the caller is logged in and
 has admin status on their account.</p>
 <p>Returns the same boolean you supply as <code>value</code></p>
+<p><br></p>
 <h2 id="thread_create">thread_create</h2>
-<h3 id="args_7">Args:</h3>
+<p><strong>Arguments:</strong></p>
+<ul>
+<li>
 <p><strong>body</strong>: string: The body of the first message</p>
+</li>
+<li>
 <p><strong>title</strong>: string: The title name for this thread</p>
+</li>
+<li>
 <p><strong>OPTIONAL: send_raw</strong>: boolean: formatting mode for the first message.</p>
+</li>
+</ul>
 <p>Creates a new thread and returns it. Requires the non-empty
 string arguments <code>body</code> and <code>title</code>.</p>
 <p>If the argument <code>send_raw</code> is specified and has a non-nil
 value, the OP message will never recieve special formatting.</p>
+<p><br></p>
 <h2 id="thread_index">thread_index</h2>
-<h3 id="args_8">Args:</h3>
-<p><strong>OPTIONAL: include_op</strong>: boolean: Include a <code>messages</code> object with the original post</p>
+<p><strong>Arguments:</strong></p>
+<ul>
+<li><strong>OPTIONAL: include_op</strong>: boolean: Include a <code>messages</code> object with the original post</li>
+</ul>
 <p>Return an array with all the threads, ordered by most recent activity.
 Requires no arguments.</p>
 <p>Optionally, you may supply the argument <code>include_op</code>, which, when
 non-nil, will include a "messages" key with the object, whose sole
 content is the original message (post_id 0).</p>
+<p><br></p>
 <h2 id="thread_load">thread_load</h2>
-<h3 id="args_9">Args:</h3>
+<p><strong>Arguments:</strong></p>
+<ul>
+<li>
 <p><strong>thread_id</strong>: string: the thread to load.</p>
+</li>
+<li>
 <p><strong>OPTIONAL: op_only</strong>: boolean: include only the original message in <code>messages</code></p>
+</li>
+<li>
 <p><strong>OPTIONAL: format</strong>: string: the formatting type of the returned messages.</p>
+</li>
+</ul>
 <p>Returns the thread object with all of its messages loaded.
 Requires the argument <code>thread_id</code>. <code>format</code> may also be
 specified as a formatter to run the messages through.
 Currently only "sequential" is supported.</p>
 <p>You may also supply the parameter <code>op_only</code>. When it's value
 is non-nil, the messages array will only include post_id 0 (the first)</p>
+<p><br></p>
 <h2 id="thread_reply">thread_reply</h2>
-<h3 id="args_10">Args:</h3>
+<p><strong>Arguments:</strong></p>
+<ul>
+<li>
 <p><strong>thread_id</strong>: string: the id for the thread this message should post to.</p>
+</li>
+<li>
 <p><strong>body</strong>: string: the message's body of text.</p>
+</li>
+<li>
 <p><strong>OPTIONAL: send_raw</strong>: boolean: formatting mode for the posted message.</p>
+</li>
+</ul>
 <p>Creates a new reply for the given thread and returns it.
 Requires the string arguments <code>thread_id</code> and <code>body</code></p>
 <p>If the argument <code>send_raw</code> is specified and has a non-nil
 value, the message will never recieve special formatting.</p>
-<hr />
+<p><br>
+<br><br></p>
 <h1 id="tools">Tools</h1>
+<hr />
 <h2 id="db_validate">db_validate</h2>
-<h3 id="args_11">Args:</h3>
+<p><strong>Arguments:</strong></p>
+<ul>
+<li>
 <p><strong>key</strong>: string: the identifier for the ruleset to check.</p>
+</li>
+<li>
 <p><strong>value</strong>: VARIES: the object for which <code>key</code> will check for.</p>
+</li>
+<li>
 <p><strong>OPTIONAL: error</strong>: boolean: when <code>true</code>, will return an API error response instead of a special object.</p>
+</li>
+</ul>
 <p>Requires the arguments <code>key</code> and <code>value</code>. Returns an object
 with information about the database sanity criteria for
 key. This can be used to validate user input in the client
@@ -347,61 +440,104 @@ instead of the special object described below.</p>
 <p>If bool == false, description is a string describing the
 problem. If bool == true, description is null and the
 provided value is safe to use.</p>
+<p><br></p>
 <h2 id="format_message">format_message</h2>
-<h3 id="args_12">Args:</h3>
+<p><strong>Arguments:</strong></p>
+<ul>
+<li>
 <p><strong>body</strong>: string: the message body to apply formatting to.</p>
+</li>
+<li>
 <p><strong>format</strong>: string: the specifier for the desired formatting engine</p>
+</li>
+</ul>
 <p>Requires the arguments <code>body</code> and <code>format</code>. Applies
 <code>format</code> to <code>body</code> and returns the new object. See
 <code>thread_load</code> for supported specifications for <code>format</code>.</p>
+<p><br></p>
 <h2 id="user_map">user_map</h2>
-<h3 id="args_13">Args:</h3>
-<p><strong>No arguments</strong></p>
+<p><em>requires no arguments</em></p>
 <p>Returns an array with all registered user_ids, with the usermap
 object populated by their full objects.</p>
-<hr />
+<p><br>
+<br><br></p>
 <h1 id="users">Users</h1>
+<hr />
 <h2 id="get_me">get_me</h2>
-<h3 id="args_14">Args:</h3>
-<p><strong>No arguments</strong></p>
+<p><em>requires no arguments</em></p>
 <p>Requires no arguments. Returns your internal user object,
 including your authorization hash.</p>
+<p><br></p>
 <h2 id="is_admin">is_admin</h2>
-<h3 id="args_15">Args:</h3>
-<p><strong>target_user</strong>: string: user_id or user_name to check against.</p>
+<p><strong>Arguments:</strong></p>
+<ul>
+<li><strong>target_user</strong>: string: user_id or user_name to check against.</li>
+</ul>
 <p>Requires the argument <code>target_user</code>. Returns a boolean
 of whether that user is an admin.</p>
+<p><br></p>
 <h2 id="user_get">user_get</h2>
-<h3 id="args_16">Args:</h3>
-<p><strong>target_user</strong>: string: either a user_name or a user_id</p>
+<p><strong>Arguments:</strong></p>
+<ul>
+<li><strong>target_user</strong>: string: either a user_name or a user_id</li>
+</ul>
 <p>Retreive an external user object for the given <code>target_user</code>.
 Can be a user_id or user_name.</p>
+<p><br></p>
 <h2 id="user_is_registered">user_is_registered</h2>
-<h3 id="args_17">Args:</h3>
-<p><strong>target_user</strong>: string: either a user_name or a user_id</p>
+<p><strong>Arguments:</strong></p>
+<ul>
+<li><strong>target_user</strong>: string: either a user_name or a user_id</li>
+</ul>
 <p>Takes the argument <code>target_user</code> and returns true or false
 whether they are in the system or not.</p>
+<p><br></p>
 <h2 id="user_register">user_register</h2>
-<h3 id="args_18">Args:</h3>
+<p><strong>Arguments:</strong></p>
+<ul>
+<li>
 <p><strong>user_name</strong>: string: the desired display name</p>
+</li>
+<li>
 <p><strong>auth_hash</strong>: string: a sha256 hash of a password</p>
-<p>Register a new user into the system and return the new object.
-Requires the string arguments <code>user_name</code> and <code>auth_hash</code>.
-Do not send User/Auth headers with this method.</p>
+</li>
+</ul>
+<p>Register a new user into the system and return the new user object
+on success. The returned object includes the same <code>user_name</code> and
+<code>auth_hash</code> that you supply, in addition to all the default user
+parameters. Returns code 4 errors for any failures.</p>
+<p><br></p>
 <h2 id="user_update">user_update</h2>
-<h3 id="args_19">Args:</h3>
-<p><strong>Any of the following may be submitted:</strong>: </p>
+<p><strong>Arguments:</strong></p>
+<ul>
+<li>
+<p><strong>Any of the following may be submitted</strong>: </p>
+</li>
+<li>
 <p><strong>user_name</strong>: string: a desired display name</p>
+</li>
+<li>
 <p><strong>auth_hash</strong>: string: sha256 hash for a new password</p>
+</li>
+<li>
 <p><strong>quip</strong>: string: a short string that can be used as a signature</p>
+</li>
+<li>
 <p><strong>bio</strong>: string: a user biography for their profile</p>
+</li>
+<li>
 <p><strong>color</strong>: integer: 0-6, a display color for the user</p>
-<p>Receives new parameters and assigns them to the user_object
-in the database. The following new parameters can be supplied:
-<code>user_name</code>, <code>auth_hash</code>, <code>quip</code>, <code>bio</code>, and <code>color</code>. Any number
-of them may be supplied.</p>
-<p>The newly updated user object is returned on success.</p>
-<hr /></div>
+</li>
+</ul>
+<p>Receives new parameters and assigns them to the user object.
+This method requires that you send a valid User/Auth header
+pair with your request, and the changes are made to that
+account.</p>
+<p>Take care to keep your client's User/Auth header pair up to date
+after using this method.</p>
+<p>The newly updated user object is returned on success,
+including the <code>auth_hash</code>.</p>
+<p><br></p></div>
         </div>
 
         <footer class="col-md-12">
diff --git a/documentation/site/errors/index.html b/documentation/site/errors/index.html
index 0c3b923..edbb4b4 100644
--- a/documentation/site/errors/index.html
+++ b/documentation/site/errors/index.html
@@ -91,16 +91,18 @@
         <div class="container">
                 <div class="col-md-3"><div class="bs-sidebar hidden-print affix well" role="complementary">
     <ul class="nav bs-sidenav">
+        <li class="main active"><a href="#handling-error-responses">Handling Error Responses</a></li>
     </ul>
 </div></div>
                 <div class="col-md-9" role="main">
 
-<p>Errors in BBJ are separated into 6 different codes to help
-ease handling a little bit. Errors are all or nothing, there
-are no "warnings". If a response has a non-false error field,
-then data will always be null. An error response from the api
-looks like this...</p>
-<pre><code>{
+<h2 id="handling-error-responses">Handling Error Responses</h2>
+<p>Errors in BBJ are separated into 6 different codes, to allow easy mapping to
+native exception and signaling systems available in the client's programming
+language. Errors are all or nothing, there are no "warnings". If a response has
+a non-false error field, then data will always be null. An error response from
+the api looks like this...</p>
+<pre><code class="javascript">{
   &quot;error&quot;: {
       &quot;code&quot;: // an integer from 0 to 5,
       &quot;description&quot;: // a string describing the error in detail.
@@ -110,16 +112,28 @@ looks like this...</p>
 }
 </code></pre>
 
-<p>The codes split errors into a few categories. Some are oriented
+<p>The codes split errors into categories. Some are oriented
 to client developers while others should be shown directly to
 users.</p>
 <ul>
-<li>0: Malformed but non-empty json input. An empty json input where it is required is handled by code 3. This is just decoding errors. The exception text is returned as description.</li>
-<li>1: Internal server error. A short representation of the internal exception as well as the code the server logged it as is returned in the description. Your clients cannot recover from this class of error, and its probably not your fault if you encounter it. If you ever get one, file a bug report.</li>
-<li>2: Server HTTP error: This is similar to the above but captures errors for the HTTP server rather than BBJs own codebase. The description contains the HTTP error code and server description. This notably covers 404s and thus invalid endpoint names.</li>
-<li>3: Parameter error: client sent erroneous input for its method. This could mean missing arguments, type errors, etc. It generalizes errors that should be fixed by the client developer and the returned descriptions are geared to them rather than end users.</li>
-<li>4: User error: These errors regard actions that the user has taken that are invalid, but not really errors in a traditional sense. The description field should be shown to users verbatim, in a clear and noticeable fashion. They are formatted as concise English sentences and end with appropriate punctuation marks.</li>
-<li>5: Authorization error: This code represents an erroneous User/Auth header pair. This should trigger the user to provide correct credentials or fall back to anon mode.</li>
+<li>
+<p><strong>Code 0</strong>: Malformed but non-empty json input. An empty json input where it is required is handled by code 3. This is just decoding errors. The exception text is returned as description.</p>
+</li>
+<li>
+<p><strong>Code 1</strong>: Internal server error. A short representation of the internal exception as well as the code the server logged it as is returned in the description. Your clients cannot recover from this class of error, and its probably not your fault if you encounter it. If you ever get one, file a bug report.</p>
+</li>
+<li>
+<p><strong>Code 2</strong>: Server HTTP error: This is similar to the above but captures errors for the HTTP server rather than BBJs own codebase. The description contains the HTTP error code and server description. This notably covers 404s and thus invalid endpoint names. The HTTP error code is left intact, so you may choose to let your HTTP library or tool of choice handle these for you.</p>
+</li>
+<li>
+<p><strong>Code 3</strong>: Parameter error: client sent erroneous input for its method. This could mean missing arguments, type errors, etc. It generalizes errors that should be fixed by the client developer and the returned descriptions are geared to them rather than end users.</p>
+</li>
+<li>
+<p><strong>Code 4</strong>: User error: These errors regard actions that the user has taken that are invalid, but not really errors in a traditional sense. The description field should be shown to users verbatim, in a clear and noticeable fashion. They are formatted as concise English sentences and end with appropriate punctuation marks.</p>
+</li>
+<li>
+<p><strong>Code 5</strong>: Authorization error: This code represents an erroneous User/Auth header pair. This should trigger the user to provide correct credentials or fall back to anon mode.</p>
+</li>
 </ul></div>
         </div>
 
diff --git a/documentation/site/mkdocs/search_index.json b/documentation/site/mkdocs/search_index.json
index da61ce7..a977d96 100644
--- a/documentation/site/mkdocs/search_index.json
+++ b/documentation/site/mkdocs/search_index.json
@@ -22,7 +22,7 @@
         },
         {
             "location": "/api_overview/",
-            "text": "How to BBJ?\n\n\nInput\n\n\nBBJ is interacted with entirely through POST requests, whose bodies are\njson objects.\n\n\nThe endpoints, all listed below, can be contacted at the path /api/ relative\nto the root of where BBJ is hosted. If bbj is hosted on a server on port 80\nat the root:\n\n\nhttp://server.com/api/endpoint_here\n\n\nThe body of your request contains all of it's argument fields, instead of\nusing URL parameters. As a demonstration, to call \nthread_create\n,\nit requires two arguments: \ntitle\n, and \nbody\n. We put those argument\nnames at the root of the json object, and their values are the info\npassed into the API for that spot. Your input will look like this:\n\n\n{\n    \"title\": \"Hello world!!\",\n    \"body\": \"Hi! I am exploring this cool board thing!!\"\n}\n\n\n\n\nAnd you will POST this body to \nhttp://server.com:PORT/api/thread_create\n.\n\n\nA few endpoints do not require any arguments. These can still be POSTed to,\nbut the body may be completely empty or an empty json object. You can even\nGET these if you so choose.\n\n\nFor all endpoints, argument keys that are not consumed by the endpoint are\nignored. Posting an object with a key/value pair of \n\"sandwich\": True\n will\nnot clog up any pipes :) In the same vein, endpoints who dont take arguments\ndon't care if you supply them anyway.\n\n\nOutput\n\n\nBBJ returns data in a consistently formatted json object. The base object\nhas three keys: \ndata\n, \nusermap\n, and \nerror\n. Visualizied:\n\n\n{\n  \"error\":   false, // boolean false or error object\n  \"data\":    null,  // null or the requested data from endpoint.\n  \"usermap\": {}     // potentially empty object, maps user_ids to user objects\n}\n\n// If \"error\" is true, it looks like this:\n\n{\n  \"error\": {\n      \"code\": // an integer from 0 to 5,\n      \"description\": // a string describing the error in detail.\n  }\n  \"data\": null   // ALWAYS null if error is not false\n  \"usermap\": {}  // ALWAYS empty if error is not false\n}\n\n\n\n\ndata\n\n\ndata\n is what the endpoint actually returns. The type of contents vary\nby endpoint and are documented below. If an endpoint says it returns a\nboolean, it will look like \n\"data\": True\n. If it says it returns an array,\nit will look like \n\"data\": [\"stuff\", \"goes\", \"here\"]\n\n\nusermap\n\n\nThe usermap is a json object mapping user_ids within \ndata\n to full user\nobjects. BBJ handles users entirely by an ID system, meaning any references\nto them inside of response data will not include vital information like their\nusername, or their profile information. Instead, we fetch those values from\nthis usermap object. All of it's root keys are user_id's and their values\nare user objects. It should be noted that the anonymous user has it's own\nID and profile object as well.\n\n\nerror\n\n\nerror\n is typically \nfalse\n. If it is \nnot\n false, then the request failed\nand the json object that \nerror\n contains should be inspected. (see the above\nvisualation) Errors follow a strict code system, making it easy for your client\nto map these responses to native exception types or signals in your language of\nchoice. See \nthe full error page\n for details.\n\n\nAuthorization\n\n\ncheck_auth\n\n\nArgs:\n\n\ntarget_user\n: string: either a user_name or a user_id\n\n\ntarget_hash\n: string: sha256 hash for the password to check\n\n\nTakes the arguments \ntarget_user\n and \ntarget_hash\n, and\nreturns boolean true or false whether the hash is valid.\n\n\n\n\nThreads & Messages\n\n\ndelete_post\n\n\nArgs:\n\n\nthread_id\n: string: the id of the thread this message was posted in.\n\n\npost_id\n: integer: the id of the target message.\n\n\nRequires the arguments \nthread_id\n and \npost_id\n.\n\n\nDelete a message from a thread. The same rules apply\nhere as \nedit_post\n and \nedit_query\n: the logged in user\nmust either be the one who posted the message within 24hrs,\nor have admin rights. The same error descriptions and code\nare returned on falilure. Boolean true is returned on\nsuccess.\n\n\nIf the post_id is 0, the whole thread is deleted.\n\n\nedit_post\n\n\nArgs:\n\n\nthread_id\n: string: the thread the message was posted in.\n\n\npost_id\n: integer: the target post_id to edit.\n\n\nbody\n: string: the new message body.\n\n\nOPTIONAL: send_raw\n: boolean: set the formatting mode for the target message.\n\n\nReplace a post with a new body. Requires the arguments\n\nthread_id\n, \npost_id\n, and \nbody\n. This method verifies\nthat the user can edit a post before commiting the change,\notherwise an error object is returned whose description\nshould be shown to the user.\n\n\nTo perform sanity checks and retrieve the unformatted body\nof a post without actually attempting to replace it, use\n\nedit_query\n first.\n\n\nOptionally you may also include the argument \nsend_raw\n to\nset the message's formatting flag. However, if this is the\nonly change you would like to make, you should use the\nendpoint \nset_post_raw\n instead.\n\n\nReturns the new message object.\n\n\nedit_query\n\n\nArgs:\n\n\nthread_id\n: string: the id of the thread the message was posted in.\n\n\npost_id\n: integer: the id of the target message.\n\n\nQueries the database to ensure the user can edit a given\nmessage. Requires the arguments \nthread_id\n and \npost_id\n\n(does not require a new body)\n\n\nReturns the original message object without any formatting\non success. Returns a descriptive code 4 otherwise.\n\n\nmessage_feed\n\n\nArgs:\n\n\ntime\n: int/float: epoch/unix time of the earliest point of interest\n\n\nReturns a special object representing all activity on the board since\nthe argument \ntime\n, a unix/epoch timestamp.\n\n\n{\n    \"threads\": {\n        \"thread_id\": {\n            ...thread object\n        },\n        ...more thread_id/object pairs\n    },\n    \"messages\": [...standard message object array sorted by date]\n}\n\n\nThe message objects in \"messages\" are the same objects returned\nin threads normally. They each have a thread_id parameter, and\nyou can access metadata for these threads by the \"threads\" object\nwhich is also provided.\n\n\nThe \"messages\" array is already sorted by submission time, newest\nfirst. The order in the threads object is undefined and you should\ninstead use their \nlast_mod\n attribute if you intend to list them\nout visually.\n\n\nYou may optionally provide a \nformat\n argument: this is treated\nthe same way as the \nthread_load\n endpoint and you should refer\nto its documentation for more info.\n\n\nset_post_raw\n\n\nArgs:\n\n\nthread_id\n: string: the id of the thread the message was posted in.\n\n\npost_id\n: integer: the id of the target message.\n\n\nvalue\n: boolean: the new \nsend_raw\n value to apply to the message.\n\n\nRequires the boolean argument of \nvalue\n, string argument\n\nthread_id\n, and integer argument \npost_id\n. \nvalue\n, when false,\nmeans that the message will be passed through message formatters\nbefore being sent to clients. When \nvalue\n is true, this means\nit will never go through formatters, all of its whitespace is\nsent to clients verbatim and expressions are not processed.\n\n\nThe same rules for editing messages (see \nedit_query\n) apply here\nand the same error objects are returned for violations.\n\n\nYou may optionally set this value as well when using \nedit_post\n,\nbut if this is the only change you want to make to the message,\nusing this endpoint instead is preferable.\n\n\nset_thread_pin\n\n\nArgs:\n\n\nthread_id\n: string: the id of the thread to modify.\n\n\nvalue\n: boolean: \ntrue\n to pin thread, \nfalse\n otherwise.\n\n\nRequires the arguments \nthread_id\n and \nvalue\n. \nvalue\n\nmust be a boolean of what the pinned status should be.\nThis method requires that the caller is logged in and\nhas admin status on their account.\n\n\nReturns the same boolean you supply as \nvalue\n\n\nthread_create\n\n\nArgs:\n\n\nbody\n: string: The body of the first message\n\n\ntitle\n: string: The title name for this thread\n\n\nOPTIONAL: send_raw\n: boolean: formatting mode for the first message.\n\n\nCreates a new thread and returns it. Requires the non-empty\nstring arguments \nbody\n and \ntitle\n.\n\n\nIf the argument \nsend_raw\n is specified and has a non-nil\nvalue, the OP message will never recieve special formatting.\n\n\nthread_index\n\n\nArgs:\n\n\nOPTIONAL: include_op\n: boolean: Include a \nmessages\n object with the original post\n\n\nReturn an array with all the threads, ordered by most recent activity.\nRequires no arguments.\n\n\nOptionally, you may supply the argument \ninclude_op\n, which, when\nnon-nil, will include a \"messages\" key with the object, whose sole\ncontent is the original message (post_id 0).\n\n\nthread_load\n\n\nArgs:\n\n\nthread_id\n: string: the thread to load.\n\n\nOPTIONAL: op_only\n: boolean: include only the original message in \nmessages\n\n\nOPTIONAL: format\n: string: the formatting type of the returned messages.\n\n\nReturns the thread object with all of its messages loaded.\nRequires the argument \nthread_id\n. \nformat\n may also be\nspecified as a formatter to run the messages through.\nCurrently only \"sequential\" is supported.\n\n\nYou may also supply the parameter \nop_only\n. When it's value\nis non-nil, the messages array will only include post_id 0 (the first)\n\n\nthread_reply\n\n\nArgs:\n\n\nthread_id\n: string: the id for the thread this message should post to.\n\n\nbody\n: string: the message's body of text.\n\n\nOPTIONAL: send_raw\n: boolean: formatting mode for the posted message.\n\n\nCreates a new reply for the given thread and returns it.\nRequires the string arguments \nthread_id\n and \nbody\n\n\nIf the argument \nsend_raw\n is specified and has a non-nil\nvalue, the message will never recieve special formatting.\n\n\n\n\nTools\n\n\ndb_validate\n\n\nArgs:\n\n\nkey\n: string: the identifier for the ruleset to check.\n\n\nvalue\n: VARIES: the object for which \nkey\n will check for.\n\n\nOPTIONAL: error\n: boolean: when \ntrue\n, will return an API error response instead of a special object.\n\n\nRequires the arguments \nkey\n and \nvalue\n. Returns an object\nwith information about the database sanity criteria for\nkey. This can be used to validate user input in the client\nbefore trying to send it to the server.\n\n\nIf the argument \nerror\n is supplied with a non-nil value,\nthe server will return a standard error object on failure\ninstead of the special object described below.\n\n\nThe returned object has two keys:\n\n\n{\n  \"bool\": true/false,\n  \"description\": null/\"why this value is bad\"\n}\n\n\nIf bool == false, description is a string describing the\nproblem. If bool == true, description is null and the\nprovided value is safe to use.\n\n\nformat_message\n\n\nArgs:\n\n\nbody\n: string: the message body to apply formatting to.\n\n\nformat\n: string: the specifier for the desired formatting engine\n\n\nRequires the arguments \nbody\n and \nformat\n. Applies\n\nformat\n to \nbody\n and returns the new object. See\n\nthread_load\n for supported specifications for \nformat\n.\n\n\nuser_map\n\n\nArgs:\n\n\nNo arguments\n\n\nReturns an array with all registered user_ids, with the usermap\nobject populated by their full objects.\n\n\n\n\nUsers\n\n\nget_me\n\n\nArgs:\n\n\nNo arguments\n\n\nRequires no arguments. Returns your internal user object,\nincluding your authorization hash.\n\n\nis_admin\n\n\nArgs:\n\n\ntarget_user\n: string: user_id or user_name to check against.\n\n\nRequires the argument \ntarget_user\n. Returns a boolean\nof whether that user is an admin.\n\n\nuser_get\n\n\nArgs:\n\n\ntarget_user\n: string: either a user_name or a user_id\n\n\nRetreive an external user object for the given \ntarget_user\n.\nCan be a user_id or user_name.\n\n\nuser_is_registered\n\n\nArgs:\n\n\ntarget_user\n: string: either a user_name or a user_id\n\n\nTakes the argument \ntarget_user\n and returns true or false\nwhether they are in the system or not.\n\n\nuser_register\n\n\nArgs:\n\n\nuser_name\n: string: the desired display name\n\n\nauth_hash\n: string: a sha256 hash of a password\n\n\nRegister a new user into the system and return the new object.\nRequires the string arguments \nuser_name\n and \nauth_hash\n.\nDo not send User/Auth headers with this method.\n\n\nuser_update\n\n\nArgs:\n\n\nAny of the following may be submitted:\n: \n\n\nuser_name\n: string: a desired display name\n\n\nauth_hash\n: string: sha256 hash for a new password\n\n\nquip\n: string: a short string that can be used as a signature\n\n\nbio\n: string: a user biography for their profile\n\n\ncolor\n: integer: 0-6, a display color for the user\n\n\nReceives new parameters and assigns them to the user_object\nin the database. The following new parameters can be supplied:\n\nuser_name\n, \nauth_hash\n, \nquip\n, \nbio\n, and \ncolor\n. Any number\nof them may be supplied.\n\n\nThe newly updated user object is returned on success.",
+            "text": "How to BBJ?\n\n\nInput\n\n\nBBJ is interacted with entirely through POST requests, whose bodies are\njson objects.\n\n\nThe endpoints, all listed below, can be contacted at the path /api/ relative\nto the root of where BBJ is hosted. If bbj is hosted on a server on port 80\nat the root:\n\n\nhttp://server.com/api/endpoint_here\n\n\nThe body of your request contains all of it's argument fields, instead of\nusing URL parameters. As a demonstration, to call \nthread_create\n,\nit requires two arguments: \ntitle\n, and \nbody\n. We put those argument\nnames at the root of the json object, and their values are the info\npassed into the API for that spot. Your input will look like this:\n\n\n{\n    \"title\": \"Hello world!!\",\n    \"body\": \"Hi! I am exploring this cool board thing!!\"\n}\n\n\n\n\nAnd you will POST this body to \nhttp://server.com:PORT/api/thread_create\n.\n\n\nA few endpoints do not require any arguments. These can still be POSTed to,\nbut the body may be completely empty or an empty json object. You can even\nGET these if you so choose.\n\n\nFor all endpoints, argument keys that are not consumed by the endpoint are\nignored. Posting an object with a key/value pair of \n\"sandwich\": True\n will\nnot clog up any pipes :) In the same vein, endpoints who dont take arguments\ndon't care if you supply them anyway.\n\n\nOutput\n\n\nBBJ returns data in a consistently formatted json object. The base object\nhas three keys: \ndata\n, \nusermap\n, and \nerror\n. Visualizied:\n\n\n{\n  \"error\":   false, // boolean false or error object\n  \"data\":    null,  // null or the requested data from endpoint.\n  \"usermap\": {}     // potentially empty object, maps user_ids to user objects\n}\n\n// If \"error\" is true, it looks like this:\n\n{\n  \"error\": {\n      \"code\": // an integer from 0 to 5,\n      \"description\": // a string describing the error in detail.\n  }\n  \"data\": null   // ALWAYS null if error is not false\n  \"usermap\": {}  // ALWAYS empty if error is not false\n}\n\n\n\n\ndata\n\n\ndata\n is what the endpoint actually returns. The type of contents vary\nby endpoint and are documented below. If an endpoint says it returns a\nboolean, it will look like \n\"data\": True\n. If it says it returns an array,\nit will look like \n\"data\": [\"stuff\", \"goes\", \"here\"]\n\n\nusermap\n\n\nThe usermap is a json object mapping user_ids within \ndata\n to full user\nobjects. BBJ handles users entirely by an ID system, meaning any references\nto them inside of response data will not include vital information like their\nusername, or their profile information. Instead, we fetch those values from\nthis usermap object. All of it's root keys are user_id's and their values\nare user objects. It should be noted that the anonymous user has it's own\nID and profile object as well.\n\n\nerror\n\n\nerror\n is typically \nfalse\n. If it is \nnot\n false, then the request failed\nand the json object that \nerror\n contains should be inspected. (see the above\nvisualation) Errors follow a strict code system, making it easy for your client\nto map these responses to native exception types or signals in your language of\nchoice. See \nthe full error page\n for details.\n\n\n\n\nAuthorization\n\n\n\n\ncheck_auth\n\n\nArguments:\n\n\n\n\n\n\ntarget_user\n: string: either a user_name or a user_id\n\n\n\n\n\n\ntarget_hash\n: string: sha256 hash for the password to check\n\n\n\n\n\n\nTakes the arguments \ntarget_user\n and \ntarget_hash\n, and\nreturns boolean true or false whether the hash is valid.\n\n\n\n\n\n\nThreads & Messages\n\n\n\n\ndelete_post\n\n\nArguments:\n\n\n\n\n\n\nthread_id\n: string: the id of the thread this message was posted in.\n\n\n\n\n\n\npost_id\n: integer: the id of the target message.\n\n\n\n\n\n\nRequires the arguments \nthread_id\n and \npost_id\n.\n\n\nDelete a message from a thread. The same rules apply\nhere as \nedit_post\n and \nedit_query\n: the logged in user\nmust either be the one who posted the message within 24hrs,\nor have admin rights. The same error descriptions and code\nare returned on falilure. Boolean true is returned on\nsuccess.\n\n\nIf the post_id is 0, the whole thread is deleted.\n\n\n\n\nedit_post\n\n\nArguments:\n\n\n\n\n\n\nthread_id\n: string: the thread the message was posted in.\n\n\n\n\n\n\npost_id\n: integer: the target post_id to edit.\n\n\n\n\n\n\nbody\n: string: the new message body.\n\n\n\n\n\n\nOPTIONAL: send_raw\n: boolean: set the formatting mode for the target message.\n\n\n\n\n\n\nReplace a post with a new body. Requires the arguments\n\nthread_id\n, \npost_id\n, and \nbody\n. This method verifies\nthat the user can edit a post before commiting the change,\notherwise an error object is returned whose description\nshould be shown to the user.\n\n\nTo perform sanity checks and retrieve the unformatted body\nof a post without actually attempting to replace it, use\n\nedit_query\n first.\n\n\nOptionally you may also include the argument \nsend_raw\n to\nset the message's formatting flag. However, if this is the\nonly change you would like to make, you should use the\nendpoint \nset_post_raw\n instead.\n\n\nReturns the new message object.\n\n\n\n\nedit_query\n\n\nArguments:\n\n\n\n\n\n\nthread_id\n: string: the id of the thread the message was posted in.\n\n\n\n\n\n\npost_id\n: integer: the id of the target message.\n\n\n\n\n\n\nQueries the database to ensure the user can edit a given\nmessage. Requires the arguments \nthread_id\n and \npost_id\n\n(does not require a new body)\n\n\nReturns the original message object without any formatting\non success. Returns a descriptive code 4 otherwise.\n\n\n\n\nmessage_feed\n\n\nArguments:\n\n\n\n\ntime\n: int/float: epoch/unix time of the earliest point of interest\n\n\n\n\nReturns a special object representing all activity on the board since\nthe argument \ntime\n, a unix/epoch timestamp.\n\n\n{\n    \"threads\": {\n        \"thread_id\": {\n            ...thread object\n        },\n        ...more thread_id/object pairs\n    },\n    \"messages\": [...standard message object array sorted by date]\n}\n\n\nThe message objects in \"messages\" are the same objects returned\nin threads normally. They each have a thread_id parameter, and\nyou can access metadata for these threads by the \"threads\" object\nwhich is also provided.\n\n\nThe \"messages\" array is already sorted by submission time, newest\nfirst. The order in the threads object is undefined and you should\ninstead use their \nlast_mod\n attribute if you intend to list them\nout visually.\n\n\nYou may optionally provide a \nformat\n argument: this is treated\nthe same way as the \nthread_load\n endpoint and you should refer\nto its documentation for more info.\n\n\n\n\nset_post_raw\n\n\nArguments:\n\n\n\n\n\n\nthread_id\n: string: the id of the thread the message was posted in.\n\n\n\n\n\n\npost_id\n: integer: the id of the target message.\n\n\n\n\n\n\nvalue\n: boolean: the new \nsend_raw\n value to apply to the message.\n\n\n\n\n\n\nRequires the boolean argument of \nvalue\n, string argument\n\nthread_id\n, and integer argument \npost_id\n. \nvalue\n, when false,\nmeans that the message will be passed through message formatters\nbefore being sent to clients. When \nvalue\n is true, this means\nit will never go through formatters, all of its whitespace is\nsent to clients verbatim and expressions are not processed.\n\n\nThe same rules for editing messages (see \nedit_query\n) apply here\nand the same error objects are returned for violations.\n\n\nYou may optionally set this value as well when using \nedit_post\n,\nbut if this is the only change you want to make to the message,\nusing this endpoint instead is preferable.\n\n\n\n\nset_thread_pin\n\n\nArguments:\n\n\n\n\n\n\nthread_id\n: string: the id of the thread to modify.\n\n\n\n\n\n\nvalue\n: boolean: \ntrue\n to pin thread, \nfalse\n otherwise.\n\n\n\n\n\n\nRequires the arguments \nthread_id\n and \nvalue\n. \nvalue\n\nmust be a boolean of what the pinned status should be.\nThis method requires that the caller is logged in and\nhas admin status on their account.\n\n\nReturns the same boolean you supply as \nvalue\n\n\n\n\nthread_create\n\n\nArguments:\n\n\n\n\n\n\nbody\n: string: The body of the first message\n\n\n\n\n\n\ntitle\n: string: The title name for this thread\n\n\n\n\n\n\nOPTIONAL: send_raw\n: boolean: formatting mode for the first message.\n\n\n\n\n\n\nCreates a new thread and returns it. Requires the non-empty\nstring arguments \nbody\n and \ntitle\n.\n\n\nIf the argument \nsend_raw\n is specified and has a non-nil\nvalue, the OP message will never recieve special formatting.\n\n\n\n\nthread_index\n\n\nArguments:\n\n\n\n\nOPTIONAL: include_op\n: boolean: Include a \nmessages\n object with the original post\n\n\n\n\nReturn an array with all the threads, ordered by most recent activity.\nRequires no arguments.\n\n\nOptionally, you may supply the argument \ninclude_op\n, which, when\nnon-nil, will include a \"messages\" key with the object, whose sole\ncontent is the original message (post_id 0).\n\n\n\n\nthread_load\n\n\nArguments:\n\n\n\n\n\n\nthread_id\n: string: the thread to load.\n\n\n\n\n\n\nOPTIONAL: op_only\n: boolean: include only the original message in \nmessages\n\n\n\n\n\n\nOPTIONAL: format\n: string: the formatting type of the returned messages.\n\n\n\n\n\n\nReturns the thread object with all of its messages loaded.\nRequires the argument \nthread_id\n. \nformat\n may also be\nspecified as a formatter to run the messages through.\nCurrently only \"sequential\" is supported.\n\n\nYou may also supply the parameter \nop_only\n. When it's value\nis non-nil, the messages array will only include post_id 0 (the first)\n\n\n\n\nthread_reply\n\n\nArguments:\n\n\n\n\n\n\nthread_id\n: string: the id for the thread this message should post to.\n\n\n\n\n\n\nbody\n: string: the message's body of text.\n\n\n\n\n\n\nOPTIONAL: send_raw\n: boolean: formatting mode for the posted message.\n\n\n\n\n\n\nCreates a new reply for the given thread and returns it.\nRequires the string arguments \nthread_id\n and \nbody\n\n\nIf the argument \nsend_raw\n is specified and has a non-nil\nvalue, the message will never recieve special formatting.\n\n\n\n\n\n\nTools\n\n\n\n\ndb_validate\n\n\nArguments:\n\n\n\n\n\n\nkey\n: string: the identifier for the ruleset to check.\n\n\n\n\n\n\nvalue\n: VARIES: the object for which \nkey\n will check for.\n\n\n\n\n\n\nOPTIONAL: error\n: boolean: when \ntrue\n, will return an API error response instead of a special object.\n\n\n\n\n\n\nRequires the arguments \nkey\n and \nvalue\n. Returns an object\nwith information about the database sanity criteria for\nkey. This can be used to validate user input in the client\nbefore trying to send it to the server.\n\n\nIf the argument \nerror\n is supplied with a non-nil value,\nthe server will return a standard error object on failure\ninstead of the special object described below.\n\n\nThe returned object has two keys:\n\n\n{\n  \"bool\": true/false,\n  \"description\": null/\"why this value is bad\"\n}\n\n\nIf bool == false, description is a string describing the\nproblem. If bool == true, description is null and the\nprovided value is safe to use.\n\n\n\n\nformat_message\n\n\nArguments:\n\n\n\n\n\n\nbody\n: string: the message body to apply formatting to.\n\n\n\n\n\n\nformat\n: string: the specifier for the desired formatting engine\n\n\n\n\n\n\nRequires the arguments \nbody\n and \nformat\n. Applies\n\nformat\n to \nbody\n and returns the new object. See\n\nthread_load\n for supported specifications for \nformat\n.\n\n\n\n\nuser_map\n\n\nrequires no arguments\n\n\nReturns an array with all registered user_ids, with the usermap\nobject populated by their full objects.\n\n\n\n\n\n\nUsers\n\n\n\n\nget_me\n\n\nrequires no arguments\n\n\nRequires no arguments. Returns your internal user object,\nincluding your authorization hash.\n\n\n\n\nis_admin\n\n\nArguments:\n\n\n\n\ntarget_user\n: string: user_id or user_name to check against.\n\n\n\n\nRequires the argument \ntarget_user\n. Returns a boolean\nof whether that user is an admin.\n\n\n\n\nuser_get\n\n\nArguments:\n\n\n\n\ntarget_user\n: string: either a user_name or a user_id\n\n\n\n\nRetreive an external user object for the given \ntarget_user\n.\nCan be a user_id or user_name.\n\n\n\n\nuser_is_registered\n\n\nArguments:\n\n\n\n\ntarget_user\n: string: either a user_name or a user_id\n\n\n\n\nTakes the argument \ntarget_user\n and returns true or false\nwhether they are in the system or not.\n\n\n\n\nuser_register\n\n\nArguments:\n\n\n\n\n\n\nuser_name\n: string: the desired display name\n\n\n\n\n\n\nauth_hash\n: string: a sha256 hash of a password\n\n\n\n\n\n\nRegister a new user into the system and return the new user object\non success. The returned object includes the same \nuser_name\n and\n\nauth_hash\n that you supply, in addition to all the default user\nparameters. Returns code 4 errors for any failures.\n\n\n\n\nuser_update\n\n\nArguments:\n\n\n\n\n\n\nAny of the following may be submitted\n: \n\n\n\n\n\n\nuser_name\n: string: a desired display name\n\n\n\n\n\n\nauth_hash\n: string: sha256 hash for a new password\n\n\n\n\n\n\nquip\n: string: a short string that can be used as a signature\n\n\n\n\n\n\nbio\n: string: a user biography for their profile\n\n\n\n\n\n\ncolor\n: integer: 0-6, a display color for the user\n\n\n\n\n\n\nReceives new parameters and assigns them to the user object.\nThis method requires that you send a valid User/Auth header\npair with your request, and the changes are made to that\naccount.\n\n\nTake care to keep your client's User/Auth header pair up to date\nafter using this method.\n\n\nThe newly updated user object is returned on success,\nincluding the \nauth_hash\n.",
             "title": "Overview & Endpoints"
         },
         {
@@ -62,233 +62,138 @@
         },
         {
             "location": "/api_overview/#check_auth",
-            "text": "",
+            "text": "Arguments:    target_user : string: either a user_name or a user_id    target_hash : string: sha256 hash for the password to check    Takes the arguments  target_user  and  target_hash , and\nreturns boolean true or false whether the hash is valid.",
             "title": "check_auth"
         },
         {
-            "location": "/api_overview/#args",
-            "text": "target_user : string: either a user_name or a user_id  target_hash : string: sha256 hash for the password to check  Takes the arguments  target_user  and  target_hash , and\nreturns boolean true or false whether the hash is valid.",
-            "title": "Args:"
-        },
-        {
             "location": "/api_overview/#threads-messages",
             "text": "",
             "title": "Threads &amp; Messages"
         },
         {
             "location": "/api_overview/#delete_post",
-            "text": "",
+            "text": "Arguments:    thread_id : string: the id of the thread this message was posted in.    post_id : integer: the id of the target message.    Requires the arguments  thread_id  and  post_id .  Delete a message from a thread. The same rules apply\nhere as  edit_post  and  edit_query : the logged in user\nmust either be the one who posted the message within 24hrs,\nor have admin rights. The same error descriptions and code\nare returned on falilure. Boolean true is returned on\nsuccess.  If the post_id is 0, the whole thread is deleted.",
             "title": "delete_post"
         },
         {
-            "location": "/api_overview/#args_1",
-            "text": "thread_id : string: the id of the thread this message was posted in.  post_id : integer: the id of the target message.  Requires the arguments  thread_id  and  post_id .  Delete a message from a thread. The same rules apply\nhere as  edit_post  and  edit_query : the logged in user\nmust either be the one who posted the message within 24hrs,\nor have admin rights. The same error descriptions and code\nare returned on falilure. Boolean true is returned on\nsuccess.  If the post_id is 0, the whole thread is deleted.",
-            "title": "Args:"
-        },
-        {
             "location": "/api_overview/#edit_post",
-            "text": "",
+            "text": "Arguments:    thread_id : string: the thread the message was posted in.    post_id : integer: the target post_id to edit.    body : string: the new message body.    OPTIONAL: send_raw : boolean: set the formatting mode for the target message.    Replace a post with a new body. Requires the arguments thread_id ,  post_id , and  body . This method verifies\nthat the user can edit a post before commiting the change,\notherwise an error object is returned whose description\nshould be shown to the user.  To perform sanity checks and retrieve the unformatted body\nof a post without actually attempting to replace it, use edit_query  first.  Optionally you may also include the argument  send_raw  to\nset the message's formatting flag. However, if this is the\nonly change you would like to make, you should use the\nendpoint  set_post_raw  instead.  Returns the new message object.",
             "title": "edit_post"
         },
         {
-            "location": "/api_overview/#args_2",
-            "text": "thread_id : string: the thread the message was posted in.  post_id : integer: the target post_id to edit.  body : string: the new message body.  OPTIONAL: send_raw : boolean: set the formatting mode for the target message.  Replace a post with a new body. Requires the arguments thread_id ,  post_id , and  body . This method verifies\nthat the user can edit a post before commiting the change,\notherwise an error object is returned whose description\nshould be shown to the user.  To perform sanity checks and retrieve the unformatted body\nof a post without actually attempting to replace it, use edit_query  first.  Optionally you may also include the argument  send_raw  to\nset the message's formatting flag. However, if this is the\nonly change you would like to make, you should use the\nendpoint  set_post_raw  instead.  Returns the new message object.",
-            "title": "Args:"
-        },
-        {
             "location": "/api_overview/#edit_query",
-            "text": "",
+            "text": "Arguments:    thread_id : string: the id of the thread the message was posted in.    post_id : integer: the id of the target message.    Queries the database to ensure the user can edit a given\nmessage. Requires the arguments  thread_id  and  post_id \n(does not require a new body)  Returns the original message object without any formatting\non success. Returns a descriptive code 4 otherwise.",
             "title": "edit_query"
         },
         {
-            "location": "/api_overview/#args_3",
-            "text": "thread_id : string: the id of the thread the message was posted in.  post_id : integer: the id of the target message.  Queries the database to ensure the user can edit a given\nmessage. Requires the arguments  thread_id  and  post_id \n(does not require a new body)  Returns the original message object without any formatting\non success. Returns a descriptive code 4 otherwise.",
-            "title": "Args:"
-        },
-        {
             "location": "/api_overview/#message_feed",
-            "text": "",
+            "text": "Arguments:   time : int/float: epoch/unix time of the earliest point of interest   Returns a special object representing all activity on the board since\nthe argument  time , a unix/epoch timestamp.  {\n    \"threads\": {\n        \"thread_id\": {\n            ...thread object\n        },\n        ...more thread_id/object pairs\n    },\n    \"messages\": [...standard message object array sorted by date]\n}  The message objects in \"messages\" are the same objects returned\nin threads normally. They each have a thread_id parameter, and\nyou can access metadata for these threads by the \"threads\" object\nwhich is also provided.  The \"messages\" array is already sorted by submission time, newest\nfirst. The order in the threads object is undefined and you should\ninstead use their  last_mod  attribute if you intend to list them\nout visually.  You may optionally provide a  format  argument: this is treated\nthe same way as the  thread_load  endpoint and you should refer\nto its documentation for more info.",
             "title": "message_feed"
         },
         {
-            "location": "/api_overview/#args_4",
-            "text": "time : int/float: epoch/unix time of the earliest point of interest  Returns a special object representing all activity on the board since\nthe argument  time , a unix/epoch timestamp.  {\n    \"threads\": {\n        \"thread_id\": {\n            ...thread object\n        },\n        ...more thread_id/object pairs\n    },\n    \"messages\": [...standard message object array sorted by date]\n}  The message objects in \"messages\" are the same objects returned\nin threads normally. They each have a thread_id parameter, and\nyou can access metadata for these threads by the \"threads\" object\nwhich is also provided.  The \"messages\" array is already sorted by submission time, newest\nfirst. The order in the threads object is undefined and you should\ninstead use their  last_mod  attribute if you intend to list them\nout visually.  You may optionally provide a  format  argument: this is treated\nthe same way as the  thread_load  endpoint and you should refer\nto its documentation for more info.",
-            "title": "Args:"
-        },
-        {
             "location": "/api_overview/#set_post_raw",
-            "text": "",
+            "text": "Arguments:    thread_id : string: the id of the thread the message was posted in.    post_id : integer: the id of the target message.    value : boolean: the new  send_raw  value to apply to the message.    Requires the boolean argument of  value , string argument thread_id , and integer argument  post_id .  value , when false,\nmeans that the message will be passed through message formatters\nbefore being sent to clients. When  value  is true, this means\nit will never go through formatters, all of its whitespace is\nsent to clients verbatim and expressions are not processed.  The same rules for editing messages (see  edit_query ) apply here\nand the same error objects are returned for violations.  You may optionally set this value as well when using  edit_post ,\nbut if this is the only change you want to make to the message,\nusing this endpoint instead is preferable.",
             "title": "set_post_raw"
         },
         {
-            "location": "/api_overview/#args_5",
-            "text": "thread_id : string: the id of the thread the message was posted in.  post_id : integer: the id of the target message.  value : boolean: the new  send_raw  value to apply to the message.  Requires the boolean argument of  value , string argument thread_id , and integer argument  post_id .  value , when false,\nmeans that the message will be passed through message formatters\nbefore being sent to clients. When  value  is true, this means\nit will never go through formatters, all of its whitespace is\nsent to clients verbatim and expressions are not processed.  The same rules for editing messages (see  edit_query ) apply here\nand the same error objects are returned for violations.  You may optionally set this value as well when using  edit_post ,\nbut if this is the only change you want to make to the message,\nusing this endpoint instead is preferable.",
-            "title": "Args:"
-        },
-        {
             "location": "/api_overview/#set_thread_pin",
-            "text": "",
+            "text": "Arguments:    thread_id : string: the id of the thread to modify.    value : boolean:  true  to pin thread,  false  otherwise.    Requires the arguments  thread_id  and  value .  value \nmust be a boolean of what the pinned status should be.\nThis method requires that the caller is logged in and\nhas admin status on their account.  Returns the same boolean you supply as  value",
             "title": "set_thread_pin"
         },
         {
-            "location": "/api_overview/#args_6",
-            "text": "thread_id : string: the id of the thread to modify.  value : boolean:  true  to pin thread,  false  otherwise.  Requires the arguments  thread_id  and  value .  value \nmust be a boolean of what the pinned status should be.\nThis method requires that the caller is logged in and\nhas admin status on their account.  Returns the same boolean you supply as  value",
-            "title": "Args:"
-        },
-        {
             "location": "/api_overview/#thread_create",
-            "text": "",
+            "text": "Arguments:    body : string: The body of the first message    title : string: The title name for this thread    OPTIONAL: send_raw : boolean: formatting mode for the first message.    Creates a new thread and returns it. Requires the non-empty\nstring arguments  body  and  title .  If the argument  send_raw  is specified and has a non-nil\nvalue, the OP message will never recieve special formatting.",
             "title": "thread_create"
         },
         {
-            "location": "/api_overview/#args_7",
-            "text": "body : string: The body of the first message  title : string: The title name for this thread  OPTIONAL: send_raw : boolean: formatting mode for the first message.  Creates a new thread and returns it. Requires the non-empty\nstring arguments  body  and  title .  If the argument  send_raw  is specified and has a non-nil\nvalue, the OP message will never recieve special formatting.",
-            "title": "Args:"
-        },
-        {
             "location": "/api_overview/#thread_index",
-            "text": "",
+            "text": "Arguments:   OPTIONAL: include_op : boolean: Include a  messages  object with the original post   Return an array with all the threads, ordered by most recent activity.\nRequires no arguments.  Optionally, you may supply the argument  include_op , which, when\nnon-nil, will include a \"messages\" key with the object, whose sole\ncontent is the original message (post_id 0).",
             "title": "thread_index"
         },
         {
-            "location": "/api_overview/#args_8",
-            "text": "OPTIONAL: include_op : boolean: Include a  messages  object with the original post  Return an array with all the threads, ordered by most recent activity.\nRequires no arguments.  Optionally, you may supply the argument  include_op , which, when\nnon-nil, will include a \"messages\" key with the object, whose sole\ncontent is the original message (post_id 0).",
-            "title": "Args:"
-        },
-        {
             "location": "/api_overview/#thread_load",
-            "text": "",
+            "text": "Arguments:    thread_id : string: the thread to load.    OPTIONAL: op_only : boolean: include only the original message in  messages    OPTIONAL: format : string: the formatting type of the returned messages.    Returns the thread object with all of its messages loaded.\nRequires the argument  thread_id .  format  may also be\nspecified as a formatter to run the messages through.\nCurrently only \"sequential\" is supported.  You may also supply the parameter  op_only . When it's value\nis non-nil, the messages array will only include post_id 0 (the first)",
             "title": "thread_load"
         },
         {
-            "location": "/api_overview/#args_9",
-            "text": "thread_id : string: the thread to load.  OPTIONAL: op_only : boolean: include only the original message in  messages  OPTIONAL: format : string: the formatting type of the returned messages.  Returns the thread object with all of its messages loaded.\nRequires the argument  thread_id .  format  may also be\nspecified as a formatter to run the messages through.\nCurrently only \"sequential\" is supported.  You may also supply the parameter  op_only . When it's value\nis non-nil, the messages array will only include post_id 0 (the first)",
-            "title": "Args:"
-        },
-        {
             "location": "/api_overview/#thread_reply",
-            "text": "",
+            "text": "Arguments:    thread_id : string: the id for the thread this message should post to.    body : string: the message's body of text.    OPTIONAL: send_raw : boolean: formatting mode for the posted message.    Creates a new reply for the given thread and returns it.\nRequires the string arguments  thread_id  and  body  If the argument  send_raw  is specified and has a non-nil\nvalue, the message will never recieve special formatting.",
             "title": "thread_reply"
         },
         {
-            "location": "/api_overview/#args_10",
-            "text": "thread_id : string: the id for the thread this message should post to.  body : string: the message's body of text.  OPTIONAL: send_raw : boolean: formatting mode for the posted message.  Creates a new reply for the given thread and returns it.\nRequires the string arguments  thread_id  and  body  If the argument  send_raw  is specified and has a non-nil\nvalue, the message will never recieve special formatting.",
-            "title": "Args:"
-        },
-        {
             "location": "/api_overview/#tools",
             "text": "",
             "title": "Tools"
         },
         {
             "location": "/api_overview/#db_validate",
-            "text": "",
+            "text": "Arguments:    key : string: the identifier for the ruleset to check.    value : VARIES: the object for which  key  will check for.    OPTIONAL: error : boolean: when  true , will return an API error response instead of a special object.    Requires the arguments  key  and  value . Returns an object\nwith information about the database sanity criteria for\nkey. This can be used to validate user input in the client\nbefore trying to send it to the server.  If the argument  error  is supplied with a non-nil value,\nthe server will return a standard error object on failure\ninstead of the special object described below.  The returned object has two keys:  {\n  \"bool\": true/false,\n  \"description\": null/\"why this value is bad\"\n}  If bool == false, description is a string describing the\nproblem. If bool == true, description is null and the\nprovided value is safe to use.",
             "title": "db_validate"
         },
         {
-            "location": "/api_overview/#args_11",
-            "text": "key : string: the identifier for the ruleset to check.  value : VARIES: the object for which  key  will check for.  OPTIONAL: error : boolean: when  true , will return an API error response instead of a special object.  Requires the arguments  key  and  value . Returns an object\nwith information about the database sanity criteria for\nkey. This can be used to validate user input in the client\nbefore trying to send it to the server.  If the argument  error  is supplied with a non-nil value,\nthe server will return a standard error object on failure\ninstead of the special object described below.  The returned object has two keys:  {\n  \"bool\": true/false,\n  \"description\": null/\"why this value is bad\"\n}  If bool == false, description is a string describing the\nproblem. If bool == true, description is null and the\nprovided value is safe to use.",
-            "title": "Args:"
-        },
-        {
             "location": "/api_overview/#format_message",
-            "text": "",
+            "text": "Arguments:    body : string: the message body to apply formatting to.    format : string: the specifier for the desired formatting engine    Requires the arguments  body  and  format . Applies format  to  body  and returns the new object. See thread_load  for supported specifications for  format .",
             "title": "format_message"
         },
         {
-            "location": "/api_overview/#args_12",
-            "text": "body : string: the message body to apply formatting to.  format : string: the specifier for the desired formatting engine  Requires the arguments  body  and  format . Applies format  to  body  and returns the new object. See thread_load  for supported specifications for  format .",
-            "title": "Args:"
-        },
-        {
             "location": "/api_overview/#user_map",
-            "text": "",
+            "text": "requires no arguments  Returns an array with all registered user_ids, with the usermap\nobject populated by their full objects.",
             "title": "user_map"
         },
         {
-            "location": "/api_overview/#args_13",
-            "text": "No arguments  Returns an array with all registered user_ids, with the usermap\nobject populated by their full objects.",
-            "title": "Args:"
-        },
-        {
             "location": "/api_overview/#users",
             "text": "",
             "title": "Users"
         },
         {
             "location": "/api_overview/#get_me",
-            "text": "",
+            "text": "requires no arguments  Requires no arguments. Returns your internal user object,\nincluding your authorization hash.",
             "title": "get_me"
         },
         {
-            "location": "/api_overview/#args_14",
-            "text": "No arguments  Requires no arguments. Returns your internal user object,\nincluding your authorization hash.",
-            "title": "Args:"
-        },
-        {
             "location": "/api_overview/#is_admin",
-            "text": "",
+            "text": "Arguments:   target_user : string: user_id or user_name to check against.   Requires the argument  target_user . Returns a boolean\nof whether that user is an admin.",
             "title": "is_admin"
         },
         {
-            "location": "/api_overview/#args_15",
-            "text": "target_user : string: user_id or user_name to check against.  Requires the argument  target_user . Returns a boolean\nof whether that user is an admin.",
-            "title": "Args:"
-        },
-        {
             "location": "/api_overview/#user_get",
-            "text": "",
+            "text": "Arguments:   target_user : string: either a user_name or a user_id   Retreive an external user object for the given  target_user .\nCan be a user_id or user_name.",
             "title": "user_get"
         },
         {
-            "location": "/api_overview/#args_16",
-            "text": "target_user : string: either a user_name or a user_id  Retreive an external user object for the given  target_user .\nCan be a user_id or user_name.",
-            "title": "Args:"
-        },
-        {
             "location": "/api_overview/#user_is_registered",
-            "text": "",
+            "text": "Arguments:   target_user : string: either a user_name or a user_id   Takes the argument  target_user  and returns true or false\nwhether they are in the system or not.",
             "title": "user_is_registered"
         },
         {
-            "location": "/api_overview/#args_17",
-            "text": "target_user : string: either a user_name or a user_id  Takes the argument  target_user  and returns true or false\nwhether they are in the system or not.",
-            "title": "Args:"
-        },
-        {
             "location": "/api_overview/#user_register",
-            "text": "",
+            "text": "Arguments:    user_name : string: the desired display name    auth_hash : string: a sha256 hash of a password    Register a new user into the system and return the new user object\non success. The returned object includes the same  user_name  and auth_hash  that you supply, in addition to all the default user\nparameters. Returns code 4 errors for any failures.",
             "title": "user_register"
         },
         {
-            "location": "/api_overview/#args_18",
-            "text": "user_name : string: the desired display name  auth_hash : string: a sha256 hash of a password  Register a new user into the system and return the new object.\nRequires the string arguments  user_name  and  auth_hash .\nDo not send User/Auth headers with this method.",
-            "title": "Args:"
-        },
-        {
             "location": "/api_overview/#user_update",
-            "text": "",
+            "text": "Arguments:    Any of the following may be submitted :     user_name : string: a desired display name    auth_hash : string: sha256 hash for a new password    quip : string: a short string that can be used as a signature    bio : string: a user biography for their profile    color : integer: 0-6, a display color for the user    Receives new parameters and assigns them to the user object.\nThis method requires that you send a valid User/Auth header\npair with your request, and the changes are made to that\naccount.  Take care to keep your client's User/Auth header pair up to date\nafter using this method.  The newly updated user object is returned on success,\nincluding the  auth_hash .",
             "title": "user_update"
         },
         {
-            "location": "/api_overview/#args_19",
-            "text": "Any of the following may be submitted: :   user_name : string: a desired display name  auth_hash : string: sha256 hash for a new password  quip : string: a short string that can be used as a signature  bio : string: a user biography for their profile  color : integer: 0-6, a display color for the user  Receives new parameters and assigns them to the user_object\nin the database. The following new parameters can be supplied: user_name ,  auth_hash ,  quip ,  bio , and  color . Any number\nof them may be supplied.  The newly updated user object is returned on success.",
-            "title": "Args:"
-        },
-        {
             "location": "/errors/",
-            "text": "Errors in BBJ are separated into 6 different codes to help\nease handling a little bit. Errors are all or nothing, there\nare no \"warnings\". If a response has a non-false error field,\nthen data will always be null. An error response from the api\nlooks like this...\n\n\n{\n  \"error\": {\n      \"code\": // an integer from 0 to 5,\n      \"description\": // a string describing the error in detail.\n  }\n  \"data\": null   // ALWAYS null if error is not false\n  \"usermap\": {}  // ALWAYS empty if error is not false\n}\n\n\n\n\nThe codes split errors into a few categories. Some are oriented\nto client developers while others should be shown directly to\nusers.\n\n\n\n\n0: Malformed but non-empty json input. An empty json input where it is required is handled by code 3. This is just decoding errors. The exception text is returned as description.\n\n\n1: Internal server error. A short representation of the internal exception as well as the code the server logged it as is returned in the description. Your clients cannot recover from this class of error, and its probably not your fault if you encounter it. If you ever get one, file a bug report.\n\n\n2: Server HTTP error: This is similar to the above but captures errors for the HTTP server rather than BBJs own codebase. The description contains the HTTP error code and server description. This notably covers 404s and thus invalid endpoint names.\n\n\n3: Parameter error: client sent erroneous input for its method. This could mean missing arguments, type errors, etc. It generalizes errors that should be fixed by the client developer and the returned descriptions are geared to them rather than end users.\n\n\n4: User error: These errors regard actions that the user has taken that are invalid, but not really errors in a traditional sense. The description field should be shown to users verbatim, in a clear and noticeable fashion. They are formatted as concise English sentences and end with appropriate punctuation marks.\n\n\n5: Authorization error: This code represents an erroneous User/Auth header pair. This should trigger the user to provide correct credentials or fall back to anon mode.",
+            "text": "Handling Error Responses\n\n\nErrors in BBJ are separated into 6 different codes, to allow easy mapping to\nnative exception and signaling systems available in the client's programming\nlanguage. Errors are all or nothing, there are no \"warnings\". If a response has\na non-false error field, then data will always be null. An error response from\nthe api looks like this...\n\n\n{\n  \"error\": {\n      \"code\": // an integer from 0 to 5,\n      \"description\": // a string describing the error in detail.\n  }\n  \"data\": null   // ALWAYS null if error is not false\n  \"usermap\": {}  // ALWAYS empty if error is not false\n}\n\n\n\n\nThe codes split errors into categories. Some are oriented\nto client developers while others should be shown directly to\nusers.\n\n\n\n\n\n\nCode 0\n: Malformed but non-empty json input. An empty json input where it is required is handled by code 3. This is just decoding errors. The exception text is returned as description.\n\n\n\n\n\n\nCode 1\n: Internal server error. A short representation of the internal exception as well as the code the server logged it as is returned in the description. Your clients cannot recover from this class of error, and its probably not your fault if you encounter it. If you ever get one, file a bug report.\n\n\n\n\n\n\nCode 2\n: Server HTTP error: This is similar to the above but captures errors for the HTTP server rather than BBJs own codebase. The description contains the HTTP error code and server description. This notably covers 404s and thus invalid endpoint names. The HTTP error code is left intact, so you may choose to let your HTTP library or tool of choice handle these for you.\n\n\n\n\n\n\nCode 3\n: Parameter error: client sent erroneous input for its method. This could mean missing arguments, type errors, etc. It generalizes errors that should be fixed by the client developer and the returned descriptions are geared to them rather than end users.\n\n\n\n\n\n\nCode 4\n: User error: These errors regard actions that the user has taken that are invalid, but not really errors in a traditional sense. The description field should be shown to users verbatim, in a clear and noticeable fashion. They are formatted as concise English sentences and end with appropriate punctuation marks.\n\n\n\n\n\n\nCode 5\n: Authorization error: This code represents an erroneous User/Auth header pair. This should trigger the user to provide correct credentials or fall back to anon mode.",
             "title": "Errors"
         },
         {
+            "location": "/errors/#handling-error-responses",
+            "text": "Errors in BBJ are separated into 6 different codes, to allow easy mapping to\nnative exception and signaling systems available in the client's programming\nlanguage. Errors are all or nothing, there are no \"warnings\". If a response has\na non-false error field, then data will always be null. An error response from\nthe api looks like this...  {\n  \"error\": {\n      \"code\": // an integer from 0 to 5,\n      \"description\": // a string describing the error in detail.\n  }\n  \"data\": null   // ALWAYS null if error is not false\n  \"usermap\": {}  // ALWAYS empty if error is not false\n}  The codes split errors into categories. Some are oriented\nto client developers while others should be shown directly to\nusers.    Code 0 : Malformed but non-empty json input. An empty json input where it is required is handled by code 3. This is just decoding errors. The exception text is returned as description.    Code 1 : Internal server error. A short representation of the internal exception as well as the code the server logged it as is returned in the description. Your clients cannot recover from this class of error, and its probably not your fault if you encounter it. If you ever get one, file a bug report.    Code 2 : Server HTTP error: This is similar to the above but captures errors for the HTTP server rather than BBJs own codebase. The description contains the HTTP error code and server description. This notably covers 404s and thus invalid endpoint names. The HTTP error code is left intact, so you may choose to let your HTTP library or tool of choice handle these for you.    Code 3 : Parameter error: client sent erroneous input for its method. This could mean missing arguments, type errors, etc. It generalizes errors that should be fixed by the client developer and the returned descriptions are geared to them rather than end users.    Code 4 : User error: These errors regard actions that the user has taken that are invalid, but not really errors in a traditional sense. The description field should be shown to users verbatim, in a clear and noticeable fashion. They are formatted as concise English sentences and end with appropriate punctuation marks.    Code 5 : Authorization error: This code represents an erroneous User/Auth header pair. This should trigger the user to provide correct credentials or fall back to anon mode.",
+            "title": "Handling Error Responses"
+        },
+        {
             "location": "/validation/",
-            "text": "The server has an endpoint called \ndb_validate\n. What this does is take\na \nkey\n and a \nvalue\n and compares \nvalue\n to a set of rules specified by\n\nkey\n. This is the same function used internally by the database to scan\nvalues before committing them to the database. By default it returns a\ndescriptive object under \ndata\n, but you can specify the key/value pair\n\n\"error\": True\n to get a standard error response back. A standard call\nto \ndb_validate\n will look like this.\n\n\n{\n    \"key\": \"title\",\n    \"value\": \"this title\\nis bad \\nbecause it contains \\nnewlines\"\n}\n\n\n\n\nand the server will respond like this when the input should be corrected.\n\n\n{\n    \"data\": {\n        \"bool\": False,\n        \"description\": \"Titles cannot contain whitespace characters besides spaces.\"\n    },\n    \"error\": False,\n    \"usermap\": {}\n}\n\n\n\n\nif everything is okay, the data object will look like this instead.\n\n\n    \"data\": {\n        \"bool\": True,\n        \"description\": null\n    },\n\n\n\n\nAlternatively, you can supply \n\"error\": True\n in the request.\n\n\n{\n    \"error\": True,\n    \"key\": \"title\",\n    \"value\": \"this title\\nis bad \\nbecause it contains \\nnewlines\"\n}\n// and you get...\n{\n    \"data\": null,\n    \"usermap\": {},\n    \"error\": {\n        \"code\": 4,\n        \"description\": \"Titles cannot contain whitespace characters besides spaces.\"\n    }\n}\n\n\n\n\nThe following keys are currently available.\n\n\n\n\n\"user_name\"\n\n\n\"auth_hash\"\n\n\n\"quip\"\n\n\n\"bio\"\n\n\n\"title\"\n\n\n\"body\"\n\n\n\"color\"\n\n\n\n\nThe descriptions returned are friendly, descriptive, and should be shown\ndirectly to users\n\n\nImplementing good sanity checks in your client\n\n\nBy using this endpoint, you will never have to validate values in your\nown code before sending them to the server. This means you can do things\nlike implement an interactive prompt which will not allow the user to\nsubmit it unless the value is correct.\n\n\nThis is used in the elisp client when registering users and for the thread\ntitle prompt which is shown before opening a composure window. The reason\nfor rejection is displayed clearly to the user and input window is restored.\n\n\n(defun bbj-sane-value (prompt key)\n  \"Opens an input loop with the user, where the response is\npassed to the server to check it for validity before the\nuser is allowed to continue. Will recurse until the input\nis valid, then it is returned.\"\n  (let* ((value (read-from-minibuffer prompt))\n         (response (bbj-request! 'db_validate\n                     'value value 'key key)))\n    (if (alist-get 'bool response)\n        value\n      (message (alist-get 'description response))\n      (sit-for 2)\n      (bbj-sane-value prompt key))))",
+            "text": "Implementing good sanity checks in your client.\n\n\nThe server has an endpoint called \ndb_validate\n. What this does is take\na \nkey\n and a \nvalue\n argument, and compares \nvalue\n to a set of rules specified by\n\nkey\n. This is the same function used internally by the database to check\nvalues before committing them to the database. By default it returns a\ndescriptive object under \ndata\n, but you can specify the key/value pair\n\n\"error\": True\n to get a standard error response back. A standard call\nto \ndb_validate\n will look like this.\n\n\n{\n    \"key\": \"title\",\n    \"value\": \"this title\\nis bad \\nbecause it contains \\nnewlines\"\n}\n\n\n\n\nand the server will respond like this when the input should be corrected.\n\n\n{\n    \"data\": {\n        \"bool\": False,\n        \"description\": \"Titles cannot contain whitespace characters besides spaces.\"\n    },\n    \"error\": False,\n    \"usermap\": {}\n}\n\n\n\n\nif everything is okay, the data object will look like this instead.\n\n\n    \"data\": {\n        \"bool\": True,\n        \"description\": null\n    },\n\n\n\n\nAlternatively, you can supply \n\"error\": True\n in the request.\n\n\n{\n    \"error\": True,\n    \"key\": \"title\",\n    \"value\": \"this title\\nis bad \\nbecause it contains \\nnewlines\"\n}\n// and you get...\n{\n    \"data\": null,\n    \"usermap\": {},\n    \"error\": {\n        \"code\": 4,\n        \"description\": \"Titles cannot contain whitespace characters besides spaces.\"\n    }\n}\n\n\n\n\nThe following keys are currently available.\n\n\n\n\n\"user_name\"\n\n\n\"auth_hash\"\n\n\n\"quip\"\n\n\n\"bio\"\n\n\n\"title\"\n\n\n\"body\"\n\n\n\"color\"\n\n\n\n\nThe descriptions returned are friendly, descriptive, and should be shown\ndirectly to users\n\n\nBy using this endpoint, you will never have to validate values in your\nown code before sending them to the server. This means you can do things\nlike implement an interactive prompt which will not allow the user to\nsubmit it unless the value is correct.\n\n\nThis is used in the elisp client when registering users and for the thread\ntitle prompt which is shown before opening a composure window. The reason\nfor rejection is displayed clearly to the user and input window is restored.\n\n\n(defun bbj-sane-value (prompt key)\n  \"Opens an input loop with the user, where the response is\npassed to the server to check it for validity before the\nuser is allowed to continue. Will recurse until the input\nis valid, then it is returned.\"\n  (let* ((value (read-from-minibuffer prompt))\n         (response (bbj-request! 'db_validate 'value value 'key key)))\n    (if (alist-get 'bool response)\n        value ;; return the user's input back to the caller\n      (message (alist-get 'description response))\n      (sit-for 2)\n      (bbj-sane-value prompt key))))",
             "title": "Input Validation"
         },
         {
             "location": "/validation/#implementing-good-sanity-checks-in-your-client",
-            "text": "By using this endpoint, you will never have to validate values in your\nown code before sending them to the server. This means you can do things\nlike implement an interactive prompt which will not allow the user to\nsubmit it unless the value is correct.  This is used in the elisp client when registering users and for the thread\ntitle prompt which is shown before opening a composure window. The reason\nfor rejection is displayed clearly to the user and input window is restored.  (defun bbj-sane-value (prompt key)\n  \"Opens an input loop with the user, where the response is\npassed to the server to check it for validity before the\nuser is allowed to continue. Will recurse until the input\nis valid, then it is returned.\"\n  (let* ((value (read-from-minibuffer prompt))\n         (response (bbj-request! 'db_validate\n                     'value value 'key key)))\n    (if (alist-get 'bool response)\n        value\n      (message (alist-get 'description response))\n      (sit-for 2)\n      (bbj-sane-value prompt key))))",
-            "title": "Implementing good sanity checks in your client"
+            "text": "The server has an endpoint called  db_validate . What this does is take\na  key  and a  value  argument, and compares  value  to a set of rules specified by key . This is the same function used internally by the database to check\nvalues before committing them to the database. By default it returns a\ndescriptive object under  data , but you can specify the key/value pair \"error\": True  to get a standard error response back. A standard call\nto  db_validate  will look like this.  {\n    \"key\": \"title\",\n    \"value\": \"this title\\nis bad \\nbecause it contains \\nnewlines\"\n}  and the server will respond like this when the input should be corrected.  {\n    \"data\": {\n        \"bool\": False,\n        \"description\": \"Titles cannot contain whitespace characters besides spaces.\"\n    },\n    \"error\": False,\n    \"usermap\": {}\n}  if everything is okay, the data object will look like this instead.      \"data\": {\n        \"bool\": True,\n        \"description\": null\n    },  Alternatively, you can supply  \"error\": True  in the request.  {\n    \"error\": True,\n    \"key\": \"title\",\n    \"value\": \"this title\\nis bad \\nbecause it contains \\nnewlines\"\n}\n// and you get...\n{\n    \"data\": null,\n    \"usermap\": {},\n    \"error\": {\n        \"code\": 4,\n        \"description\": \"Titles cannot contain whitespace characters besides spaces.\"\n    }\n}  The following keys are currently available.   \"user_name\"  \"auth_hash\"  \"quip\"  \"bio\"  \"title\"  \"body\"  \"color\"   The descriptions returned are friendly, descriptive, and should be shown\ndirectly to users  By using this endpoint, you will never have to validate values in your\nown code before sending them to the server. This means you can do things\nlike implement an interactive prompt which will not allow the user to\nsubmit it unless the value is correct.  This is used in the elisp client when registering users and for the thread\ntitle prompt which is shown before opening a composure window. The reason\nfor rejection is displayed clearly to the user and input window is restored.  (defun bbj-sane-value (prompt key)\n  \"Opens an input loop with the user, where the response is\npassed to the server to check it for validity before the\nuser is allowed to continue. Will recurse until the input\nis valid, then it is returned.\"\n  (let* ((value (read-from-minibuffer prompt))\n         (response (bbj-request! 'db_validate 'value value 'key key)))\n    (if (alist-get 'bool response)\n        value ;; return the user's input back to the caller\n      (message (alist-get 'description response))\n      (sit-for 2)\n      (bbj-sane-value prompt key))))",
+            "title": "Implementing good sanity checks in your client."
         }
     ]
 }
\ No newline at end of file
diff --git a/documentation/site/validation/index.html b/documentation/site/validation/index.html
index 7d60ca0..897c330 100644
--- a/documentation/site/validation/index.html
+++ b/documentation/site/validation/index.html
@@ -91,14 +91,15 @@
         <div class="container">
                 <div class="col-md-3"><div class="bs-sidebar hidden-print affix well" role="complementary">
     <ul class="nav bs-sidenav">
-        <li class="main active"><a href="#implementing-good-sanity-checks-in-your-client">Implementing good sanity checks in your client</a></li>
+        <li class="main active"><a href="#implementing-good-sanity-checks-in-your-client">Implementing good sanity checks in your client.</a></li>
     </ul>
 </div></div>
                 <div class="col-md-9" role="main">
 
+<h2 id="implementing-good-sanity-checks-in-your-client">Implementing good sanity checks in your client.</h2>
 <p>The server has an endpoint called <code>db_validate</code>. What this does is take
-a <code>key</code> and a <code>value</code> and compares <code>value</code> to a set of rules specified by
-<code>key</code>. This is the same function used internally by the database to scan
+a <code>key</code> and a <code>value</code> argument, and compares <code>value</code> to a set of rules specified by
+<code>key</code>. This is the same function used internally by the database to check
 values before committing them to the database. By default it returns a
 descriptive object under <code>data</code>, but you can specify the key/value pair
 <code>"error": True</code> to get a standard error response back. A standard call
@@ -156,7 +157,6 @@ to <code>db_validate</code> will look like this.</p>
 </ul>
 <p>The descriptions returned are friendly, descriptive, and should be shown
 directly to users</p>
-<h2 id="implementing-good-sanity-checks-in-your-client">Implementing good sanity checks in your client</h2>
 <p>By using this endpoint, you will never have to validate values in your
 own code before sending them to the server. This means you can do things
 like implement an interactive prompt which will not allow the user to
@@ -164,16 +164,15 @@ submit it unless the value is correct.</p>
 <p>This is used in the elisp client when registering users and for the thread
 title prompt which is shown before opening a composure window. The reason
 for rejection is displayed clearly to the user and input window is restored.</p>
-<pre><code>(defun bbj-sane-value (prompt key)
+<pre><code class="lisp">(defun bbj-sane-value (prompt key)
   &quot;Opens an input loop with the user, where the response is
 passed to the server to check it for validity before the
 user is allowed to continue. Will recurse until the input
 is valid, then it is returned.&quot;
   (let* ((value (read-from-minibuffer prompt))
-         (response (bbj-request! 'db_validate
-                     'value value 'key key)))
+         (response (bbj-request! 'db_validate 'value value 'key key)))
     (if (alist-get 'bool response)
-        value
+        value ;; return the user's input back to the caller
       (message (alist-get 'description response))
       (sit-for 2)
       (bbj-sane-value prompt key))))
diff --git a/gendocs.sh b/gendocs.sh
new file mode 100755
index 0000000..d1870f1
--- /dev/null
+++ b/gendocs.sh
@@ -0,0 +1,9 @@
+#!/bin/sh
+# Generate the documentation site.
+# Invoke with no arguments in the base repo directory.
+# Nothing magical here.
+
+python3 ./mkendpoints.py
+cd ./documentation
+mkdocs build
+cd ..
diff --git a/document_endpoints.py b/mkendpoints.py
index ac5c874..c1d4aea 100644
--- a/document_endpoints.py
+++ b/mkendpoints.py
@@ -115,18 +115,19 @@ for function in endpoints:
     types[function.doctype].append(function)
 
 for doctype in sorted(types.keys()):
-    body += "# %s\n\n" % doctype
+    body += "<br><br>\n# %s\n------\n" % doctype
     funcs = sorted(types[doctype], key=lambda _: _.__name__)
     for f in funcs:
         body += "## %s\n\n" % f.__name__
-        body += "### Args:\n"
-        for key, value in f.arglist:
-            if key:
-                body += "**%s**: %s\n\n" % (key, value)
-            else:
-                body += "__No arguments__"
+        if f.arglist[0][0]:
+            body += "**Arguments:**\n\n"
+            for key, value in f.arglist:
+                body += " * __%s__: %s\n\n" % (key, value)
+        else:
+            body += "_requires no arguments_"
+
         body += "\n\n" + pydoc.getdoc(f) + "\n\n"
-    body += "\n\n--------\n\n"
+        body += "\n<br>\n"
 
 with open("documentation/docs/api_overview.md", "w") as output:
     output.write(body)
diff --git a/server.py b/server.py
index b29d3d5..6061566 100644
--- a/server.py
+++ b/server.py
@@ -176,18 +176,22 @@ def no_anon_hook(user, message=None, user_error=True):
 
 class API(object):
     """
-    This object contains all the API endpoints for bbj.
-    The html serving part of the server is not written
-    yet, so this is currently the only module being
-    served.
+    This object contains all the API endpoints for bbj. The html serving
+    part of the server is not written yet, so this is currently the only
+    module being served.
+
+    The docstrings below are specifically formatted for the mkdocs static
+    site generator. The ugly `doctype` and `arglist` attributes assigned
+    after each method definition are for use in the `mkendpoints.py` script.
     """
 
     @api_method
     def user_register(self, args, database, user, **kwargs):
         """
-        Register a new user into the system and return the new object.
-        Requires the string arguments `user_name` and `auth_hash`.
-        Do not send User/Auth headers with this method.
+        Register a new user into the system and return the new user object
+        on success. The returned object includes the same `user_name` and
+        `auth_hash` that you supply, in addition to all the default user
+        parameters. Returns code 4 errors for any failures.
         """
         validate(args, ["user_name", "auth_hash"])
         return db.user_register(
@@ -201,19 +205,23 @@ class API(object):
     @api_method
     def user_update(self, args, database, user, **kwargs):
         """
-        Receives new parameters and assigns them to the user_object
-        in the database. The following new parameters can be supplied:
-        `user_name`, `auth_hash`, `quip`, `bio`, and `color`. Any number
-        of them may be supplied.
+        Receives new parameters and assigns them to the user object.
+        This method requires that you send a valid User/Auth header
+        pair with your request, and the changes are made to that
+        account.
+
+        Take care to keep your client's User/Auth header pair up to date
+        after using this method.
 
-        The newly updated user object is returned on success.
+        The newly updated user object is returned on success,
+        including the `auth_hash`.
         """
         no_anon_hook(user, "Anons cannot modify their account.")
         validate(args, [])  # just make sure its not empty
         return db.user_update(database, user, args)
     user_update.doctype = "Users"
     user_update.arglist = (
-        ("Any of the following may be submitted:", ""),
+        ("Any of the following may be submitted", ""),
         ("user_name", "string: a desired display name"),
         ("auth_hash", "string: sha256 hash for a new password"),
         ("quip", "string: a short string that can be used as a signature"),