README.md in easypost-5.0.1 vs README.md in easypost-5.1.0

@@ -59,19 +59,21 @@
 ```
 
 ### Custom Connections
 
 Pass in a lambda function as `custom_client_exec` when initializing a client that responds to `call(method, uri, headers, open_timeout, read_timeout, body = nil)` where:
+
 - `uri` is the fully-qualified URL of the EasyPost endpoint, including query parameters (`Uri` object)
 - `method` is the lowercase name of the HTTP method being used for the request (e.g. `:get`, `:post`, `:put`, `:delete`)
 - `headers` is a hash with all headers needed for the request pre-populated, including authorization (`Hash` object)
 - `open_timeout` is the number of seconds to wait for the connection to open (integer)
 - `read_timeout` is the number of seconds to wait for one block to be read (integer)
 - `body` is a string of the body data to be included in the request, or nil (e.g. GET or DELETE request) (string or `nil`)
 
 The lambda function should return an object with `code` and `body` attributes, where:
-- `code` is the HTTP response status code (integer) 
+
+- `code` is the HTTP response status code (integer)
 - `body` is the response body (string)
 
 #### Faraday
 
 ```ruby
@@ -114,10 +116,53 @@
   api_key: ENV['EASYPOST_API_KEY'],
   custom_client_exec: custom_connection,
 )
 ```
 
+### HTTP Hooks
+
+Users can audit HTTP requests and responses being made by the library by subscribing to request and response events. To do so, pass a block to the `subscribe_request_hook` and `subscribe_response_hook` methods of an instance of `EasyPost::Client`:
+
+```ruby
+require 'easypost'
+
+client = EasyPost::Client.new(api_key: ENV['EASYPOST_API_KEY'])
+
+# Returns a randomly-generated symbol which you can use to later unsubscribe the request hook
+client.subscribe_request_hook do |request_data|
+  # Your code goes here
+end
+# Returns a randomly-generated symbol which you can use to later unsubscribe the response hook
+client.subscribe_response_hook do |response_data|
+  # Your code goes here
+end
+```
+
+You can also name your hook subscriptions by providing an optional parameter to the methods above:
+
+```ruby
+require 'easypost'
+
+client = EasyPost::Client.new(api_key: ENV['EASYPOST_API_KEY'])
+
+request_hook = client.subscribe_request_hook(:my_request_hook) do |request_data|
+  # Your code goes here
+end
+response_hook = client.subscribe_response_hook(:my_response_hook) do |response_data|
+  # Your code goes here
+end
+
+puts request_hook  # :my_request_hook
+puts response_hook # :my_response_hook
+```
+
+Keep in mind that subscribing a hook with the same name of an existing hook will replace the existing hook with the new one. A request hook and a response hook can share the same name.
+
+#### Custom HTTP Connections with HTTP Hooks
+
+If you're using a custom HTTP connection, keep in mind that the `response_data` parameter that a response hook receives *will not be hydrated* with all the response data. You will have to inspect the `client_response_object` property in `response_data` to inspect the response code, response headers and response body.
+
 ## Documentation
 
 API documentation can be found at: <https://easypost.com/docs/api>.
 
 Library documentation can be found on the web at: <https://easypost.github.io/easypost-ruby/> or by building them locally via the `make docs` command.
@@ -139,25 +184,22 @@
 # Install style guide (Unix only)
 make install-style
 
 # Lint project
 make lint
+make lint-fix
 
-# Fix linting errors
-make format
-
 # Run tests (coverage is generated on a successful test suite run)
 EASYPOST_TEST_API_KEY=123... EASYPOST_PROD_API_KEY=123... make test
 
 # Run security analysis
 make scan
 
 # Generate library documentation
 make docs
 
 # Update submodules
-git submodule init
-git submodule update --remote
+make update-examples-submodule
 ```
 
 ### Testing
 
 The test suite in this project was specifically built to produce consistent results on every run, regardless of when they run or who is running them. This project uses [VCR](https://github.com/vcr/vcr) to record and replay HTTP requests and responses via "cassettes". When the suite is run, the HTTP requests and responses for each test function will be saved to a cassette if they do not exist already and replayed from this saved file if they do, which saves the need to make live API calls on every test run. If you receive errors about a cassette expiring, delete and re-record the cassette to ensure the data is up-to-date.