demandchain · donovanbray · Apr 6, 2015 · Apr 6, 2015 · Apr 6, 2015 · Apr 7, 2015
diff --git a/.rvmrc.template b/.rvmrc.template
@@ -1 +1 @@
-rvm 1.9.3@developer.offerengine.com --create
+rvm 1.9.3-p327@developer.offerengine.com --create
diff --git a/Gemfile b/Gemfile
@@ -8,6 +8,7 @@ gem 'nokogiri', '~> 1.4.4'
 gem 'yajl-ruby', '~> 0.8.2'
 gem 'pygmentize', '~> 0.0.3'
 gem 'mime-types', '~> 1.16'
+gem 'guard-nanoc'
 
 group :development do
   gem 'adsf'

diff --git a/Gemfile.lock b/Gemfile.lock
@@ -1,27 +1,68 @@
 GEM
   remote: http://rubygems.org/
   specs:
-    adsf (1.0.1)
+    adsf (1.2.0)
       rack (>= 1.0.0)
-    cri (2.0.2)
-    kramdown (0.13.4)
-    mime-types (1.17.2)
-    nanoc (3.2.4)
-      nanoc3 (>= 3.2.4)
-    nanoc3 (3.2.4)
-      cri (~> 2.0)
+    celluloid (0.16.0)
+      timers (~> 4.0.0)
+    coderay (1.1.0)
+    colored (1.2)
+    cri (2.6.1)
+      colored (~> 1.2)
+    ffi (1.9.8)
+    formatador (0.2.5)
+    guard (2.12.5)
+      formatador (>= 0.2.4)
+      listen (~> 2.7)
+      lumberjack (~> 1.0)
+      nenv (~> 0.1)
+      notiffany (~> 0.0)
+      pry (>= 0.9.12)
+      shellany (~> 0.0)
+      thor (>= 0.18.1)
+    guard-nanoc (1.0.3)
+      guard (~> 2.8)
+      nanoc (~> 3.6)
+    hitimes (1.2.2)
+    kramdown (0.13.8)
+    listen (2.10.0)
+      celluloid (~> 0.16.0)
+      rb-fsevent (>= 0.9.3)
+      rb-inotify (>= 0.9)
+    lumberjack (1.0.9)
+    method_source (0.8.2)
+    mime-types (1.25.1)
+    nanoc (3.7.5)
+      cri (~> 2.3)
+    nenv (0.2.0)
     nokogiri (1.4.7)
+    notiffany (0.0.6)
+      nenv (~> 0.1)
+      shellany (~> 0.0)
+    pry (0.10.1)
+      coderay (~> 1.1.0)
+      method_source (~> 0.8.1)
+      slop (~> 3.4)
     pygmentize (0.0.3)
-    rack (1.4.0)
-    rake (0.9.2.2)
-    systemu (2.4.2)
+    rack (1.6.0)
+    rake (10.4.2)
+    rb-fsevent (0.9.4)
+    rb-inotify (0.9.5)
+      ffi (>= 0.5.0)
+    shellany (0.0.1)
+    slop (3.6.0)
+    systemu (2.6.5)
+    thor (0.19.1)
+    timers (4.0.1)
+      hitimes
     yajl-ruby (0.8.3)
 
 PLATFORMS
   ruby
 
 DEPENDENCIES
   adsf
+  guard-nanoc
   kramdown (~> 0.13.2)
   mime-types (~> 1.16)
   nanoc

diff --git a/Guardfile b/Guardfile
@@ -0,0 +1,30 @@
+# A sample Guardfile
+# More info at https://github.com/guard/guard#readme
+
+## Uncomment and set this to only include directories you want to watch
+# directories %w(app lib config test spec features)
+
+## Uncomment to clear the screen before every task
+# clearing :on
+
+## Guard internally checks for changes in the Guardfile and exits.
+## If you want Guard to automatically start up again, run guard in a
+## shell loop, e.g.:
+##
+##  $ while bundle exec guard; do echo "Restarting Guard..."; done
+##
+## Note: if you are using the `directories` clause above and you are not
+## watching the project directory ('.'), then you will want to move
+## the Guardfile to a watched dir and symlink it back, e.g.
+#
+#  $ mkdir config
+#  $ mv Guardfile config/
+#  $ ln -s config/Guardfile .
+#
+# and, you'll have to watch "config/Guardfile" instead of "Guardfile"
+
+guard 'nanoc' do
+  watch('nanoc.yaml') # Change this to config.yaml if you use the old config file name
+  watch('Rules')
+  watch(%r{^(content|layouts|lib)/.*$})
+end
diff --git a/content/index.md b/content/index.md
@@ -22,7 +22,7 @@ If you have any problems or requests, please contact [support](mailto:support@de
 
 ## Deal
 
-A _deal_ is a product that offers goods or services from different merchants at discounted levels. 
+A _deal_ is a product that offers goods or services from different merchants at discounted levels.
 
 ## Purchase
 
@@ -36,9 +36,9 @@ A _purchase_ is a transaction in which a person (the _purchaser_) buys a quantit
 
 You can provide deals to your customers using just two simple API calls: _get deals_ and _execute a purchase._ The following example is a brief description of how these calls work with an existing mobile application.
 
-In this example, a partner has integrated the entire deal viewing and purchasing process into a native mobile app experience. The following diagram shows the user purchase flow and the steps needed to implement each part of the flow: 
+In this example, a partner has integrated the entire deal viewing and purchasing process into a native mobile app experience. The following diagram shows the user purchase flow and the steps needed to implement each part of the flow:
 
-<img src="/images/mobile_use_example.png" alt="Mobile Example Image" > 
+<img src="/images/mobile_use_example.png" alt="Mobile Example Image" >
 
 * <b>Show Offers:</b> Request deals using the Get Deals call. The call returns a list of deals available to purchase based on the filter parameters your provide with the request. Users see a subset of the deals with just a few key aspects of each deal.
 
@@ -48,4 +48,4 @@ In this example, a partner has integrated the entire deal viewing and purchasing
 
 * <b>Redeem Offer</b> When an Execute Purchase request is successful, a purchase confirmation page appears with a link to the redemption voucher for the newly purchased deal.
 
-To learn how to use the Deem Offers API, see our [Quick Start Guide](/v1/quick_start/).
+To learn how to use the Deem Offers API, see our [Quick Start Guide](/v1/quick_start/).
diff --git a/content/v1/adunits.md b/content/v1/adunits.md
@@ -9,7 +9,7 @@ The ad units operate like widgets to show in-flight deals that users can click t
 Up to 10 in-flight deals are selected for each ad unit based on request parameters, and they are rotated periodically.
 Request parameters applicable to the [Deals API](/v1/deals) are also applicable to ad units.
 <br><br>
-Partners need to include only one line of JavaScript to place an ad unit on a web page.  
+Partners need to include only one line of JavaScript to place an ad unit on a web page.
 If no deals are identified for the ad units, then a stand-by ad unit is rendered with content "40 - 80% Off at ${partner web site}".
 
 In version 1, three types of ad units are supported:

diff --git a/content/v1/authentication.md b/content/v1/authentication.md
@@ -13,9 +13,9 @@ Your unique API key is provided in the Admin Dashboard. If at any time your key
 Add the api_key parameter to each GET, POST, and PUT request with the value of your unique API key:
 
 ## Request
-	
-	GET /v1/deals?api_key={api_key}
+
+	GET /api/v1/deals?api_key={api_key}
 
 ## Request Example
 
-	GET /v1/deals?api_key=1234567
+	GET /api/v1/deals?api_key=1234567
diff --git a/content/v1/deals.md b/content/v1/deals.md
@@ -15,7 +15,7 @@ This request returns a single deal resource for a specific deal.
 
 ## Request
 
-    GET /deals/{deal_id}?api_key={api_key}
+    GET /api/v1/deals/{deal_id}?api_key={api_key}
 
 ## Request Parameters
 
@@ -26,7 +26,7 @@ deal_id
 
 ## Request Example
 
-	GET /v1/deals/my-restaurant?api_key=1234567
+	GET /api/v1/deals/my-restaurant?api_key=1234567
 
 ## Response
 
@@ -63,7 +63,7 @@ This request returns an array of deal resources, ordered by start_at time (with
 
 ## Request
 
-    GET /deals/locate?api_key={api_key}
+    GET /api/v1/deals/locate?api_key={api_key}
 
 ## Request Parameters
 
@@ -80,7 +80,7 @@ radius
 
 ## Request Example
 
-<%= requests("GET /v1/deals/locate?api_key=1234567") %>
+<%= requests("GET /api/v1/deals/locate?api_key=1234567") %>
 <%= json(OfferEngine.deals_locate_request()) %>
 
 ## Response

diff --git a/content/v1/full_purchase.md b/content/v1/full_purchase.md
@@ -10,7 +10,7 @@ This single operation will create a new user if the user doesn't already exist,
 
 ## Request
 
-	POST /v1/purchases/full.json?api_key={api_key}
+	POST /api/v1/purchases/full.json?api_key={api_key}
 
 ## Request Parameters
 
@@ -275,4 +275,4 @@ error_type = "validations_failed"
 ### Validation errors for user, payment card, purchase, and shipping address
 
 <%= headers 422 %>
-<%= json(OfferEngine.full_purchase_error_all()) %>
+<%= json(OfferEngine.full_purchase_error_all()) %>
diff --git a/content/v1/get_deals.md b/content/v1/get_deals.md
@@ -12,9 +12,9 @@ Each deal has a number of attributes you can use to filter the Get Deals request
 
 If you make this call with no set parameters, Get Deals returns a list of <i>all</i> "in-flight" (currently active) deals across <i>all</i> geographical regions -- including deals that are sold out and deals that are <i>not</i> sold out. To avoid retrieving sold-out deals, we recommend that you set <i>exclude_soldout</i> to "true" when making this call.
 
-## Request 
+## Request
 
-	GET /v1/deals?api_key={api_key}
+	GET /api/v1/deals?api_key={api_key}
 
 ## Request Parameters
 
@@ -57,7 +57,7 @@ merchant
 price_min
 : _Optional Integer_ Filter the minimum deal price in cents (i.e., 100 equals one dollar).
 
-price_max 
+price_max
 : _Optional Integer_ Filter the maximum deal price in cents.
 
 ### Location parameters
@@ -81,14 +81,14 @@ user
 
 ### Source parameters
 
-suppliers 
+suppliers
 : _Optional Array_ Filter deals by supplier (a partner slug or set of comma-separated partner slugs).
 
 vendors
 : _Optional Array_ Filter deals by vendor (a vendor slug or set of comma-separated vendor slugs).
 
 ### Inventory parameters
- 
+
 num_left
 : _Optional Integer_ Filter deals by the quantity of inventory left.
 
@@ -110,7 +110,7 @@ card_links_redeemed
 
 ### New user account, new payment card, and a shipping address:
 
-<%= requests("GET /v1/deals?api_key=1234567") %>
+<%= requests("GET /api/v1/deals?api_key=1234567") %>
 <%= json(OfferEngine.deals_request()) %>
 
 ## Response
@@ -147,4 +147,4 @@ error_type = "find_failed"
 ## Error Response Example
 
 <%= headers 404 %>
-<%= json(OfferEngine.deals_error()) %>
+<%= json(OfferEngine.deals_error()) %>
diff --git a/content/v1/purchases.md b/content/v1/purchases.md
@@ -16,15 +16,15 @@ This request retrieves a specific purchase object. It returns a representation o
 
 ### Request
 
-    GET /purchases/<purchase_id>?api_key=<api_key>
+    GET /api/v1/purchases/<purchase_id>?api_key=<api_key>
 
 ### Parameters
 
 None
 
 ### Request Example
 
-<%= requests("GET /purchases/34063ec2.json?api_key=1234567") %>
+<%= requests("GET /api/v1/purchases/34063ec2.json?api_key=1234567") %>
 
 ### Response
 
@@ -56,7 +56,7 @@ deal_id
 : _String_  Unique identifier for deal purchased
 
 deal_type
-: _String_  Type of deal purchased (<possible results>)
+: _String_  Type of deal purchased (_possible results_)
 
 barcode
 : _String_  Unique barcode used for purchase redemption
@@ -71,7 +71,7 @@ created_at
 : _String_  Date and time purchase was made
 
 state
-: _String_  State of the purchase (<possible results>)
+: _String_  State of the purchase (_possible results_)
 
 qrcode_url
 : _String_  URL for the qrcode image associated with the coupon
@@ -90,7 +90,7 @@ redeemed_at
 
 This request creates a purchase for an existing user with a stored payment card. This operation will execute a purchase transaction for an existing user that already has a stored payment card.
 
-    POST /purchases
+    POST /api/v1/purchases
 
 ### Parameters
 deal_id
@@ -118,7 +118,7 @@ session_id (optional)
 ## Reserve a purchase
 Temporarily reserve inventory (for five minutes) for a purchase in order to process payment transactions. If the transaction succeeds, you would perform a checkout; otherwise, you would return the inventory.
 
-    POST /purchases/reserve
+    POST /api/v1/purchases/reserve
 
 ### Parameters
 
@@ -136,7 +136,7 @@ num_bought
 ## Claim a purchase
 After inventory has been reserved for a purchase and payment processing is successful, you would use this requent with your reservation token (the response from the reserve call) to create a purchase record from your reservation -- if the reservation is valid. If the reservation is invalid or expired, we will still attempt to create a purchase record; however, succes is not guaranteed because the deal might be sold out.
 
-    PUT /purchases/:purchase_id/claim
+    PUT /api/v1/purchases/:purchase_id/claim
 
 ### Parameters
 
@@ -151,7 +151,7 @@ user_id
 ## Release a reserved purchase
 If you have reserved inventory for a purchase but the payment processing failed, use this request to release the inventory of the purchase.
 
-    PUT /purchases/:purchase_id/release
+    PUT /api/v1/purchases/:purchase_id/release
 
 ### Response
 

diff --git a/content/v1/quick_start.md b/content/v1/quick_start.md
@@ -16,15 +16,15 @@ In order to use the Deem Offers API, you must be an approved Deem Offers partner
 
 To use the Deem Offers API, you must first get your partner API key from your Deem Offers Admin website. Keep this private key secret. You will provide this key with every API call you make. Here is an example of how your requests will look:
 
-	GET /v1/deals?api_key={api_key}
+	GET /api/v1/deals?api_key={api_key}
 
 To learn more about authentication, see [Authentication](/v1/authentication/).
 
 ## Step 2: Get Deals
 
-The next step after getting your API key is to request available deals to display on your internet surface (your website, your emails, or your mobile app). To get a set of available San Francisco deals with inventory that is not currently sold out, make the following request: 
+The next step after getting your API key is to request available deals to display on your internet surface (your website, your emails, or your mobile app). To get a set of available San Francisco deals with inventory that is not currently sold out, make the following request:
 
-<%= requests("GET /v1/deals?api_key=1234567") %>
+<%= requests("GET /api/v1/deals?api_key=1234567") %>
 <%= json(OfferEngine.deals_request()) %>
 
 This request returns a set of deal resources containing all of the information you need to display deals on your internet surface, including the deal title, availability dates, inventory quantity, purchase limits, images, and additional attributes. The response looks like this:
@@ -36,15 +36,15 @@ For more information about the Get Deals call, see [Get Deals](/v1/get_deals/).
 
 ## Step 3: Execute Purchases
 
-After displaying deals on your internet surfaces, you are ready to execute a purchase for a purchaser. This purchase can be made with one simple call that includes the following: 
+After displaying deals on your internet surfaces, you are ready to execute a purchase for a purchaser. This purchase can be made with one simple call that includes the following:
 * user information
 * payment information
 * deal information
 * shipping information (if needed)
 
 The purchase request looks like this:
 
-<%= requests("POST /v1/purchases/full.json") %>
+<%= requests("POST /api/v1/purchases/full.json") %>
 <%= json(OfferEngine.full_purchase_request_new()) %>
 
 When the purchase executes successfully, you receive a response similar to this:
@@ -57,4 +57,4 @@ For more information about purchasing deals, see [Execute Purchases](/v1/full_pu
 
 ## Additional Requests
 
-Additional requests -- such as getting deals from specific locations or regions, managing user sessions, getting user information, creating targted emails, and getting statistical information -- are included with the Deem Offers API. The additional calls are not necessary to provide Deem Offers deals to your customers, but you may find them useful. To learn more about additional requests, see [Additional Calls](/v1/advanced/).
+Additional requests -- such as getting deals from specific locations or regions, managing user sessions, getting user information, creating targted emails, and getting statistical information -- are included with the Deem Offers API. The additional calls are not necessary to provide Deem Offers deals to your customers, but you may find them useful. To learn more about additional requests, see [Additional Calls](/v1/advanced/).
Original file line number	Diff line number	Diff line change
		@@ -1 +1 @@
		rvm 1.9.3@developer.offerengine.com --create
		rvm 1.9.3-p327@developer.offerengine.com --create