Merge pull request #74 from ripple/gh-pages

Dev Portal from Staging to Master for 10/3 push
Merge pull request #73 from mDuo13/gh-pages
2025-11-19 11:15:49 +00:00 · 2014-10-03 13:55:45 -07:00 · 2014-10-03 13:22:29 -07:00 · 2014-10-02 16:08:45 -07:00 · 2014-10-01 00:13:41 -07:00 · 2014-09-30 16:37:02 -07:00
20 changed files with 2106 additions and 570 deletions
--- a/assets/img/rippleThrobber.png
+++ b/assets/img/rippleThrobber.png
--- a/consensus-whitepaper.html
+++ b/consensus-whitepaper.html
@@ -99,7 +99,13 @@ mixpanel.init("132d42885e094171f34467fc54da6fab");
            <li><a href="https://ripplelabs.atlassian.net/">Bug Tracking</a></li>
            <li><a href="https://ripple.com/dev/blog/">Dev Blog</a></li>
            <li><a href="https://ripple.com/forum/viewforum.php?f=2&sid=c016bc6b934120b7117c0e136e74de98">Forums</a></li>
-            <li><a target="_self" href="ripple-api-tool.html">API Tool</a></li>
+            <li class="dropdown">
+              <a href="#" class="dropdown-toggle" data-toggle="dropdown">API Tool <span class="caret"></span></a>
+              <ul class="dropdown-menu" role="menu">
+                <li><a href="ripple-api-tool.html">WebSocket Tool</a></li>
+                <li><a href="rest-api-tool.html">REST Tool</a></li>
+              </ul>
+            </li>
          </ul>
          	<div class='right'>
 		 	 <!-- GitHub buttons -->
@@ -157,6 +163,8 @@ mixpanel.init("132d42885e094171f34467fc54da6fab");
 					
 						<ul class="footer_links core_network">
 							<li><a href="rippled-apis.html">rippled</a>
+							<li><a href="transactions.html">Transactions</a>
+							<li><a href="consensus-whitepaper.html">Consensus</a>
 						</ul>
 				
 				</div>
--- a/css/api-style.css
+++ b/css/api-style.css
@@ -87,7 +87,7 @@ h2 {
  margin:0;
  padding:0;
 }
-#response {
+#response, #response_body {
  min-height:100px;
  border-top-left-radius:0px !important;
  border-top-right-radius:0px !important;
@@ -98,7 +98,7 @@ h2 {
 #output {
  width: 60%;
 }
-p, h3 {
+h3 {
  margin:16px 0;
  font-family:'open sans';
  font-weight:300;
@@ -150,7 +150,7 @@ p, h3 {
 }

 #request_options > div {
-  float:right;
+/*  float:right;
  margin:0;
  width:200px;
  color:#fff;
@@ -161,23 +161,25 @@ p, h3 {
  background-image:linear-gradient(283deg, rgba(255,255,255,0.1) 50%, transparent 55%), linear-gradient(top, rgba(255,255,255,0.15), transparent);
  background-image:-webkit-linear-gradient(283deg, rgba(255,255,255,0.1) 50%, transparent 55%), -webkit-linear-gradient(top, rgba(255,255,255,0.15), transparent);
  background-image:-moz-linear-gradient(283deg, rgba(255,255,255,0.1) 50%, transparent 55%), -moz-linear-gradient(top, rgba(255,255,255,0.15), transparent);
- */
+ 

  border-radius:4px;
  border-bottom:1px solid #fff;
  background-color: #346AA9;
  font-weight:300;
  font-size:16px;
-/*   line-height:50px; */
+/*   line-height:50px; 
  text-align:center;
  cursor:default;

  user-select:none;
  -webkit-user-select:none;
  -moz-user-select:none;
+*/
+  margin-top: 5px;
 }
 #request_button {
-  background:#3a87ad;
+  background-color: #346AA9;
 }
 #request_button.depressed {
  background:#295F7A;
@@ -264,8 +266,9 @@ ul.toolbar li {


 /* JSON syntax highlighting */
-#request,
-#response {
+#request, #request_body,
+#response, #response_body,
+#rest_url_wrapper {
  font-family:'inconsolata',monospace;
  font-size:13px;
  line-height:20px;
@@ -289,9 +292,9 @@ ul.toolbar li {
  border:1px dotted #3a87ad;
 }

-#selected_command {
+/*#selected_command {
  margin-top:-32px;
-}
+}*/

 #selected_command a {
  text-decoration:none;
@@ -343,3 +346,112 @@ span.cm-number {
 span.cm-atom {
  color:#66327C !important;
 }
+
+/* Progress spinner animation */
+@keyframes rotating {
+    from {
+        transform: rotate(0deg);
+        -ms-transform: rotate(0deg);
+        -moz-transform: rotate(0deg);
+        -webkit-transform: rotate(0deg);
+        -o-transform: rotate(0deg);
+    }
+    to {
+        transform: rotate(360deg);
+        -ms-transform: rotate(360deg);
+        -moz-transform: rotate(360deg);
+        -webkit-transform: rotate(360deg);
+        -o-transform: rotate(360deg);
+    }
+}
+
+@-webkit-keyframes rotating /* Safari and Chrome */ {
+    from {
+        transform: rotate(0deg);
+        -ms-transform: rotate(0deg);
+        -moz-transform: rotate(0deg);
+        -webkit-transform: rotate(0deg);
+        -o-transform: rotate(0deg);
+    }
+    to {
+        transform: rotate(360deg);
+        -ms-transform: rotate(360deg);
+        -moz-transform: rotate(360deg);
+        -webkit-transform: rotate(360deg);
+        -o-transform: rotate(360deg);
+    }
+}
+
+.loader {
+    -webkit-animation: rotating 1s linear infinite;
+    -moz-animation: rotating 1s linear infinite;
+    -ms-animation: rotating 1s linear infinite;
+    -o-animation: rotating 1s linear infinite;
+    animation: rotating 1s linear infinite;
+    width: 25px;height:25px;
+}
+
+
+/* Rest-tool-specific stuff */
+
+#rest_method {
+    display: inline-block;
+    padding: 6px;
+    vertical-align: middle;
+    border: 1px dotted #aaa;
+    border-radius: 4px;
+    -moz-border-radius: 4px;
+    -webkit-border-radius: 4px;
+    margin-bottom: 3px;
+    background-color: #c7254e;
+    color: white;
+    appearance: none;
+    -moz-appearance: none;
+}
+
+#rest_url_wrapper {
+    font-family: sans-serif;
+    display: inline-block;
+    text-indent: -2em;
+    padding-left: 2.5em;
+}
+
+#rest_url {
+    width: auto;
+    border: 0;
+    background: none;
+    font-size:13px;
+    vertical-align: top;
+}
+
+#rest_url .editable {
+    font-weight: bold;
+    font-family:'inconsolata',monospace;
+    border-width: 0 0px 1px 0;
+    border-style: dotted;
+    border-color: #aaa;
+    min-width: 5em;
+    background: none;
+    vertical-align: top;
+}
+
+#rest_url .non_editable {
+    vertical-align: top;
+}
+
+#rest_url_wrapper p {
+    margin: 0;
+}
+
+#rest_url div {
+    display: inline-block;
+}
+
+#rest_url input {
+    margin: 0 !important;
+}
+
+#rest_url div label, 
+#rest_url div input {
+    display: block;
+}
--- a/css/custom-landing.css
+++ b/css/custom-landing.css
@@ -15,6 +15,10 @@ a:hover {
 	text-decoration: none;
 }

+.resources a {
+    white-space: nowrap;
+}
+

 /************
  jumbotron
--- a/css/custom.css
+++ b/css/custom.css
@@ -158,6 +158,18 @@ color: #f09 !important;
 	
 }

+
+/************
+  api tool(s)
+*********** */
+
+body #online_state {
+    position: absolute;
+    right: 50px;
+    top: 70px;
+}
+
+
 /************
  	nav
 *********** */
--- a/gatewayd.html
+++ b/gatewayd.html
@@ -90,7 +90,13 @@ mixpanel.init("132d42885e094171f34467fc54da6fab");
            <li><a href="https://ripplelabs.atlassian.net/">Bug Tracking</a></li>
            <li><a href="https://ripple.com/dev/blog/">Dev Blog</a></li>
            <li><a href="https://ripple.com/forum/viewforum.php?f=2&sid=c016bc6b934120b7117c0e136e74de98">Forums</a></li>
-            <li><a target="_self" href="ripple-api-tool.html">API Tool</a></li>
+            <li class="dropdown">
+              <a href="#" class="dropdown-toggle" data-toggle="dropdown">API Tool <span class="caret"></span></a>
+              <ul class="dropdown-menu" role="menu">
+                <li><a href="ripple-api-tool.html">WebSocket Tool</a></li>
+                <li><a href="rest-api-tool.html">REST Tool</a></li>
+              </ul>
+            </li>
          </ul>
          	<div class='right'>
 		 	 <!-- GitHub buttons -->
@@ -133,6 +139,8 @@ mixpanel.init("132d42885e094171f34467fc54da6fab");
 					
 						<ul class="footer_links core_network">
 							<li><a href="rippled-apis.html">rippled</a>
+							<li><a href="transactions.html">Transactions</a>
+							<li><a href="consensus-whitepaper.html">Consensus</a>
 						</ul>
 				
 				</div>
--- a/guidelines.html
+++ b/guidelines.html
@@ -77,7 +77,13 @@ mixpanel.init("132d42885e094171f34467fc54da6fab");
            <li><a href="https://ripplelabs.atlassian.net/">Bug Tracking</a></li>
            <li><a href="https://ripple.com/dev/blog/">Dev Blog</a></li>
            <li><a href="https://ripple.com/forum/viewforum.php?f=2&sid=c016bc6b934120b7117c0e136e74de98">Forums</a></li>
-            <li><a target="_self" href="ripple-api-tool.html">API Tool</a></li>
+            <li class="dropdown">
+              <a href="#" class="dropdown-toggle" data-toggle="dropdown">API Tool <span class="caret"></span></a>
+              <ul class="dropdown-menu" role="menu">
+                <li><a href="ripple-api-tool.html">WebSocket Tool</a></li>
+                <li><a href="rest-api-tool.html">REST Tool</a></li>
+              </ul>
+            </li>
          </ul>
          	<div class='right'>
 		 	 <!-- GitHub buttons -->
@@ -423,6 +429,8 @@ mixpanel.init("132d42885e094171f34467fc54da6fab");
 					
 						<ul class="footer_links core_network">
 							<li><a href="rippled-apis.html">rippled</a>
+							<li><a href="transactions.html">Transactions</a>
+							<li><a href="consensus-whitepaper.html">Consensus</a>
 						</ul>
 				
 				</div>
--- a/index.html
+++ b/index.html
@@ -74,7 +74,13 @@ mixpanel.init("132d42885e094171f34467fc54da6fab");
            <li><a href="https://ripplelabs.atlassian.net/">Bug Tracking</a></li>
            <li><a href="https://ripple.com/dev/blog/">Dev Blog</a></li>
            <li><a href="https://ripple.com/forum/viewforum.php?f=2&sid=c016bc6b934120b7117c0e136e74de98">Forums</a></li>
-            <li><a target="_self" href="ripple-api-tool.html">API Tool</a></li>
+            <li class="dropdown">
+              <a href="#" class="dropdown-toggle" data-toggle="dropdown">API Tool <span class="caret"></span></a>
+              <ul class="dropdown-menu" role="menu">
+                <li><a href="ripple-api-tool.html">WebSocket Tool</a></li>
+                <li><a href="rest-api-tool.html">REST Tool</a></li>
+              </ul>
+            </li>
          </ul>
          	<div class='right'>
 		 	 <!-- GitHub buttons -->
@@ -193,6 +199,7 @@ mixpanel.init("132d42885e094171f34467fc54da6fab");
 							<li><a href="https://github.com/ripple/rippled"><i class="fa fa-code"></i> Source </a></li>
 							<li><a href="https://www.bountysource.com/trackers/304896-rippled"><i class="fa fa-dot-circle-o"></i> Bounties </a></li>
 							<li><a href="consensus-whitepaper.html"><i class="fa fa-file"></i> Consensus Whitepaper </a></li>
+							<li><a href="transactions.html"><i class="fa fa-cubes"></i> Transaction Format </a></li>
 						</ul>
 			</div>
 			
@@ -225,6 +232,8 @@ mixpanel.init("132d42885e094171f34467fc54da6fab");
 					
 						<ul class="footer_links core_network">
 							<li><a href="rippled-apis.html">rippled</a>
+							<li><a href="transactions.html">Transactions</a>
+							<li><a href="consensus-whitepaper.html">Consensus</a>
 						</ul>
 				
 				</div>
--- a/js/api-main.js
+++ b/js/api-main.js
@@ -15,6 +15,7 @@
  var request         = $(command_wrapper).find('#request');
  var status          = $(command_wrapper).find('#status');
  var info            = $(command_wrapper).find('#info');
+  var spinner = $(".loader");

  var remote = new ripple.Remote({
    trusted:        true,
@@ -339,6 +340,7 @@
    if (is_response && parsed.id === id._c) {
      if (!WAITING) return;
      else WAITING = false;
+      spinner.hide();

      var request_header = '<span class="request_name">'
      + selected_request.name;
@@ -591,6 +593,7 @@
    WAITING                  = true;
    selected_request.message = message;
    selected_request.t       = Date.now();
+    spinner.show();

    request.message = prepare_request(message);
    request.request();
--- a/js/apitool-rest.js
+++ b/js/apitool-rest.js
@@ -0,0 +1,461 @@
+var commands = $("#command_list li");
+var request_body = $("#request_body");
+var request_button = $("#request_button");
+var response_body = $("#response_body");
+var response_code = $("#rest_responsecode");
+var rest_url = $('#rest_url');
+var rest_method = $("#rest_method");
+var selected_command = $("#selected_command");
+var spinner = $(".loader");
+var reminders = $("#rest_url_wrapper .rest_reminders");
+var test_warning = $("#test_warning");
+
+var GET = "GET";
+var POST = "POST";
+var PUT = "PUT";
+var DELETE = "DELETE";
+var URL_BASE = "https://api.ripple.com:443";
+
+var DOC_BASE = "ripple-rest.html";
+
+
+function slugify(str) {
+  str = str.replace(/^\s+|\s+$/g, ''); // trim
+  str = str.toLowerCase();
+  
+  // remove accents, swap ñ for n, etc
+  var from = "àáäâèéëêìíïîòóöôùúüûñç·/_,:;";
+  var to   = "aaaaeeeeiiiioooouuuunc------";
+  for (var i=0, l=from.length ; i<l ; i++) {
+    str = str.replace(new RegExp(from.charAt(i), 'g'), to.charAt(i));
+  }
+
+  str = str.replace(/[^a-z0-9 -]/g, '') // remove invalid chars
+    .replace(/\s+/g, '-') // collapse whitespace and replace by -
+    .replace(/-+/g, '-'); // collapse dashes
+
+  return str;
+}
+
+//Build requests
+var requests = { };
+function Request(name, obj) {
+    obj.name = name;
+    requests[slugify(name)] = obj;
+
+    return obj;
+};
+
+$(commands).click(function() {
+    var cmd = slugify($(this).text().trim());
+
+    if (!requests[cmd]) return;
+
+    select_request(cmd, true);
+    window.location.hash = cmd;
+
+    $(this).siblings().removeClass('selected');
+    $(this).addClass('selected');
+});
+
+
+//---------- List of requests ------------------------//
+
+var DEFAULT_ADDRESS_1 = "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn";
+var DEFAULT_ADDRESS_2 = "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX";
+var DEFAULT_HASH = "9D591B18EDDD34F0B6CF4223A2940AEA2C3CC778925BABF289E0011CD8FA056E";
+
+Request('Generate Account', {
+    method: GET,
+    path: "/v1/accounts/new",
+    description: 'Generate the keys for a potential new account',
+    link: '#generating-accounts'
+});
+
+Request('Get Account Balances', {
+    method: GET,
+    path: '/v1/accounts/{:address}/balances',
+    description: 'Retrieve the current balances for the given Ripple account',
+    link: '#account-balances',
+    params: {
+        "{:address}": DEFAULT_ADDRESS_1
+    }
+});
+
+Request('Get Account Settings', {
+    method: GET,
+    path: '/v1/accounts/{:address}/settings',
+    description: 'Retrieve the current settings for the given Ripple account',
+    link: '#account-settings',
+    params: {
+        "{:address}": DEFAULT_ADDRESS_1
+    }
+});
+
+Request('Update Account Settings', {
+    method: POST,
+    path: '/v1/accounts/{:address}/settings',
+    description: 'Change the current settings for the given Ripple account.',
+    link: '#updating-account-settings',
+    test_only: true,
+    params: {
+        "{:address}": DEFAULT_ADDRESS_1
+    },
+    body: {
+        secret: "sssssssssssssssssssssssssssss",
+        settings: {
+            require_destination_tag: false,
+            require_authorization: false,
+            disallow_xrp: false,
+            disable_master: false,
+            email_hash: "98b4375e1d753e5b91627516f6d70977"
+        } 
+    }
+});
+
+Request('Prepare Payment', {
+    method: GET,
+    path: '/v1/accounts/{:source_address}/payments/paths/{:destination_address}/{:amount}?{:query_params}',
+    description: 'Change the current settings for the given Ripple account',
+    link: '#prepare-payment',
+    params: {
+        "{:source_address}": DEFAULT_ADDRESS_1,
+        "{:destination_address}": DEFAULT_ADDRESS_2,
+        "{:amount}": "1+USD+rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
+        "{:query_params}": "source_currencies=USD"
+    }
+});
+
+Request('Submit Payment', {
+    method: POST,
+    path: '/v1/payments',
+    description: 'Send a prepared payment to the network.',
+    link: '#submitting-a-payment',
+    test_only: true,
+    body: {
+      "secret": "sssssssssssssssssssssssssssss",
+      "client_resource_id": "348170b9-16b9-4927-854d-7f9d4a2a692d",
+      "payment":     {
+          "source_account": DEFAULT_ADDRESS_1,
+          "source_tag": "",
+          "source_amount": {
+            "value": "1",
+            "currency": "USD",
+            "issuer": ""
+          },
+          "source_slippage": "0",
+          "destination_account": DEFAULT_ADDRESS_2,
+          "destination_tag": "",
+          "destination_amount": {
+            "value": "1",
+            "currency": "USD",
+            "issuer": DEFAULT_ADDRESS_1
+          },
+          "invoice_id": "",
+          "paths": "[]",
+          "partial_payment": false,
+          "no_direct_ripple": false
+        }
+    }
+});
+
+Request("Confirm Payment", {
+    method: GET,
+    path: "/v1/accounts/{:address}/payments/{:hash}",
+    description: "Retrieve details of a payment and its status",
+    link: "#confirming-a-payment",
+    params: {
+        "{:address}": DEFAULT_ADDRESS_1,
+        "{:hash}": DEFAULT_HASH
+    }
+});
+
+Request("Get Payment History", {
+    method: GET,
+    path: "/v1/accounts/{:address}/payments?{:query_params}",
+    description: "Browse through the history of payments sent and received by an account",
+    link: "#payment-history",
+    params: {
+        "{:address}": DEFAULT_ADDRESS_1,
+        "{:query_params}": "direction=incoming&exclude_failed=true"
+    }
+});
+
+Request("Get Trustlines", {
+    method: GET,
+    path: "/v1/accounts/{:address}/trustlines?{:query_params}",
+    description: "Check the status of one or more trustlines attached to an account",
+    link: "#reviewing-trustlines",
+    params: {
+        "{:address}": DEFAULT_ADDRESS_1,
+        "{:query_params}": "currency=USD&counterparty=ra5nK24KXen9AHvsdFTKHSANinZseWnPcX"
+    }
+});
+
+Request("Grant Trustline", {
+    method: POST,
+    path: "/v1/accounts/{:address}/trustlines",
+    description: "Add or modify a trustline from this account.",
+    link: "#granting-a-trustline",
+    test_only: true,
+    params: {
+        "{:address}": DEFAULT_ADDRESS_1
+    },
+    body: {
+        "secret": "sneThnzgBgxc3zXPG....",
+        "trustline": {
+            "limit": "110",
+            "currency": "USD",
+            "counterparty": "rMwjYedjc7qqtKYVLiAccJSmCwih4LnE2q",
+            "allows_rippling": false
+        }
+    }
+});
+
+Request("Check Notifications", {
+    method: GET,
+    path: "/v1/accounts/{:address}/notifications/{:hash}",
+    description: "Browse through the history of payments sent and received by an account",
+    link: "#checking-notifications",
+    params: {
+        "{:address}": DEFAULT_ADDRESS_1,
+        "{:hash}": DEFAULT_HASH
+    }
+});
+
+Request("Check Connection", {
+    method: GET,
+    path: "/v1/server/connected",
+    description: "Check whether the REST server is connected to a rippled server",
+    link: "#check-connection-state"
+});
+
+Request("Get Server Status", {
+    method: GET,
+    path: "/v1/server",
+    description: "Retrieve information about the current status of the Ripple-REST server and the rippled server it is connected to",
+    link: "#get-server-status"
+});
+
+Request("Retrieve Ripple Transaction", {
+    method: GET,
+    path: "/v1/tx/{:hash}",
+    description: "Retrieve a raw Ripple transaction",
+    link: "#retrieve-ripple-transaction",
+    params: {
+        "{:hash}": DEFAULT_HASH
+    }
+});
+
+Request("Generate UUID", {
+    method: GET,
+    path: "/v1/uuid",
+    description: "Create a universally-unique identifier (UUID) to use as the client resource ID for a payment",
+    link: "#create-client-resource-id"
+});
+
+//---------- End req. List ---------------------------//
+
+var cm_request = CodeMirror(request_body.get(0), {
+    mode: 'javascript',
+    json: true,
+    smartIndent: false
+});
+
+var cm_response = CodeMirror(response_body.get(0), {
+    mode: 'javascript',
+    json: true,
+    smartIndent: false,
+    readOnly: true
+});
+
+function update_method(el) {
+    if (el === undefined) {
+        method = $(this).val();
+    } else {
+        method = $(el).val();
+    }
+    
+    if (method == GET || method == DELETE) {
+        request_body.hide();
+    } else {
+        request_body.show();
+        cm_request.refresh();
+    }
+}
+
+function change_path(command) {
+    rest_url.empty();
+    reminders.html("&nbsp;");
+    
+    var re = /(\{:[^}]+\})/g; // match stuff like {:address}
+    params = command.path.split(re);
+    
+    //console.log(params);
+    for (i=0; i<params.length; i++) {
+        if (params[i].match(/\{:[^}]+\}/) !== null) {
+            if (command.params === undefined || command.params[params[i]] === undefined) {
+                var default_val = params[i];
+            } else {
+                var default_val = command.params[params[i]];
+            }
+            //rest_url.append("<span class='editable' contenteditable='true' id='resturl_"+params[i]+"'>"+default_val+"</span>");
+            
+            var new_div = $("<div>").appendTo(rest_url);
+            var new_param = $("<input type='text' id='resturl_"+params[i]+"' value='"+default_val+"' class='editable' title='"+params[i]+"' />").appendTo(new_div);
+            new_param.autosizeInput({"space": 0});
+            //var new_label = $("<label class='reminder' for='resturl_"+params[i]+"'>"+params[i]+"</label>").appendTo(new_div);
+            
+            
+        } else {
+            rest_url.append("<span class='non_editable'>"+params[i]+"</span>");
+        }
+    }
+}
+
+function select_request(request) {
+    command = requests[request];
+    
+    if (command.test_only === true) {
+        test_warning.show();
+    } else {
+        test_warning.hide();
+    }
+
+    if (command.description) {
+        $(description).html($('<a>')
+            .attr('href', DOC_BASE+command.link)
+            .html(command.description));
+        $(description).show();
+    } else {
+        $(description).hide();
+    }
+
+    selected_command.html($('<a>')
+                    .attr('href', DOC_BASE+command.link)
+                    .text(command.name));
+                                
+    //rest_url.val(command.path);
+    //rest_url.text(command.path);
+    change_path(command);
+
+    
+//    rest_method.val(command.method);
+//    rest_method.change();
+    request_button.val(command.method);
+    request_button.text(command.method+" request");
+    update_method(request_button);
+    
+    if (command.method == POST || command.method == PUT) {
+        cm_request.setValue(JSON.stringify(command.body, null, 2));
+    } else {
+        //No body, so wipe out the current contents.
+        //This prevents confusion if the user toggles the HTTP method dropdown
+        cm_request.setValue("");
+    }
+    
+    reset_response_area();
+};
+
+//helper to fill the default payment with a new UUID
+function get_uuid(callback) {
+    $.get(URL_BASE + "/v1/uuid").done(callback);
+}
+
+function get_path() {
+    s = "";
+    rest_url.find(".non_editable, .editable").each(function() {
+        if (this.tagName == "INPUT") {
+            s += $(this).val();
+        } else {
+            s += $(this).text();
+        }
+    });
+    return s;
+}
+
+function send_request() {
+    //var method = rest_method.val();
+    var method = request_button.val();
+    if (method != GET && method != POST && method != PUT && method != DELETE) {
+        console.log("ERROR: unrecognized http method");
+        return;
+    }
+    //var path = rest_url.val();
+    var path = get_path();
+
+    $(this).addClass('depressed');
+    response_body.addClass('obscured');
+
+    if (method == PUT || method == POST) {
+        var body   = cm_request.getValue();
+        $.ajax({
+            type: method,
+            url: URL_BASE + path,
+            data: body,
+            contentType: 'application/json',
+            processData: false
+        }).done(success_output).fail(error_output).always(reset_sending_status);
+    } else {
+        $.ajax({
+            type: method,
+            url: URL_BASE + path
+        }).done(success_output).fail(error_output).always(reset_sending_status);
+    }
+    
+    spinner.show();
+}
+
+function error_output(xhr,status,statusText) {
+    response_code.text(xhr.status+" "+xhr.statusText);
+    cm_response.setValue(xhr.responseText);
+}
+
+function success_output(body,status,xhr) {
+    response_code.text(xhr.status+" "+xhr.statusText);
+    cm_response.setValue(JSON.stringify(body, null, 2));
+}
+
+function reset_sending_status() {
+    response_body.removeClass('obscured');
+    request_button.removeClass('depressed');
+    spinner.hide();
+}
+
+function reset_response_area() {
+    cm_response.setValue("");
+    response_code.text("");
+}
+
+$(document).ready(function() {
+    request_button.click(send_request);
+    //rest_method.change(update_method);
+    
+    get_uuid(function(resp,status,xhr) {
+        requests["submit-payment"].body.client_resource_id = resp.uuid;
+        if (window.location.hash == "#submit-payment") {
+            //we might have already loaded the call by the time the AJAX
+            // completes, so refresh the default body.
+            // Debatably a bad idea, because if the AJAX takes so long that the
+            // user has already started editing the call, it'll reset it.
+            select_request("submit-payment");
+        }
+    });
+
+    if (window.location.hash) {
+      var cmd   = window.location.hash.slice(1).toLowerCase();
+      var keys  = Object.keys(requests);
+      var index = keys.indexOf(cmd);
+
+      if (index === -1) return;
+
+      var el = commands.eq(index);
+
+      select_request(cmd);
+
+      $(el).siblings().removeClass('selected');
+      $(el).addClass('selected');
+    } else {
+      select_request('generate-account');
+    }
+});
--- a/js/jquery.autosize.input.min.js
+++ b/js/jquery.autosize.input.min.js
@@ -0,0 +1 @@
+var Plugins;(function(n){var t=function(){function n(n){typeof n=="undefined"&&(n=30);this.space=n}return n}(),i;n.AutosizeInputOptions=t;i=function(){function n(t,i){var r=this;this._input=$(t);this._options=$.extend({},n.getDefaultOptions(),i);this._mirror=$('<span style="position:absolute; top:-999px; left:0; white-space:pre;"/>');$.each(["fontFamily","fontSize","fontWeight","fontStyle","letterSpacing","textTransform","wordSpacing","textIndent"],function(n,t){r._mirror[0].style[t]=r._input.css(t)});$("body").append(this._mirror);this._input.on("keydown keyup input propertychange change",function(){r.update()});(function(){r.update()})()}return n.prototype.getOptions=function(){return this._options},n.prototype.update=function(){var n=this._input.val()||"",t;n!==this._mirror.text()&&(this._mirror.text(n),t=this._mirror.width()+this._options.space,this._input.width(t))},n.getDefaultOptions=function(){return this._defaultOptions},n.getInstanceKey=function(){return"autosizeInputInstance"},n._defaultOptions=new t,n}();n.AutosizeInput=i,function(t){var i="autosize-input",r=["text","password","search","url","tel","email","number"];t.fn.autosizeInput=function(u){return this.each(function(){if(this.tagName=="INPUT"&&t.inArray(this.type,r)>-1){var f=t(this);f.data(n.AutosizeInput.getInstanceKey())||(u==undefined&&(u=f.data(i)),f.data(n.AutosizeInput.getInstanceKey(),new n.AutosizeInput(this,u)))}})};t(function(){t("input[data-"+i+"]").autosizeInput()})}(jQuery)})(Plugins||(Plugins={}))
--- a/rest-api-tool.html
+++ b/rest-api-tool.html
@@ -0,0 +1,244 @@
+<!doctype html>
+<html>
+<head>
+  <meta charset='utf-8'>
+  <meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">
+  <meta name="viewport" content="width=device-width">
+
+  <title>Ripple Developer Portal: Ripple-REST API Tool</title>
+
+  <!-- favicon -->
+  <link rel="icon" href="favicon.ico" type="image/x-icon"> 
+  <link rel="shortcut icon" href="favicon.ico" type="image/x-icon"> 
+
+  <!-- Flatdoc -->
+  <script src="https://ajax.googleapis.com/ajax/libs/jquery/1.11.1/jquery.min.js"></script>
+  <script src='https://dev.ripple.com/vendor/flatdoc/v/0.8.0/legacy.js'></script>
+  <script src='https://dev.ripple.com/vendor/flatdoc/v/0.8.0/flatdoc.js'></script>
+  
+   <!-- Bootstrap -->
+ 
+   <link href="css/bootstrap.min.css" rel="stylesheet">
+   <script src="js/bootstrap.min.js"></script>
+
+
+  <!-- Custom Stylesheet -->
+  <link href='https://fonts.googleapis.com/css?family=Montserrat' rel='stylesheet' type='text/css'>
+  <link href='https://fonts.googleapis.com/css?family=Open+Sans:600italic,400,700,300' rel='stylesheet' type='text/css'>
+  <link  href='css/main.css' rel='stylesheet'>
+  <link  href='css/custom.css' rel='stylesheet'>
+  
+	<link rel="shortcut icon" href="favicon.ico?v=2" type="image/x-icon">
+	<link rel="icon" href="favicon.ico?v=2" type="image/x-icon">
+  
+  
+  
+  <!-- start Mixpanel -->
+  <script type="text/javascript">(function(e,b){if(!b.__SV){var a,f,i,g;window.mixpanel=b;a=e.createElement("script");a.type="text/javascript";a.async=!0;a.src=("https:"===e.location.protocol?"https:":"http:")+'//cdn.mxpnl.com/libs/mixpanel-2.2.min.js';f=e.getElementsByTagName("script")[0];f.parentNode.insertBefore(a,f);b._i=[];b.init=function(a,e,d){function f(b,h){var a=h.split(".");2==a.length&&(b=b[a[0]],h=a[1]);b[h]=function(){b.push([h].concat(Array.prototype.slice.call(arguments,0)))}}var c=b;"undefined"!==
+typeof d?c=b[d]=[]:d="mixpanel";c.people=c.people||[];c.toString=function(b){var a="mixpanel";"mixpanel"!==d&&(a+="."+d);b||(a+=" (stub)");return a};c.people.toString=function(){return c.toString(1)+".people (stub)"};i="disable track track_pageview track_links track_forms register register_once alias unregister identify name_tag set_config people.set people.set_once people.increment people.append people.track_charge people.clear_charges people.delete_user".split(" ");for(g=0;g<i.length;g++)f(c,i[g]);
+b._i.push([a,e,d])};b.__SV=1.2}})(document,window.mixpanel||[]);
+mixpanel.init("132d42885e094171f34467fc54da6fab");
+  </script>
+    
+  <script>if (window.location.host == "dev.ripple.com") { mixpanel.track("rest-api-tool"); }</script>    
+  <!-- end Mixpanel -->
+
+  <!-- start google analytics -->
+  <script>
+  (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
+  (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
+  m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
+  })(window,document,'script','//www.google-analytics.com/analytics.js','ga');
+
+  ga('create', 'UA-49188512-1', 'ripple.com');
+  ga('send', 'pageview');
+
+  </script>
+  <!-- end google analytics -->  
+    
+
+  
+
+  <!-- Temporary shims until I modify the css directly -->
+  <link type='text/css' rel='stylesheet' href='css/mod.css' />
+  <script src='js/expandcode.js'></script>
+  
+</head>
+<body role='flatdoc' class='no-literate'>
+<!--Draft warning would go here-->
+ 	<div class="navbar navbar-inverse navbar-fixed-top" role="navigation">
+      <div class="container">
+        <div class="navbar-header">
+          <button type="button" class="navbar-toggle" data-toggle="collapse" data-target=".navbar-collapse">
+            <span class="sr-only">Toggle navigation</span>
+            <span class="icon-bar"></span>
+            <span class="icon-bar"></span>
+            <span class="icon-bar"></span>
+          </button>
+          <a class="navbar-brand" href="https://dev.ripple.com/"><img class="small_logo" src="assets/img/ripple_logo_small.png"></a>
+        </div>
+        <div class="navbar-collapse collapse">
+          <ul class="nav navbar-nav">
+			<li><a href="/">Resources</a></li>
+            <li><a href="https://www.bountysource.com/teams/ripple/bounties">Bounties</a></li>
+            <li><a href="https://ripplelabs.atlassian.net/">Bug Tracking</a></li>
+            <li><a href="https://ripple.com/dev/blog/">Dev Blog</a></li>
+            <li><a href="https://ripple.com/forum/viewforum.php?f=2&sid=c016bc6b934120b7117c0e136e74de98">Forums</a></li>
+            <li class="dropdown active">
+              <a href="#" class="dropdown-toggle" data-toggle="dropdown">API Tool <span class="caret"></span></a>
+              <ul class="dropdown-menu" role="menu">
+                <li><a href="ripple-api-tool.html">WebSocket Tool</a></li>
+                <li class="active"><a href="rest-api-tool.html">REST Tool</a></li>
+              </ul>
+            </li>
+          </ul>
+          	<div class='right'>
+		 	 <!-- GitHub buttons -->
+		 		 <iframe src="https://dev.ripple.com/vendor/ghbtn.html?user=ripple&repo=ripple-dev-portal&type=watch&count=true" allowtransparency="true" frameborder="0" scrolling="0" width="110" height="20"></iframe>
+			</div>
+        </div><!--/.nav-collapse -->
+      </div>
+    </div>
+  <div class='content-root'>
+   <div id='wrapper'>
+    <div style="clear:both;"></div>
+    <div id='command_wrapper'>
+      <ul id='command_list'>
+        <li class='selected'>Generate Account</li>
+        <li>Get Account Balances</li>
+        <li>Get Account Settings</li>
+        <li>Update Account Settings</li>
+        <br/>
+        <li>Prepare Payment</li>
+        <li>Submit Payment</li>
+        <li>Confirm Payment</li>
+        <li>Get Payment History</li>
+        <br/>
+        <li>Get Trustlines</li>
+        <li>Grant Trustline</li>
+        <br/>
+        <li>Check Notifications</li>
+        <br/>
+        <li>Check Connection</li>
+        <li>Get Server Status</li>
+        <br/>
+        <li>Retrieve Ripple Transaction</li>
+        <li>Generate UUID</li>
+      </ul>
+      <div id='command_table'>
+        <div id='io_wrapper'>
+          <div id='input' class='io'>
+            <h2>REST Request</h2>
+            <div id='test_warning' class='alert alert-danger' style='display:none;'>
+                <h4>Test accounts only!</h4>
+                <p>Never submit account secrets to a server you do not control, unless you are prepared to lose ownership of the account!</p>
+            </div>
+            <div style="clear:both;"></div>
+            <h3 id='selected_command' title='Reference information'></h3>
+            <p id='description'></p>
+            <div id='invalid'>Invalid JSON</div>
+<!--            <select id='rest_method'>
+                <option value='GET'>GET</option>
+                <option value='POST'>POST</option>
+            </select>-->
+            <div id='rest_url_wrapper'>
+                <p><span id='rest_host'>https://api.ripple.com</span><span id='rest_url'></span></p>
+            </div>
+            <div id='request_body'></div>
+            <div id='request_options'>
+              <div class="button btn btn-primary api" id='request_button'>Send request</div>
+            </div>
+          </div>
+          <div id='output' class='io'>
+            <h2>Response</h2>
+            <div>
+                <img class="loader" src="assets/img/rippleThrobber.png" style="vertical-align: middle; display:none;"/>
+                <span id='rest_responsecode'></span>
+            </div>
+            <div id='response_body'></div>
+            <div id='tooltip'></div>
+          </div>
+        </div>
+      </div>
+    </div>
+  </div>
+  </div>
+<div class="footer">
+      <div class="container">
+        <p class="text-muted">
+        	<div class="row">
+				<div class="col-md-2">
+					
+						<ul class="footer_links applications">
+							<li><a href="https://www.rippletrade.com">Ripple Trade</a>
+							<li><a href="https://www.ripplecharts.com">Ripple Charts</a>
+							<li><a href="https://ripple.com/graph">Ripple Graph</a>
+							<li><a href="http://codius.org/">Codius</a>
+						</ul>
+				</div>
+				<div class="col-md-2">
+					
+						<ul class="footer_links middleware">
+							<li><a href="gatewayd.html">Gatewayd</a>
+							<li><a href="ripple-rest.html">Ripple REST</a>
+							<li><a href="https://github.com/ripple/ripple-lib">Ripple Lib</a>
+						</ul>
+				
+				</div>
+				<div class="col-md-2">
+					
+						<ul class="footer_links core_network">
+							<li><a href="rippled-apis.html">rippled</a>
+							<li><a href="transactions.html">Transactions</a>
+							<li><a href="consensus-whitepaper.html">Consensus</a>
+						</ul>
+				
+				</div>
+				<div class="col-md-2">
+						<ul class="footer_links bounties">
+							<li><a href="https://www.bountysource.com/teams/ripple/bounties">Bounties</a>
+							<li><a href="https://ripplelabs.atlassian.net/">Bug tracking</a>
+							<li><a href="guidelines.html">Brand guidelines</a>
+							<li><a href="https://ripple.com/dev/blog/">Dev blog</a>
+							<li><a href="https://ripple.com/forum/viewforum.php?f=2&sid=c016bc6b934120b7117c0e136e74de98">Forums</a>
+							<li><a href="https://ripple.com/wiki/Main_Page">Wiki</a>
+						</ul>
+				
+				</div>
+				<div class="col-md-4 mail_chimp">
+				<p>Join the mailing list!</p>
+				<label for="mce-EMAIL">Email address</label>
+					<!-- Begin MailChimp Signup Form -->
+						<link href="//cdn-images.mailchimp.com/embedcode/slim-081711.css" rel="stylesheet" type="text/css">
+						<style type="text/css">
+							#mc_embed_signup{clear:left; font:14px; }
+	
+						</style>
+						<div id="mc_embed_signup">
+						<form action="//ripple.us4.list-manage.com/subscribe/post?u=245dbc1c47849f034390dc5bf&amp;id=4dfbe160d0" method="post" id="mc-embedded-subscribe-form" name="mc-embedded-subscribe-form" class="validate" target="_blank" novalidate>
+	
+							<input type="email" value="" name="EMAIL" class="email" id="mce-EMAIL" placeholder="" required>
+							<!-- real people should not fill this in and expect good things - do not remove this or risk form bot signups-->
+							<div style="position: absolute; left: -5000px; top: -50px;"><input type="text" name="b_245dbc1c47849f034390dc5bf_4dfbe160d0" tabindex="-1" value=""></div>
+							<input type="submit" value="Submit" name="subscribe" id="mc-embedded-subscribe" class="button btn btn-primary">
+						</form>
+						</div>
+
+					<!--End mc_embed_signup-->
+				</div>
+      		</div>
+        
+      </div>
+    </div>
+  
+  <link rel='stylesheet' type='text/css' href='css/api-style.css'/>
+  <link rel='stylesheet' type='text/css' href='css/codemirror.css'/>
+  <script type='text/javascript' src='js/es5-shim.js'></script>
+  <script src='//cdnjs.cloudflare.com/ajax/libs/codemirror/3.16.0/codemirror.min.js'></script>
+  <script type='text/javascript' src='js/cm-javascript.min.js'></script>
+  <script type='text/javascript' src='js/jquery.autosize.input.min.js'></script>
+  <script type='text/javascript' src='js/apitool-rest.js'></script>
+
+
+</body>
+</html>
--- a/ripple-api-tool.html
+++ b/ripple-api-tool.html
@@ -5,7 +5,7 @@
  <meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">
  <meta name="viewport" content="width=device-width">

-  <title>Ripple Developer Portal: Ripple API Tool</title>
+  <title>Ripple Developer Portal: Websocket API Tool</title>

  <!-- favicon -->
  <link rel="icon" href="favicon.ico" type="image/x-icon"> 
@@ -25,11 +25,12 @@
  <!-- Custom Stylesheet -->
  <link href='https://fonts.googleapis.com/css?family=Montserrat' rel='stylesheet' type='text/css'>
  <link href='https://fonts.googleapis.com/css?family=Open+Sans:600italic,400,700,300' rel='stylesheet' type='text/css'>
-  <link  href='css/main.css' rel='stylesheet'>
-  <link  href='css/custom.css' rel='stylesheet'>
+  <link href='css/main.css' rel='stylesheet'>
+  <link href='css/custom.css' rel='stylesheet'>
+  <link href='css/mod.css' type='text/css' rel='stylesheet' />
  
-	<link rel="shortcut icon" href="favicon.ico?v=2" type="image/x-icon">
-	<link rel="icon" href="favicon.ico?v=2" type="image/x-icon">
+  <link rel="shortcut icon" href="favicon.ico?v=2" type="image/x-icon">
+  <link rel="icon" href="favicon.ico?v=2" type="image/x-icon">
  
  
  
@@ -58,14 +59,8 @@ mixpanel.init("132d42885e094171f34467fc54da6fab");
    

  
-
-  <!-- Temporary shims until I modify the css directly -->
-  <link type='text/css' rel='stylesheet' href='css/mod.css' />
-  <script src='js/expandcode.js'></script>
-  
 </head>
 <body role='flatdoc' class='no-literate'>
-<!--Draft warning would go here-->
 	<div class="navbar navbar-inverse navbar-fixed-top" role="navigation">
      <div class="container">
        <div class="navbar-header">
@@ -84,7 +79,13 @@ mixpanel.init("132d42885e094171f34467fc54da6fab");
            <li><a href="https://ripplelabs.atlassian.net/">Bug Tracking</a></li>
            <li><a href="https://ripple.com/dev/blog/">Dev Blog</a></li>
            <li><a href="https://ripple.com/forum/viewforum.php?f=2&sid=c016bc6b934120b7117c0e136e74de98">Forums</a></li>
-            <li class="active"><a target="_self" href="ripple-api-tool.html">API Tool</a></li>
+            <li class="dropdown active">
+              <a href="#" class="dropdown-toggle" data-toggle="dropdown">API Tool <span class="caret"></span></a>
+              <ul class="dropdown-menu" role="menu">
+                <li class="active"><a href="ripple-api-tool.html">WebSocket Tool</a></li>
+                <li><a href="rest-api-tool.html">REST Tool</a></li>
+              </ul>
+            </li>
          </ul>
          	<div class='right'>
 		 	 <!-- GitHub buttons -->
@@ -95,7 +96,6 @@ mixpanel.init("132d42885e094171f34467fc54da6fab");
    </div>
  <div class='content-root'>
   <div id='wrapper'>
-    <h1>Ripple WebSocket API tool</h1>
    <div id='online_state'>Offline</div>
    <div style="clear:both;"></div>
    <div id='command_wrapper'>
@@ -131,16 +131,16 @@ mixpanel.init("132d42885e094171f34467fc54da6fab");
      <div id='command_table'>
        <div id='io_wrapper'>
          <div id='input' class='io'>
-            <h2>Request</h2>
-            <div id='request_options'>
-              <div class="button btn btn-primary api" id='request_button'>Send request</div>
-            </div>
+            <h2>WebSocket Request</h2>
            <div style="clear:both;"></div>
            <h3 id='selected_command' title='Reference information'>server_info</h3>
            <p id='description'></p>
            <div id='invalid'>Invalid JSON</div>
            <p>JSON</p>
            <div id='request'></div>
+            <div id='request_options'>
+              <div class="button btn btn-primary api" id='request_button'>Send request</div>
+            </div>
          </div>
          <div id='output' class='io'>
            <h2>Response</h2>
@@ -149,7 +149,10 @@ mixpanel.init("132d42885e094171f34467fc54da6fab");
              <li id='stream_show'>show</li>
              <li id='stream_pause'>pause</li>
            </ul>
-            <div id='status'></div>
+            <div>
+                <img class="loader" src="assets/img/rippleThrobber.png" style="vertical-align: middle; display:none;"/>
+                <p id='status'></p>
+            </div>
            <p id='info'></p>
            <div id='response'></div>
            <div id='tooltip'></div>
@@ -185,6 +188,8 @@ mixpanel.init("132d42885e094171f34467fc54da6fab");
 					
 						<ul class="footer_links core_network">
 							<li><a href="rippled-apis.html">rippled</a>
+							<li><a href="transactions.html">Transactions</a>
+							<li><a href="consensus-whitepaper.html">Consensus</a>
 						</ul>
 				
 				</div>
--- a/ripple-rest.html
+++ b/ripple-rest.html
@@ -92,7 +92,13 @@ mixpanel.init("132d42885e094171f34467fc54da6fab");
            <li><a href="https://ripplelabs.atlassian.net/">Bug Tracking</a></li>
            <li><a href="https://ripple.com/dev/blog/">Dev Blog</a></li>
            <li><a href="https://ripple.com/forum/viewforum.php?f=2&sid=c016bc6b934120b7117c0e136e74de98">Forums</a></li>
-            <li><a href="ripple-api-tool.html">API Tool</a></li>
+            <li class="dropdown">
+              <a href="#" class="dropdown-toggle" data-toggle="dropdown">API Tool <span class="caret"></span></a>
+              <ul class="dropdown-menu" role="menu">
+                <li><a href="ripple-api-tool.html">WebSocket Tool</a></li>
+                <li><a href="rest-api-tool.html">REST Tool</a></li>
+              </ul>
+            </li>
          </ul>
          	<div class='right'>
 		 	 <!-- GitHub buttons -->
@@ -146,6 +152,8 @@ mixpanel.init("132d42885e094171f34467fc54da6fab");
 					
 						<ul class="footer_links core_network">
 							<li><a href="rippled-apis.html">rippled</a>
+							<li><a href="transactions.html">Transactions</a>
+							<li><a href="consensus-whitepaper.html">Consensus</a>
 						</ul>
 				
 				</div>
--- a/rippled-apis.html
+++ b/rippled-apis.html
--- a/ripplerest_api.md
+++ b/ripplerest_api.md
@@ -1,31 +1,48 @@
 # Ripple-REST API #

-The `ripple-rest` API makes it easy to access the Ripple system via a RESTful web interface.  In this section, we will cover the concepts you need to understand, and get you started accessing the API and learning how to use it.
+The Ripple-REST API provides a simplified, easy-to-use interface to the Ripple Network via a RESTful API. This page explains how to use the API to send and receive payments on Ripple.

-While there are other API's to use with Ripple (i.e. Accessing the `rippled` server directly via a web socket), this documentation is meant only for the `ripple-rest` API as this is the high-level API recommended for working with Ripple and some of the endpoints provide abstractions to make it much easier to use than the traditional websocket API's.
+We recommend Ripple-REST for users just getting started with Ripple, since it provides high-level abstractions and convenient simplifications in the data format. If you prefer to access a `rippled` server directly, you can use [rippled's WebSocket or JSON-RPC APIs](rippled-apis.html) instead, which provide the full power of Ripple at the cost of more complexity.

-Installation instructions and source code can be found in the `ripple-rest` repository <a href="https://github.com/ripple/ripple-rest" target="_blank">here</a>. 
-
-Older versions of the `ripple-rest` documentation will archived <a href="https://github.com/ripple/ripple-dev-portal/archive" target="_blank">here</a>.
+Installation instructions and source code can be found in the [Ripple-REST repository](https://github.com/ripple/ripple-rest).


 ## Available API Routes ##

-* [`GET /v1/accounts/{:address}/payments/paths`](#preparing-a-payment)
-* [`GET /v1/accounts/{:address}/payments`](#confirming-a-payment) 
-* [`GET /v1/accounts/{:address}/balances`](#account-balances)
-* [`GET /v1/accounts/{:address}/settings`](#account-settings)
-* [`GET /v1/accounts/{:address}/trustlines`](#reviewing-trustlines)
-* [`GET /v1/accounts/{:address}/notifications`](#checking-notifications)
-* [`GET /v1/server/connected`](#check-connection-state)
-* [`GET /v1/server`](#get-server-status)
-* [`GET /v1/tx`](#retrieve-ripple-transaction)
-* [`GET /v1/uuid`](#create-client-resource-id)
+#### Accounts ####
+
+* [Generate Account - `GET /v1/accounts/new`](#generating-accounts)
+* [Get Account Balances - `GET /v1/accounts/{:address}/balances`](#account-balances)
+* [Get Account Settings - `GET /v1/accounts/{:address}/settings`](#account-settings)
+* [Update Account Settings - `POST /v1/accounts/{:address}/settings`](#updating-account-settings)
+
+#### Payments ####
+
+* [Prepare Payment - `GET /v1/accounts/{:address}/payments/paths`](#prepare-payment)
+* [Submit Payment - `POST /v1/payments`](#submitting-a-payment)
+* [Confirm Payment - `GET /v1/accounts/{:address}/payments/{:payment}`](#confirming-a-payment)
+* [Get Payment History - `GET /v1/accounts/{:address}/payments`](#confirming-a-payment)
+
+#### Trustlines ####
+
+* [Get Trustlines - `GET /v1/accounts/{:address}/trustlines`](#reviewing-trustlines)
+* [Grant Trustline - `POST /v1/accounts/{:address}/trustlines`](#granting-a-trustline)
+
+#### Notifications ####
+
+* [Check Notifications - `GET /v1/accounts/{:address}/notifications/{:transaction_hash}`](#checking-notifications)
+
+#### Status ####
+
+* [Check Connection - `GET /v1/server/connected`](#check-connection-state)
+* [Get Server Status - `GET /v1/server`](#get-server-status)
+
+#### Utilities ####
+
+* [Retrieve Ripple Transaction - `GET /v1/tx`](#retrieve-ripple-transaction)
+* [Generate UUID - `GET /v1/uuid`](#create-client-resource-id)


-* [`POST /v1/payments`](#submitting-a-payment)
-* [`POST /v1/accounts/{:address}/settings`](#updating-account-settings)
-* [`POST /v1/accounts/{:address}/trustlines`](#granting-a-trustline)

 ## API Overview ##

@@ -33,7 +50,7 @@ Older versions of the `ripple-rest` documentation will archived <a href="https:/

 Ripple is a system for making financial transactions.  You can use Ripple to send money anywhere in the world, in any currency, instantly and for free.

-In the Ripple world, each account is identified by a <a href="https://ripple.com/wiki/Account" target="_blank">Ripple Address</a>.  A Ripple address is a string that uniquely identifies an account, for example: `rNsJKf3kaxvFvR8RrDi9P3LBk2Zp6VL8mp`
+In the Ripple world, each account is identified by a [Ripple Address](https://ripple.com/wiki/Account).  A Ripple address is a string that uniquely identifies an account, for example: `rNsJKf3kaxvFvR8RrDi9P3LBk2Zp6VL8mp`

 A Ripple ___payment___ can be sent using Ripple's native currency, XRP, directly from one account to another.  Payments can also be sent in other currencies, for example US dollars, Euros, Pounds or Bitcoins, though the process is slightly more complicated.

@@ -59,34 +76,45 @@ Note that when you submit a payment for processing, you have to assign a unique

 The Ripple protocol supports multiple types of transactions other than just payments. Transactions are considered to be any changes to the database made on behalf of a Ripple Address. Transactions are first constructed and then submitted to the network. After transaction processing, meta data is associated with the transaction which itemizes the resulting changes to the ledger.

-+ Payment: Payment transaction is an authorized transfer of balance from one address to another.
-
-+ Trustline: Trustline transaction is an authorized grant of trust between two addresses.
-
-+ Setting: Setting transaction is an authorized update of account flags under a Ripple Account.
+ * Payment: A Payment transaction is an authorized transfer of balance from one address to another. (This maps to rippled's [Payment transaction type](transactions.html#payment))
+ * Trustline: A Trustline transaction is an authorized grant of trust between two addresses. (This maps to rippled's [TrustSet transaction type](transactions.html#payment))
+ * Setting: A Setting transaction is an authorized update of account flags under a Ripple Account. (This maps to rippled's [AccountSet transaction type](transactions.html#payment))

 ## Getting Started ##

 ### Setup ###

-Before you can use the `ripple-rest` API, you will need to have three things:
+You don't need to do any setup to retrieve information from a public Ripple-REST server. Ripple Labs hosts a public Ripple-REST server here:

- * An installed version of `ripple-rest` running locally or remotely. Instructions on installing `ripple-rest` can be found in the readme.md file in the Github Repository <a href="https://github.com/ripple/ripple-rest" target="_blank">here</a>.
+`https://api.ripple.com`

- * An activated Ripple account.  If you don't have a Ripple account, you can use the Ripple web client to create one, as described in the <a href="https://ripple.com/wiki/Client_Manual" target="_blank">Client Manual</a>.  Make sure you have a copy of the Ripple address for your account; the address can be found by clicking on the __Receive__ tab in the web client.
+However, in order to submit payments or other transactions, you need an activated Ripple account. See the [online support](https://support.ripplelabs.com/hc/en-us/categories/200194196-Set-Up-Activation) for how you can create an account using the [Ripple Trade client](https://rippletrade.com/). 
+
+Make sure you know both the account address and the account secret for your account:
+ * The *address* can be found by clicking the *Show Address* button in the __Fund__ tab of Ripple Trade
+ * The *secret* is provided when you first create your account. **WARNING: If you submit your secret to a server you do not control, your account can be stolen, along with all the money in it.** We recommend using a test account with very limited funds on the public Ripple-REST server.
+
+If you want to run your own Ripple-REST server, see the [installation instructions](https://github.com/ripple/ripple-rest/#installing-and-running).
+
+
+As a programmer, you will also need to have a suitable HTTP client that allows you to make secure HTTP (`HTTPS`) GET and POST requests. There are lots of options, including:
+
+ * The [`curl`](http://curl.haxx.se/) commandline utility
+ * The [Poster Firefox extension](https://addons.mozilla.org/en-US/firefox/addon/poster/)
+ * The [Postman Chrome extension](https://chrome.google.com/webstore/detail/postman-rest-client/fdmmgilgnpjigdojojpjoooidkmcomcm?hl=en)
 
- * The URL of the server running the `ripple-rest` API that you wish to use.  In this documentation, we will assume that the server is installed and running on a server you have connectivity to. 
- 
-As a programmer, you will also need to have a suitable HTTP client library that allows you to make secure HTTP (`HTTPS`) requests.  To follow the examples below, you will need to have access to the `curl` command-line tool.
+You can also use the [REST API Tool](rest-api-tool.html) here on the Dev Portal to try out the API.
+
+[Try it! >](rest-api-tool.html)


 ### Exploring the API ###

-Let's start by using `curl` to see if the `ripple-rest` API is currently running.  Type the following into a terminal window:
+A REST API makes resources available via HTTP, the same protocol used by your browser to access the web. This means you can even use your browser to get a response from the API. Try visiting the following URL:

-`curl http://[ripple-rest-server]/v1/server`
+https://api.ripple.com/v1/server

-After a short delay, the following response should be displayed:
+The response should be a page with content similar to the following:

 ```js
 {
@@ -119,54 +147,70 @@ After a short delay, the following response should be displayed:
 }
 ```

-The `ripple-rest` API conforms to the following general behavior for a web interface:
+The `ripple-rest` API conforms to the following general behavior for [RESTful API](http://en.wikipedia.org/wiki/Representational_state_transfer):

 * The HTTP method identifies what you are trying to do.  Generally, HTTP `GET` requests are used to retrieve information, while HTTP `POST` requests are used to make changes or submit information.
-
-* You make HTTP (or HTTPS) requests to the API endpoint, including the desired resources within the URL itself.
-
+* You make HTTP (or HTTPS) requests to the API endpoint, indicating the desired resources within the URL itself. (The public server, for the sake of security, only accepts HTTPS requests.)
 * If more complicated information needs to be sent, it will be included as JSON-formatted data within the body of the HTTP POST request.
+* Upon successful completion, the server returns an [HTTP status code](http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html) of 200 OK, and a `Content-Type` value of `application/json`.  The body of the response will be a JSON-formatted object containing the information returned by the endpoint.

-* Upon completion, the server will return an HTTP status code of 200 (OK), and a `Content-Type` value of `application/json`.  The body of the response will be a JSON-formatted object containing the information returned by the endpoint.
-
-* The returned JSON object will include a `success` field indicating whether the request was successful or not.
+As an additional convention, all responses from Ripple-REST contain a `"success"` field with a boolean value indicating whether or not the success 


 ### Errors ###

-There are two different ways in which errors are returned by the `ripple-rest` API:
+When errors occur, the server returns an HTTP status code in the 400-599 range, depending on the type of error. The body of the response contains more detailed information on the cause of the problem. (*Note:* Old versions of Ripple-REST return 200 OK regardless of the outcome.)

-Low-level errors are indicated by the server returning an appropriate HTTP status code.  The following status codes are currently supported:
+In general, the HTTP status code is indicative of where the problem occurred:

-+ `Bad Request (400)` The JSON body submitted is malformed or invalid.  
-+ `Method Not Accepted (404)` The endpoint is not allowed.  
-+ `Gateway Timeout (502)` The rippled server is taking to long to respond.  
-+ `Bad Gateway (504)` The rippled server is non-responsive.
+* Codes in the 200-299 range indicate success. (*Note:* Old versions of Ripple-REST return 200 OK even in some failure cases.)
+* Codes in the 400-499 range indicate that the request was invalid or incorrect somehow. For example:
+    * `400 Bad Request` occurs if the JSON body is malformed. This includes syntax errors as well as when invalid or mutually-exclusive options are selected.
+    * `404 Not Found` occurs if the path specified does not exist, or does not support that method (for example, trying to POST to a URL that only serves GET requests)
+* Codes in the 500-599 range indicate that the server experienced a problem. This could be due to a network outage or a bug in the software somewhere. For example:
+    * `502 Bad Gateway` occurs if Ripple-REST could not contact its `rippled` server at all.
+    * `504 Gateway Timeout` occurs if the `rippled` server took too long to respond to the Ripple-REST server.

-Application-level errors are described further in the body of the JSON response with the following fields:
+When possible, the server provides a JSON response body with more information about the error. These responses contain the following fields:

-+ `success` This will be set to `false` if an error occurred.
-
-+ `error` A short string identifying the error that occurred.
-
-+ `message` A longer human-readable string explaining what went wrong.
+| Field | Value | Description |
+|-------|-------|-------------|
+|`success` | Boolean | `false` indicates that an error occurred. |
+| `error_type` | String | A short string identifying the error that occurred. |
+| `message` | String | A longer human-readable string explaining what went wrong. |


-### API Objects ###
+# Formatting Conventions #

-#### <a id="amount_object"></a> 1. Amount ####
+## Quoted Numbers ##
+
+In any case where a large number should be specified, Ripple-REST uses a string instead of the native JSON number type. This avoids problems with JSON libraries which might automatically convert numbers into native types with differing range and precision.
+
+You should parse these numbers into a numeric data type with adequate precision. If it is not clear how much precision you need, we recommend using an arbitrary-precision data type.
+
+## <a id="amount_object"></a> Currency Amounts ##

 All currencies on the Ripple Network have issuers, except for XRP. In the case of XRP, the `issuer` field may be omitted or set to `""`. Otherwise, the `issuer` must be a valid Ripple address of the gateway that issues the currency.

-For more information about XRP see  <a href="https://ripple.com/wiki/XRP" target="_blank">the Ripple wiki page on XRP</a>. For more information about using currencies other than XRP on the Ripple Network see <a href="https://ripple.com/wiki/Ripple_for_Gateways" target="_blank">the Ripple wiki page for gateways</a>.
+For more information about XRP see [the Ripple wiki page on XRP](https://ripple.com/wiki/XRP). For more information about using currencies other than XRP on the Ripple Network see [the Ripple wiki page for gateways](https://ripple.com/wiki/Ripple_for_Gateways).

-Amount Object:
+### Amounts in JSON ###
+
+When an amount of currency (or other asset) is specified as part of a JSON body, it is encoded as an object with three fields:
+
+| Field | Value | Description |
+|-------|-------|-------------|
+| value | String (Quoted decimal) | The quantity of the currency |
+| currency | String | Three-digit [ISO 4217 Currency Code](http://www.xe.com/iso4217.php) specifying which currency |
+| issuer | String | The Ripple address of the account issuing the currency. This is usually an [issuing gateway](https://wiki.ripple.com/Gateway_List). Always an empty string for XRP. |
+
+Example Amount Object:

 ```js
 {
  "value": "1.0",
  "currency": "USD",
-  "issuer": "r..."
+  "issuer": "rMwjYedjc7qqtKYVLiAccJSmCwih4LnE2q"
 }
 ```

@@ -180,54 +224,30 @@ or for XRP:
 }
 ```

-#### <a id="payment_object"></a> 2. Payment ####
+The `value` field can get very large or very small. See the [Currency Format](https://wiki.ripple.com/Currency_Format) for the exact limits of Ripple's precision.

-The `Payment` object is a simplified version of the standard Ripple transaction format. 
+### Amounts in URLs ###
+
+When an amount of currency has to be specified in a URL, you use the same fields as the JSON object -- value, currency, and issuer -- but concatenate them with `+` symbols. 
+
+Example Amount:
+
+`1.0+USD+rMwjYedjc7qqtKYVLiAccJSmCwih4LnE2q`
+
+When specifying an amount of XRP, you can omit the issuer entirely. For example:
+
+`1.0+XRP`
+
+## <a id="payment_object"></a> Payment Objects ##
+
+The `Payment` object is a simplified version of the standard Ripple transaction format.

 This `Payment` format is intended to be straightforward to create and parse, from strongly or loosely typed programming languages. Once a transaction is processed and validated it also includes information about the final details of the payment.

-<!-- A minimal `Payment` object will look like this:
+An example Payment object looks like this:

 ```js
 {
-  "src_address": "rKXCummUHnenhYudNb9UoJ4mGBR75vFcgz",
-  "dst_address": "rNw4ozCG514KEjPs5cDrqEcdsi31Jtfm5r",
-  "dst_amount": {
-    "value": "0.001",
-    "currency": "XRP",
-    "issuer": ""
-  }
-}
-```
-->
-
- + `source_address` is the Ripple address for the source account, as a string.
- 
- + `destination_address` is the Ripple address for the destination account, as a string.
- 
- + `destination_amount` is an [Amount](#amount_object) object representing the amount that should be deposited into the destination account.
-
-The full set of fields accepted on `Payment` submission is as follows:
-
-+ `source_tag` is an optional unsigned 32 bit integer (0-4294967294, inclusive) that is generally used if the sender is a hosted wallet at a gateway. This should be the same as the `destination_tag` used to identify the hosted wallet when they are receiving a payment.
-
-+ `destination_tag` is an optional unsigned 32 bit integer (0-4294967294, inclusive) that is generally used if the receiver is a hosted wallet at a gateway.
-
-+ `source_slippage` can be specified to give the `source_amount` a cushion and increase its chance of being processed successfully. This is helpful if the payment path changes slightly between the time when a payment options quote is given and when the payment is submitted. The `source_address` will never be charged more than `source_slippage` + the `value` specified in `source_amount`.
-
-+ `invoice_id` is an optional 256-bit hash field that can be used to link payments to an invoice or bill.
-
-+ `paths` is a "stringified" version of the Ripple PathSet structure. Most users of this API will want to treat this field as opaque. See the [Ripple Wiki](https://ripple.com/wiki/Payment_paths) for more information about Ripple pathfinding.
-
-+ `flag_no_direct_ripple` is a boolean that can be set to `true` if `paths` are specified and the sender would like the Ripple Network to disregard any direct paths from the `source_address` to the `destination_address`. This may be used to take advantage of an arbitrage opportunity or by gateways wishing to issue balances from a hot wallet to a user who has mistakenly set a trustline directly to the hot wallet. Most users will not need to use this option.
-
-+ `flag_partial_payment` is a boolean that, if set to true, indicates that this payment should go through even if the whole amount cannot be sent because of a lack of liquidity or funds in the `source_address` account. The vast majority of senders will never need to use this option.
-
-Payment Object:
-
-```js
-{
-    /* User Specified */

    "source_address": "rKXCummUHnenhYudNb9UoJ4mGBR75vFcgz",
    "source_tag": "",
@@ -244,42 +264,62 @@ Payment Object:
        "currency": "XRP",
        "issuer": ""
    },
-
-    /* Advanced Options */
-
    "invoice_id": "",
    "paths": "[]",
    "flag_no_direct_ripple": false,
    "flag_partial_payment": false
 }
 ```
+
+The fields of a Payment object are defined as follows:
+
+| Field | Value | Description |
+|-------|-------|-------------|
+| `source_address` | String | The Ripple address of the account sending the payment |
+| `destination_address` | String |The Ripple address of the account receiving the payment |
+| `destination_amount` | [Amount Object](#amount_object) | The amount of currency that should be deposited into the account receiving the payment. |
+| `source_tag` | Unsigned Integer | (Optional) A 32-bit unsigned integer (0-4294967294, inclusive) that is generally used if the sender is a hosted wallet at a gateway. This should be the same as the `destination_tag` used to identify the hosted wallet when they are receiving a payment. |
+| `destination_tag` | Unsigned Integer | (Optional) A 32-bit unsigned integer (0-4294967294, inclusive) that is generally used if the recipient of the payment is a hosted wallet at a gateway. |
+| `source_slippage` | String (Quoted decimal number) | can be specified to give the `source_amount` a cushion and increase its chance of being processed successfully. This is helpful if the payment path changes slightly between the time when a payment options quote is given and when the payment is submitted. The `source_address` will never be charged more than `source_slippage` + the `value` specified in `source_amount`. |
+| `invoice_id` | String | (Optional) 256-bit hash that can be used to link payments to an invoice or bill. |
+| `paths` | String | A "stringified" version of the Ripple PathSet structure. You can get a path for your payment from the [Prepare Payment](#prepare-payment) method. |
+| `flag_no_direct_ripple` | Boolean  | (Optional, defaults to false) `true` if `paths` are specified and the sender would like the Ripple Network to disregard any direct paths from the `source_address` to the `destination_address`. This may be used to take advantage of an arbitrage opportunity or by gateways wishing to issue balances from a hot wallet to a user who has mistakenly set a trustline directly to the hot wallet. Most users will not need to use this option. |
+| `flag_partial_payment` | Boolean | (Optional, defaults to false) If set to `true`, fees will be deducted from the delivered amount instead of the sent amount. (*Caution:* There is no minimum amount that will actually arrive as a result of using this flag; only a miniscule amount may actually be received.) See [Partial Payments](transactions.html#partial-payments) |
+
+
 # PAYMENTS #

 `ripple-rest` provides access to `ripple-lib`'s robust transaction submission processes. This means that it will set the fee, manage the transaction sequence numbers, sign the transaction with your secret, and resubmit the transaction up to 10 times if `rippled` reports an initial error that can be solved automatically.

-## Making Payments ##
+## Payments ##

-### Preparing a Payment ###
+## Prepare Payment ##

-__GET /v1/accounts/{:address}/payments/paths/{destination_account}/{destination_amount}__
+__GET /v1/accounts/{:address}/payments/paths/{:destination_account}/{:destination_amount}__

+[Try it! >](rest-api-tool.html#prepare-payment)

-To prepare a payment, you first make an HTTP `GET` call to the above endpoint.  This will generate a list of possible payments between the two parties for the desired amount, taking into account the established trustlines between the two parties for the currency being transferred.  You can then choose one of the returned payments, modify it if necessary (for example, to set slippage values or tags), and then submit the payment for processing.
+Before you make a payment, it is necessary to figure out the possible ways in which that payment can be made. This method gets a list possible ways to make a payment, but it does not affect the network: consider it like getting quotes before actually making the payment.
+
+You can then choose one of the returned payment objects, modify it as desired (for example, to set slippage values or tags), and then submit the payment for processing.

 The following URL parameters are required by this API endpoint:

-+ `address` *[required]* The Ripple address for the source account.
-+ `destination_account` *[required]* The Ripple address for the destination account.
-+ `destination_amount` *[required]* The amount to be sent to the destination account.  Note that this value uses `+` characters to separate the `value`, `currency` and `issuer` fields.  
-+ For XRP, the format is: `0.1+XRP`
- 
-+ For other currencies, you need to include the Ripple address of the currency's issuer, like this: `0.1+USD+r...`
+| Field | Value | Description |
+|-------|-------|-------------|
+| `address` | String | The Ripple address for the account that would send the payment. |
+| `destination_account` | String | The Ripple address for the account that would receive the payment. |
+| `destination_amount` | String ([URL-formatted Amount](#amounts-in-urls) | The amount that the destination account should receive. |

-Optionally, you can also include the following as a query string parameter:
+Optionally, you can also include the following as a query parameter:

-`source_currencies` *[optional]* A comma-separated list of source currencies.  This is used to filter the returned list of possible payments.  Each source currency can be specified either as a currency code (eg, `USD`), or as a currency code and issuer (eg, `USD+r...`).  If the issuer is not specified for a currency other than XRP, then the results will be limited to the specified currency, but any issuer for that currency will be included in the results.
+| Field | Value | Description |
+|-------|-------|-------------|
+| `source_currencies` | Comma-separated list of source currencies. Each should be an [ISO 4217 currency code](http://www.xe.com/iso4217.php), or a `{:currency}+{:issuer}` string. | Filters possible payments to include only ones that spend the source account's balances in the specified currencies. If an issuer is not specified, include all issuances of that currency held by the sending account. |

-Note that this call is a wrapper around the [Ripple path-find](https://ripple.com/wiki/RPC_API#path_find) command, and returns an array of [`Payment`](#payment_object) objects, like this:
+This method effectively performs a [ripple_path_find](rippled-apis.html#ripple-path-find) and constructs a payment object for the paths it finds.
+
+Response Body:

 ```js
 {
@@ -306,73 +346,52 @@ Before you can submit a payment, you will need to have three pieces of informati
 + The `secret` *[required]* or private key for your Ripple account.

 __DO NOT SUBMIT YOUR SECRET TO AN UNTRUSTED REST API SERVER__ -- this is the key to your account and your money. If you are using the test server provided, only use test accounts to submit payments.
- 
-+ A `client_resource_id` *[required]* that will uniquely identify this payment.  This is a 36-character UUID (universally unique identifier) value which will uniquely identify this payment within the `ripple-rest` API.  Note that you can use the [`GET /v1/uuid`](#calculating_a_uuid) endpoint to calculate a UUID value if you do not have a UUID generator readily available.
+
+ A `client_resource_id` *[required]* that will uniquely identify this payment.  This is a 36-character UUID (universally unique identifier) value which will uniquely identify this payment within the `ripple-rest` API. This value can be any unique string such as "123" or "ABC123".  Note that you can use the [`GET /v1/uuid`](#calculating_a_uuid) endpoint to calculate a UUID value if you do not have a UUID generator readily available.

 This HTTP `POST` request must have a content-type of `application/json`, and the body of the request should look like this:

 ```js
 {
  "secret": "s...",
-  "client_resource_id": "...",
+  "client_resource_id": "123",
  "payment": {
-    "source_account": "rPs7nVbSops6xm4v77wpoPFf549cqjzUy9",
+    "source_account": "rBEXjfD3MuXKATePRwrk4AqgqzuD9JjQqv",
    "source_tag": "",
    "source_amount": {
-    "value": "1",
-    "currency": "XRP",
-    "issuer": ""
+      "value": "5.01",
+      "currency": "USD",
+      "issuer": ""
    },
    "source_slippage": "0",
-    "destination_account" "rKB4oSXwPkRpb2sZRhgGyRfaEhhYS6tf4M",
+    "destination_account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
    "destination_tag": "",
    "destination_amount": {
-      "value": "1",
-      "currency": "XRP",
+      "value": "5",
+      "currency": "USD",
      "issuer": ""
-    }, 
+    },
    "invoice_id": "",
-    "paths": "[]",
-    "no_direct_ripple": false,
+    "paths": "[[{\"account\":\"rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B\",\"type\":1,\"type_hex\":\"0000000000000001\"}]]",
    "partial_payment": false,
-    "direction": "outgoing",
-    "state": "validated",
-    "result": "tesSUCCESS",
-    "ledger": "6141074",
-    "hash": "85C5E6762DE7969DC1BD69B3C8C7387A5B8FCE6A416AA1F74C0ED5D10F08EADD",
-    "timestamp": "2014-04-18T01:21:00.000Z",
-    "fee": "0.000012",
-    "source_balance_changes": 
-    [ 
-      {
-        "value": "-1.000012",
-        "currency": "XRP",
-        "issuer": ""
-      }
-    ],
-    "destination_balance_changes": 
-    [
-      {
-        "value": "1",
-        "currency": "XRP",
-        "issuer": ""
-      }
-    ]
+    "no_direct_ripple": false
  }
 }
 ```

+[Try it! >](rest-api-tool.html#submit-payment)
+
 Upon completion, the server will return a JSON object which looks like the following:

 ```js
 {
  "success": true,
-  "client_resource_id": "f2f811b7-dc3b-4078-a2c2-e4ca9e453981",
-  "status_url": ".../v1/accounts/r1.../payments/f2f811b7-dc3b-4078-a2c2-e4ca9e453981"
+  "client_resource_id": "123",
+  "status_url": ".../v1/accounts/r1.../payments/123"
 }
 ```

-The `status_url` value is a URL that can be queried to get the current status for this payment.  This will be a reference to the `GET /v1/accounts/{account}/payments` endpoint, with the client resource ID filled in to retrieve the details of the payment.  More information on this endpoint can be found in the section on [confirming a payment](#confirming-a-payment).
+The `status_url` value is a URL that can be queried to get the current status for this payment.  This will be a reference to the `GET /v1/accounts/{:address}/payments` endpoint, with the client resource ID filled in to retrieve the details of the payment.  More information on this endpoint can be found in the section on [confirming a payment](#confirming-a-payment).

 If an error occurred that prevented the payment from being submitted, the response object will look like this:

@@ -390,7 +409,11 @@ Note that payments cannot be cancelled once they have been submitted.

 ### Confirming a Payment ###

-__`GET /v1/accounts/{:address}/payments/{:hash} or {:client_resource_id}`__
+__`GET /v1/accounts/{:address}/payments/{:id}`__
+
+The `{:id}` value can be either a client resource identifier or a transaction hash value.
+
+[Try it! >](rest-api-tool.html#confirm-payment)

 To confirm that your payment has been submitted successfully, you can call this API endpoint.  The `hash` value can either be the transaction hash for the desired payment, or the payment's client resource ID.

@@ -414,7 +437,7 @@ The server will return the details of your payment:
    "value": "1",
    "currency": "XRP",
    "issuer": ""
-  }, 
+  },
  "invoice_id": "",
  "paths": "[]",
  "no_direct_ripple": false,
@@ -426,15 +449,15 @@ The server will return the details of your payment:
  "hash": "85C5E6762DE7969DC1BD69B3C8C7387A5B8FCE6A416AA1F74C0ED5D10F08EADD",
  "timestamp": "2014-04-18T01:21:00.000Z",
  "fee": "0.000012",
-  "source_balance_changes": 
-  [ 
+  "source_balance_changes":
+  [
    {
      "value": "-1.000012",
      "currency": "XRP",
      "issuer": ""
    }
  ],
-  "destination_balance_changes": 
+  "destination_balance_changes":
  [
    {
      "value": "1",
@@ -465,6 +488,8 @@ As well as sending payments, your application will need to know when incoming pa

 __`GET /v1/accounts/{:address}/payments`__

+[Try it! >](rest-api-tool.html#get-payment-history)
+
 This will return the most recent payments (both incoming and outgoing will be denoted in the direction)

 ```js
@@ -476,7 +501,7 @@ This will return the most recent payments (both incoming and outgoing will be de
    { /* payment */ }.
    { /* payment */ }.
    { /* payment */ }
-  ]    
+  ]
 }
 ```
 __`GET /v1/accounts/{:address}/payments?direction=incoming`__
@@ -506,18 +531,20 @@ Using this approach, you can regularly poll for new incoming payments, confident

 __`GET /v1/accounts/{:address}/payments`__

+[Try it! >](rest-api-tool.html#get-payment-history)
+
 This API endpoint can be used to browse through an account's payment history and also used to confirm specific payments after a payment has been submitted. The following query string parameters can be used to filter the list of returned payments:

 + `source_account` Filter the results to only include payments sent by the given account.
- 
+
 + `destination_account` Filter the results to only include payments received by the given account.

 + `exclude_failed` If set to `true`, the results will only include payments which were successfully validated and written into the ledger.  Otherwise, failed payments will be included.

-+ `direction` Limit the results to only include the given type of payments.  The following direction values are currently supported: 
- + `incoming` 
- + `outgoing` 
- + `pending` 
+ `direction` Limit the results to only include the given type of payments.  The following direction values are currently supported:
+ + `incoming`
+ + `outgoing`
+ + `pending`
 + `earliest_first` If set to `true`, the payments will be returned in ascending date order.  Otherwise, the payments will be returned in descending date order (ie, the most recent payment will be returned first).  Defaults to `false`.

 + `start_ledger` The index for the starting ledger.  If `earliest_first` is `true`, this will be the oldest ledger to be queried; otherwise, it will be the most recent ledger.  Defaults to the first ledger in the `rippled` server's database.
@@ -525,7 +552,7 @@ This API endpoint can be used to browse through an account's payment history and
 + `end_ledger` The index for the ending ledger.  If `earliest_first` is `true`, this will be the most recent ledger to be queried; otherwise, it will be the oldest ledger.  Defaults to the most recent ledger in the `rippled` server's database.

 + `results_per_page` The maximum number of payments to be returned at once.  Defaults to 20.
- 
+
 + `page` The page number to be returned.  The first page of results will have page number `1`, the second page will have page number `2`, and so on.  Defaults to `1`.

 Upon completion, the server will return a JSON object which looks like the following:
@@ -559,10 +586,41 @@ Note that the `ripple-rest` API has to retrieve the full list of payments from t

 `ripple-rest` provides the ability to review and confirm on information regarding your Ripple account. You can view your current balances and settings, as well as the ability to set your account setting flags.

+## Generating Accounts ##
+
+(New in [Ripple-REST v1.3.0](https://github.com/ripple/ripple-rest/releases/tag/v1.3.0-rc1))
+
+There are two steps to making a new account on the Ripple network: randomly creating the keys for that account, and sending it enough XRP to meet the account reserve.
+
+Generating the keys can be done offline, since it does not affect the network at all. To make it easy, Ripple-REST can generate account keys for you.
+
+*Caution:* Ripple account keys are very sensitive, since they give full control over that account's money on the Ripple network. Do not transmit them to untrusted servers, or unencrypted over the internet (for example, through HTTP instead of HTTPS). There *are* bad actors who are sniffing around for account keys so they can steal your money!
+
+__`GET /v1/accounts/new`__
+
+[Try it! >](rest-api-tool.html#generate-account)
+
+The response is an object with the address and the secret for a potential new account:
+
+```js
+{
+    "success": true,
+    "account": {
+        "address": "raqFu9wswvHYS4q5hZqZxVSYei73DQnKL8",
+        "secret": "shUzHiYxoXX2FgA54j42cXCZ9dTVT"
+    }
+}
+```
+
+The second step is [making a payment](#making-payments) of XRP to the new account address. (Ripple lets you send XRP to any mathematically possible account address, which creates the account if necessary.) The generated account does not exist in the ledger until it receives enough XRP to meet the account reserve.
+
+
 ## Account Balances ##

 __`GET /v1/accounts/{:address}/balances`__

+[Try it! >](rest-api-tool.html#get-account-balances)
+
 Retrieve the current balances for the given Ripple account.

 The `account` parameter should be set to the Ripple address of the desired account.  The server will return a JSON object which looks like the following:
@@ -581,7 +639,7 @@ The `account` parameter should be set to the Ripple address of the desired accou
      "amount": "512.79",
      "issuer": "r...",
    }
-    ...  
+    ...
  ]
 }
 ```
@@ -592,7 +650,9 @@ There will be one entry in the `balances` array for the account's XRP balance, a

 You can retrieve an account's settings by using the following endpoint:

-__`GET /v1/accounts/{account}/settings`__
+__`GET /v1/accounts/{:address}/settings`__
+
+[Try it! >](rest-api-tool.html#get-account-settings)

 The server will return a list of the current settings in force for the given account, in the form of a JSON object:

@@ -613,9 +673,9 @@ The server will return a list of the current settings in force for the given acc

 The following account settings are currently supported:

-+ `PasswordSpent` `true` if the password has been "spent", else `false`. 
+ `PasswordSpent` `true` if the password has been "spent", else `false`.
 <!--NOTE: This is not currently listed in the account settings schema, so I'm not sure what this setting is used for.
--> 
+-->
 + `RequireDestTag` If this is set to `true`, incoming payments will only be validated if they include a `destination_tag` value.  Note that this is used primarily by gateways that operate exclusively with hosted wallets.

 + `RequireAuth` If this is set to `true`, incoming trustlines will only be validated if this account first creates a trustline to the counterparty with the authorized flag set to true.  This may be used by gateways to prevent accounts unknown to them from holding currencies they issue.
@@ -623,18 +683,18 @@ The following account settings are currently supported:
 + `DisallowXRP` If this is set to `true`, payments in XRP will not be allowed.

 + `EmailHash` The MD5 128-bit hash of the account owner's email address, if known.
- 
+
 + `MessageKey` An optional public key, represented as a hex string, that can be used to allow others to send encrypted messages to the account owner.

 + `Domain` The domain name associated with this account.
- 
+
 + `TransferRate` The rate charged each time a holder of currency issued by this account transfers some funds.  The default rate is `"1.0"; a rate of `"1.01"` is a 1% charge on top of the amount being transferred.  Up to nine decimal places are supported.

 ## Updating Account Settings ##

 To change an account's settings, make an HTTP `POST` request to the above endpoint.  The request must have a content-type of `application/json`, and the body of the request should look like this:

-__`POST /v1/accounts/{account}/settings`__
+__`POST /v1/accounts/{:address}/settings`__

 ```js
 {
@@ -651,22 +711,26 @@ __`POST /v1/accounts/{account}/settings`__
 }
 ```

+[Try it! >](rest-api-tool.html#update-account-settings)
+
 The given settings will be updated.

 # TRUSTLINES #

 ## Reviewing Trustlines ##

-__`GET /v1/account/{:address}/trustlines`__
+__`GET /v1/accounts/{:address}/trustlines`__

-Retrieves all trustlines associated with the Ripple address. Upon completion, the server will return a JSON object which represents each trustline individually along with the currency, limit, and counterparty. 
+[Try it! >](rest-api-tool.html#get-trustlines)
+
+Retrieves all trustlines associated with the Ripple address. Upon completion, the server will return a JSON object which represents each trustline individually along with the currency, limit, and counterparty.

 The following query string parameters are supported to provide additional filtering for either trustlines to a particular currency or trustlines from a specific counterparty:

 + `currency` Three letter currency denominations (i.e. USD, BTC).
 + `counterparty` Ripple address of the counterparty trusted.

-__`GET /v1/account/{:address}/trustlines?currency=USD&counterparty=rPs723Dsd...`__
+__`GET /v1/accounts/{:address}/trustlines?currency=USD&counterparty=rPs723Dsd...`__

 The object returned looks like this:

@@ -691,10 +755,7 @@ The object returned looks like this:
      "reciprocated_trust_limit": "0",
      "account_allows_rippling": false,
      "counterparty_allows_rippling": true
-    },
-    { /* trustline */ },
-    { /* trustline */ },
-    { /* trustline */ }
+    }
  ]
 }
 ```
@@ -716,6 +777,10 @@ A trustline can also updated and simply set with a currency,amount,counterparty
  }
 }
 ```
+
+[Try it! >](rest-api-tool.html#grant-trustline)
+
+
 A successful submission will result in a returning JSON object that includes a transaction hash to the trustline transaction.

 ```js
@@ -740,6 +805,8 @@ Notifications can be used as a looping mechanism to monitor any transactions aga

 __`GET /v1/accounts/{:address}/notifications/{:transaction_hash}`__

+[Try it! >](rest-api-tool.html#check-notifications)
+
 This endpoint will grab the notification based on the specific transaction hash specified. Once called the notification object retreived will provide information on the type of transaction and also the previous and next notifications will be shown as well. The `previous_notification_url` and `next_notification_url` can be used to walk up and down the notification queue. Once the `next_notification_url` is empty that means you have the most current notification, this applies for the `previous_notification_url` similarly when it's empty as it means you are holding the earliest notification available on the `rippled` you are connecting to.

 A successful retrieval will look like this:
@@ -774,9 +841,11 @@ The earliest notification available on the `rippled` server will show `previous_
 The following two endpoints can be used to check if the `ripple-rest` API is currently connected to a `rippled` server, and to retrieve information about the current status of the API.

 ## Check Connection State ##
-<span></span>
+
 __`GET /v1/server/connected`__

+[Try it! >](rest-api-tool.html#check-connection)
+
 Checks to see if the `ripple-rest` API is currently connected to a `rippled` server, and is ready to be used.  This provides a quick and easy way to check to see if the API is up and running, before attempting to process transactions.

 No additional parameters are required.  Upon completion, the server will return `true` if the API is connected, and `false` otherwise.
@@ -789,42 +858,43 @@ No additional parameters are required.  Upon completion, the server will return
 ```

 ## Get Server Status ##
-<span></span>
+
 __`GET /v1/server`__

+[Try it! >](rest-api-tool.html#get-server-status)
+
 Retrieve information about the current status of the `ripple-rest` API and the `rippled` server it is connected to.

 This endpoint takes no parameters, and returns a JSON object with information on the current status of the API:

 ```js
 {
-  "api_server_status": "online",
-  "rippled_server_url": "wss://s_west.ripple.com:443",
+  "success": true,
+  "api_documentation_url": "https://github.com/ripple/ripple-rest",
+  "rippled_server_url": "wss://s1.ripple.com:443",
  "rippled_server_status": {
-    "info": {
-      "build_version": "0.21.0-rc2",
-      "complete_ledgers": "32570-4805506",
-      "hostid": "BUSH",
-      "last_close": {
-        "converge_time_s": 2.011,
-        "proposers": 5
-      },
-      "load_factor": 1,
-      "peers": 51,
-      "pubkey_node": "n9KNUUntNaDqvMVMKZLPHhGaWZDnx7soeUiHjeQE8ejR45DmHyfx",
-      "server_state": "full",
-      "validated_ledger": {
-        "age": 2,
-        "base_fee_xrp": 0.00001,
-        "hash": "2B79CECB06A500A2FB92F4FB610D33A20CF8D7FB39F2C2C7C3A6BD0D75A1884A",
-        "reserve_base_xrp": 20,
-        "reserve_inc_xrp": 5,
-        "seq": 4805506
-      },
-      "validation_quorum": 3
-    }
-  },
-  "api_documentation_url": "https://github.com/ripple/ripple-rest"
+    "build_version": "0.26.3-sp1",
+    "complete_ledgers": "32570-8926343",
+    "hostid": "LIED",
+    "io_latency_ms": 1,
+    "last_close": {
+      "converge_time_s": 3.068,
+      "proposers": 5
+    },
+    "load_factor": 1,
+    "peers": 52,
+    "pubkey_node": "n9LpxYuMx4Epz4Wz8Kg2kH3eBTx1mUtHnYwtCdLoj3HC85L2pvBm",
+    "server_state": "full",
+    "validated_ledger": {
+      "age": 10,
+      "base_fee_xrp": 0.00001,
+      "hash": "5A24FC580674F444BAA72B897C906FF1E167227869BF3D2971C2D87272B038EF",
+      "reserve_base_xrp": 20,
+      "reserve_inc_xrp": 5,
+      "seq": 8926343
+    },
+    "validation_quorum": 3
+  }
 }
 ```

@@ -845,6 +915,8 @@ While the `ripple-rest` API is a high-level API built on top of the `rippled` se

 __`GET /v1/tx/{:transaction_hash}`__

+[Try it! >](rest-api-tool.html#retrieve-ripple-transaction)
+
 This retrieves the underlying Ripple transaction with the given transaction hash value.  Upon completion, the server will return following JSON object:

 ```js
@@ -868,9 +940,11 @@ If the given transaction could not be found in the `rippled` server's historical


 ## Create Client Resource ID ##
-<span></span>
+
 __`GET /v1/uuid`__

+[Try it! >](rest-api-tool.html#generate-uuid)
+
 This endpoint creates a universally unique identifier (UUID) value which can be used to calculate a client resource ID for a payment.  This can be useful if the application does not have a UUID generator handy.

 This API endpoint takes no parameters, and returns a JSON object which looks like the following:
@@ -878,6 +952,6 @@ This API endpoint takes no parameters, and returns a JSON object which looks lik
 ```js
 {
  "success": true,
-  "uuid": "xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx"
+  "uuid": "a5a8fe40-3795-4b10-b2b6-f05f3ca31db9"
 }
 ```
--- a/terms-conditions.html
+++ b/terms-conditions.html
@@ -74,7 +74,13 @@ mixpanel.init("132d42885e094171f34467fc54da6fab");
            <li><a href="https://ripplelabs.atlassian.net/">Bug Tracking</a></li>
            <li><a href="https://ripple.com/dev/blog/">Dev Blog</a></li>
            <li><a href="https://ripple.com/forum/viewforum.php?f=2&sid=c016bc6b934120b7117c0e136e74de98">Forums</a></li>
-            <li><a href="ripple-api-tool.html">API Tool</a></li>
+            <li class="dropdown">
+              <a href="#" class="dropdown-toggle" data-toggle="dropdown">API Tool <span class="caret"></span></a>
+              <ul class="dropdown-menu" role="menu">
+                <li><a href="ripple-api-tool.html">WebSocket Tool</a></li>
+                <li><a href="rest-api-tool.html">REST Tool</a></li>
+              </ul>
+            </li>
          </ul>
          	<div class='right'>
 		 	 <!-- GitHub buttons -->
@@ -174,6 +180,8 @@ mixpanel.init("132d42885e094171f34467fc54da6fab");
 					
 						<ul class="footer_links core_network">
 							<li><a href="rippled-apis.html">rippled</a>
+							<li><a href="transactions.html">Transactions</a>
+							<li><a href="consensus-whitepaper.html">Consensus</a>
 						</ul>
 				
 				</div>
--- a/transactions.html
+++ b/transactions.html
@@ -0,0 +1,211 @@
+<!DOCTYPE html>
+<html>
+<head>
+  <meta charset="utf-8">
+  <meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">
+  <meta name="viewport" content="width=device-width">
+
+  <title>Ripple Developer Portal: Transactions</title>
+
+  <!-- favicon -->
+  <link rel="icon" href="favicon.ico" type="image/x-icon"> 
+  <link rel="shortcut icon" href="favicon.ico" type="image/x-icon"> 
+  <script src="https://ajax.googleapis.com/ajax/libs/jquery/1.11.1/jquery.min.js"></script>
+  
+  <!-- Flatdoc -->
+  <script src="https://dev.ripple.com/vendor/flatdoc/v/0.8.0/legacy.js"></script>
+  <script src="https://dev.ripple.com/vendor/flatdoc/v/0.8.0/flatdoc.js"></script>
+  
+   <!-- Bootstrap -->
+ 
+   <link href="css/bootstrap.min.css" rel="stylesheet">
+   <script src="js/bootstrap.min.js"></script>
+
+  <!-- Flatdoc theme -->
+  <link href="vendor/flatdoc/v/0.8.0/theme-white/style.css" rel="stylesheet">
+  <script src="vendor/flatdoc/v/0.8.0/theme-white/script.js"></script>
+
+  <!-- Custom Stylesheets -->
+  <link href="https://fonts.googleapis.com/css?family=Montserrat" rel="stylesheet" type="text/css">
+  <link href="https://fonts.googleapis.com/css?family=Open+Sans:600italic,400,700,300" rel="stylesheet" type="text/css">
+  <link href="css/main.css" rel="stylesheet">
+  <link href="css/custom.css" rel="stylesheet">
+  
+	<link rel="shortcut icon" href="favicon.ico?v=2" type="image/x-icon">
+	<link rel="icon" href="favicon.ico?v=2" type="image/x-icon">
+
+  
+  <!-- start Mixpanel -->
+  <script type="text/javascript">(function(e,b){if(!b.__SV){var a,f,i,g;window.mixpanel=b;a=e.createElement("script");a.type="text/javascript";a.async=!0;a.src=("https:"===e.location.protocol?"https:":"http:")+'//cdn.mxpnl.com/libs/mixpanel-2.2.min.js';f=e.getElementsByTagName("script")[0];f.parentNode.insertBefore(a,f);b._i=[];b.init=function(a,e,d){function f(b,h){var a=h.split(".");2==a.length&&(b=b[a[0]],h=a[1]);b[h]=function(){b.push([h].concat(Array.prototype.slice.call(arguments,0)))}}var c=b;"undefined"!==
+typeof d?c=b[d]=[]:d="mixpanel";c.people=c.people||[];c.toString=function(b){var a="mixpanel";"mixpanel"!==d&&(a+="."+d);b||(a+=" (stub)");return a};c.people.toString=function(){return c.toString(1)+".people (stub)"};i="disable track track_pageview track_links track_forms register register_once alias unregister identify name_tag set_config people.set people.set_once people.increment people.append people.track_charge people.clear_charges people.delete_user".split(" ");for(g=0;g<i.length;g++)f(c,i[g]);
+b._i.push([a,e,d])};b.__SV=1.2}})(document,window.mixpanel||[]);
+mixpanel.init("132d42885e094171f34467fc54da6fab");
+  </script>
+    
+  <script>if (window.location.host == "dev.ripple.com") { mixpanel.track("transactions"); }</script>    
+  <!-- end Mixpanel -->
+
+  <!-- start google analytics -->
+  <script>
+  (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
+  (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
+  m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
+  })(window,document,'script','//www.google-analytics.com/analytics.js','ga');
+
+  ga('create', 'UA-49188512-1', 'ripple.com');
+  ga('send', 'pageview');
+
+  </script>
+  <!-- end google analytics -->  
+    
+
+  
+  <!-- syntax selection js -->
+  <script src="js/multicodetab.js"></script>
+  <!-- Code to load Flatdoc; commented out on compiled page  -->
+  <script>
+    $(".flatdoc-content").empty();
+    $(".content-root .menubar .menu").empty();
+    Flatdoc.run({
+      fetcher: Flatdoc.file('tx_format.md')
+    });
+    $(document).on('flatdoc:ready', $().multicode_tabs);
+  </script>
+  <!-- end flatdoc load -->
+  <!-- Alternate multicode tabs for compiled page: 
+  <script>
+    $(document).ready(function() {
+        $(".multicode").minitabs()
+        make_code_expandable();
+    });
+  </script>
+  <!--end alt code for compiled page -->
+  <link type="text/css" rel="stylesheet" href="css/mod.css">
+  <script src="js/expandcode.js"></script>
+  <script src="js/fixsidebarscroll.js"></script>
+  
+</head>
+<body role='flatdoc' class='no-literate'>
+ 	<div class="navbar navbar-inverse navbar-fixed-top" role="navigation">
+      <div class="container">
+        <div class="navbar-header">
+          <button type="button" class="navbar-toggle" data-toggle="collapse" data-target=".navbar-collapse">
+            <span class="sr-only">Toggle navigation</span>
+            <span class="icon-bar"></span>
+            <span class="icon-bar"></span>
+            <span class="icon-bar"></span>
+          </button>
+          <a class="navbar-brand" href="https://dev.ripple.com/"><img class="small_logo" src="assets/img/ripple_logo_small.png"></a>
+        </div>
+        <div class="navbar-collapse collapse">
+          <ul class="nav navbar-nav">
+			<li class="active"><a href="/">Resources</a></li>
+            <li><a href="https://www.bountysource.com/teams/ripple/bounties">Bounties</a></li>
+            <li><a href="https://ripplelabs.atlassian.net/">Bug Tracking</a></li>
+            <li><a href="https://ripple.com/dev/blog/">Dev Blog</a></li>
+            <li><a href="https://ripple.com/forum/viewforum.php?f=2&sid=c016bc6b934120b7117c0e136e74de98">Forums</a></li>
+            <li class="dropdown">
+              <a href="#" class="dropdown-toggle" data-toggle="dropdown">API Tool <span class="caret"></span></a>
+              <ul class="dropdown-menu" role="menu">
+                <li><a href="ripple-api-tool.html">WebSocket Tool</a></li>
+                <li><a href="rest-api-tool.html">REST Tool</a></li>
+              </ul>
+            </li>
+          </ul>
+          	<div class='right'>
+		 	 <!-- GitHub buttons -->
+		 		 <iframe src="https://dev.ripple.com/vendor/ghbtn.html?user=ripple&repo=ripple-dev-portal&type=watch&count=true" allowtransparency="true" frameborder="0" scrolling="0" width="110" height="20"></iframe>
+			</div>
+        </div><!--/.nav-collapse -->
+      </div>
+    </div>
+<!-- 
+  <div class="header-subnav-wrapper">
+  <div class='header-subnav navbar-fixed-top'>
+    <ul>
+        <li><a href='?p=introduction' id='subnav-intro'>Introduction</a></li>
+        <li><a href='?p=ripple-rest-api' id='subnav-rest'>Ripple-REST API</a></li>
+        <li><a href='?p=web-sockets-api' id='subnav-websocket'>WebSocket &amp; JSON-RPC APIs</a></li>
+    </ul>
+    <div class='clearer'>&nbsp;</div>
+  </div>
+</div>
+ -->
+  <div class='content-root'>
+    <div class='menubar'>
+      <div class='menu section' role='flatdoc-menu'></div>
+    </div>
+    <div role='flatdoc-content' class='content'>
+    	
+	</div>
+  </div>
+<div class="footer">
+      <div class="container">
+        <p class="text-muted">
+        	<div class="row">
+				<div class="col-md-2">
+					
+						<ul class="footer_links applications">
+							<li><a href="https://www.rippletrade.com">Ripple Trade</a>
+							<li><a href="https://www.ripplecharts.com">Ripple Charts</a>
+							<li><a href="https://ripple.com/graph">Ripple Graph</a>
+							<li><a href="http://codius.org/">Codius</a>
+						</ul>
+				</div>
+				<div class="col-md-2">
+					
+						<ul class="footer_links middleware">
+							<li><a href="gatewayd.html">Gatewayd</a>
+							<li><a href="ripple-rest.html">Ripple REST</a>
+							<li><a href="https://github.com/ripple/ripple-lib">Ripple Lib</a>
+						</ul>
+				
+				</div>
+				<div class="col-md-2">
+					
+						<ul class="footer_links core_network">
+							<li><a href="rippled-apis.html">rippled</a>
+							<li><a href="transactions.html">Transactions</a>
+							<li><a href="consensus-whitepaper.html">Consensus</a>
+						</ul>
+				
+				</div>
+				<div class="col-md-2">
+						<ul class="footer_links bounties">
+							<li><a href="https://www.bountysource.com/teams/ripple/bounties">Bounties</a>
+							<li><a href="https://ripplelabs.atlassian.net/">Bug tracking</a>
+							<li><a href="guidelines.html">Brand guidelines</a>
+							<li><a href="https://ripple.com/dev/blog/">Dev blog</a>
+							<li><a href="https://ripple.com/forum/viewforum.php?f=2&sid=c016bc6b934120b7117c0e136e74de98">Forums</a>
+							<li><a href="https://ripple.com/wiki/Main_Page">Wiki</a>
+						</ul>
+				
+				</div>
+				<div class="col-md-4 mail_chimp">
+				<p>Join the mailing list!</p>
+				<label for="mce-EMAIL">Email address</label>
+					<!-- Begin MailChimp Signup Form -->
+						<link href="//cdn-images.mailchimp.com/embedcode/slim-081711.css" rel="stylesheet" type="text/css">
+						<style type="text/css">
+							#mc_embed_signup{clear:left; font:14px; }
+	
+						</style>
+						<div id="mc_embed_signup">
+						<form action="//ripple.us4.list-manage.com/subscribe/post?u=245dbc1c47849f034390dc5bf&amp;id=4dfbe160d0" method="post" id="mc-embedded-subscribe-form" name="mc-embedded-subscribe-form" class="validate" target="_blank" novalidate>
+	
+							<input type="email" value="" name="EMAIL" class="email" id="mce-EMAIL" placeholder="" required>
+							<!-- real people should not fill this in and expect good things - do not remove this or risk form bot signups-->
+							<div style="position: absolute; left: -5000px; top: -50px;"><input type="text" name="b_245dbc1c47849f034390dc5bf_4dfbe160d0" tabindex="-1" value=""></div>
+							<input type="submit" value="Submit" name="subscribe" id="mc-embedded-subscribe" class="button btn btn-primary">
+						</form>
+						</div>
+
+					<!--End mc_embed_signup-->
+				</div>
+      		</div>
+        </p>
+      </div>
+    </div>
+</body>
+</html>
+
--- a/tx_format.md
+++ b/tx_format.md
@@ -2,7 +2,7 @@

 A *Transaction* is the only way to modify the Ripple Ledger. All transactions have certain fields in common:

-* [All Transactions](#all-transactions)
+* [Common Fields](#common-fields)

 There are several different types of transactions that perform different actions, each with additional fields relevant to that type of action:

@@ -15,12 +15,13 @@ There are several different types of transactions that perform different actions

 Additionally, there are *Psuedo-Transactions* that are not created and submitted in the usual way, but may appear in ledgers:

-* [Amendment - Adopt a new feature in the network](#amendment)
 * [Fee - Adjust the minimum transaction fee or account reserve](#fee)

-## Signing Transactions ##
+## Signing and Sending Transactions ##

-Signing a transaction cryptographically proves that the person in charge of the account sending the transaction really means to do so. Only signed transactions can be submitted to the network and included in ledgers.  network, and possibly included in a validated ledger. A signed transaction is immutable: if any of the contents of the transaction change, the signature is not valid.
+Signing a transaction cryptographically proves that the person in charge of the account sending the transaction is authorized to do so. Only signed transactions can be submitted to the network and included in a validated ledger. A signed transaction is immutable: its contents cannot change, and the signature is not valid for any other transaction.
+
+You can sign a transaction using a secret key: either the master secret, or a regular secret if the account has a regular key pair associated with it. (See [SetRegularKey](#setregularkey) for details.)

 Multi-signature transactions are [in development](https://wiki.ripple.com/Multisign).

@@ -31,7 +32,7 @@ Typically, you create a transaction in JSON format first. Here is an example of
  "TransactionType" : "Payment",
  "Account" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
  "Destination" : "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX",
-  "Amount" : { 
+  "Amount" : {
     "currency" : "USD",
     "value" : "1",
     "issuer" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn"
@@ -44,10 +45,10 @@ Typically, you create a transaction in JSON format first. Here is an example of

 After doing that, you generate the signed binary format for the transaction. There are two ways to do this:

-* Convert it to a binary blob and sign it offline. This is preferable, since it means that the account secret used for signing the transaction is never transmitted over any network connection.
-  * [rsign.js](https://github.com/ripple/ripple-lib/blob/develop/bin/rsign.js) is the reference implementation for offline signing. 
-* Have a `rippled` server sign the transaction for you. The [sign command](rippled-apis.html#sign) takes a JSON-format transaction and secret and returns the signed binary transaction format ready for submission. (Transmitting your account secret is dangerous, so you should only do this from within a trusted and encrypted sub-net.)
-  * As a shortcut, you can use the [submit command](rippled-apis.html#submit) with a `tx_json` object to sign and submit a transaction all at once. This is only recommended for testing and development purposes. 
+1. Convert it to a binary blob and sign it offline. This is preferable, since it means that the account secret used for signing the transaction is never transmitted over any network connection.
+  * [rsign.js](https://github.com/ripple/ripple-lib/blob/develop/bin/rsign.js) is a JavaScript implementation of offline signing.
+2. Have a `rippled` server sign the transaction for you. The [sign command](rippled-apis.html#sign) takes a JSON-format transaction and secret and returns the signed binary transaction format ready for submission. (Transmitting your account secret is dangerous, so you should only do this from within a trusted and encrypted sub-net, to a server you control.)
+  * As a shortcut, you can use the [submit command](rippled-apis.html#submit) with a `tx_json` object to sign and submit a transaction all at once. This is only recommended for testing and development purposes.

 In either case, signing a transaction generates a binary blob that can be submitted to the network. This means using `rippled`'s [submit command](rippled-apis.html#submit). Here is an example of the same transaction, as a signed blob, being submitted with the WebSocket API:

@@ -149,77 +150,114 @@ After a transaction has been submitted, if it gets accepted into a validated led
 }
 ```

-*Note:* The `"hash"` value needed to look up the transaction is in the response from the server when you submit the transaction, or you can find the relevant transaction by looking through an account's transaction history with the [account_tx command](rippled-apis.html#account_tx).
+### Identifying Transactions ###

-## All Transactions ##
+The `"hash"` is the unique value that identifies a particular transaction. The server provides the hash in the response when you submit the transaction; you can also look up a transaction in an account's transaction history with the [account_tx command](rippled-apis.html#account_tx).

-Every transaction has a the same set of fundamental properties:
+The transaction hash can be used as a "proof of payment" since anyone can look up the transaction using the hash and verify its final status.
+
+## Common Fields ##
+
+Every transaction type has the same set of fundamental fields:

 | Field | JSON Type | [Internal Type](https://wiki.ripple.com/Binary_Format) | Description |
 |-------|-----------|---------------|-------------|
-| Account | String | Account | The unique address of the account that initiated the transaction |
-| [Fee](#transaction-fees) | String | Amount | (Required, but auto-fillable) Integer amount of XRP, in drops, to be destroyed as a fee for redistributing this transaction to the network. |
-| Flags | Unsigned Integer | UInt32 | (Optional) Set of bit-flags for this transaction |
+| Account | String | Account | The unique address of the account that initiated the transaction. |
+| [AccountTxnID](#accounttxnid) | String | Hash256 | (Optional) Hash value identifying another transaction. This transaction is only valid if the sending account's previous transaction matches the provided hash. |
+| [Fee](#transaction-fees) | String | Amount | (Required, but [auto-fillable](#auto-fillable-fields)) Integer amount of XRP, in drops, to be destroyed as a fee for redistributing this transaction to the network. |
+| [Flags](#flags) | Unsigned Integer | UInt32 | (Optional) Set of bit-flags for this transaction. |
 | [LastLedgerSequence](#lastledgersequence) | Number | UInt32 | (Optional, but strongly recommended) Highest ledger sequence number that a transaction can appear in. |
 | [Memos](#memos) | Array of Objects | Array | (Optional) Additional arbitrary information used to identify this transaction. |
-| [PreviousTxnID](#previoustxnid) | String | Hash256 | (Optional) Hash value identifying a transaction. If the transaction immediately prior this one by sequence number does not match the provided hash, this transaction is considered invalid. |
-| [Sequence](#canceling-or-skipping-a-transaction) | Unsigned Integer | UInt32 | (Required, but auto-fillable) The sequence number, relative to the initiating account, of this transaction. A transaction is only valid if the `Sequence` number is exactly 1 greater than the last-valided transaction from the same account. |
-| SigningPubKey | String | PubKey | (Omitted until signed) Hex representation of the public key that corresponds to the private key used to sign this transaction. |
+| [Sequence](#canceling-or-skipping-a-transaction) | Unsigned Integer | UInt32 | (Required, but [auto-fillable](#auto-fillable-fields)) The sequence number, relative to the initiating account, of this transaction. A transaction is only valid if the `Sequence` number is exactly 1 greater than the last-valided transaction from the same account. |
+| SigningPubKey | String | PubKey | (Automatically added when signing) Hex representation of the public key that corresponds to the private key used to sign this transaction. |
 | SourceTag | Unsigned Integer | UInt32 | (Optional) Arbitrary integer used to identify the reason for this payment, or the hosted wallet on whose behalf this transaction is made. Conventionally, a refund should specify the initial payment's `SourceTag` as the refund payment's `DestinationTag`. |
-| TransactionType | String | UInt16 | The type of transaction. Valid types include: `Payment`, `OfferCreate`, `OfferCancel`, `TrustSet`, and `AccountSet`. |
-| TxnSignature | String | VariableLength | (Omitted until signed) The signature that verifies this transaction as originating from the account it says it is from |
+| TransactionType | String | UInt16 | The type of transaction. Valid types include: `Payment`, `OfferCreate`, `OfferCancel`, `TrustSet`, `AccountSet`, and `SetRegularKey`. |
+| TxnSignature | String | VariableLength | (Automatically added when signing) The signature that verifies this transaction as originating from the account it says it is from. |
+
+The field `PreviousTxnID` is a **DEPRECATED** alias for [AccountTxnID](#accounttxnid). Always use `AccountTxnID` instead.
+
+### Auto-fillable Fields ###
+
+Some fields can be automatically filled in before the transaction is signed, either by a `rippled` server or by the library used for offline signing. Both [ripple-lib](https://github.com/ripple/ripple-lib) and `rippled` can automatically provide the following values:
+
+* `Fee` - Automatically use the current base network fee.
+* `Sequence` - Automatically use the next sequence number for the account sending the transaction.
+
+For a production system, we recommend *not* leaving these fields to be filled by the server. For example if fees become temporarily high, you may want to wait for fees to decrease before sending some transactions, instead of continuing regardless of fee.
+
+The [`Paths` field](#paths) of the [Payment](#payment) transaction type can also be automatically filled in. 

 ### Transaction Fees ###

-The `Fee` field specifies an amount, in drops of XRP, that must be deducted from the sender's balance in order to relay any transaction through the network. This is a measure to protect against spam and DDoS attacks weighing down the whole network. You can specify any amount in the `Fee` field when you create a transaction. If your transaction makes it into a validated leger (whether or not it achieves its intended purpose), then the deducted XRP is destroyed forever.
+The `Fee` field specifies an amount, in [drops of XRP](rippled-apis.html#specifying-currency-amounts), that must be deducted from the sender's balance in order to relay any transaction through the network. This is a measure to protect against spam and DDoS attacks weighing down the whole network. You can specify any amount in the `Fee` field when you create a transaction. If your transaction makes it into a validated leger (whether or not it achieves its intended purpose), then the deducted XRP is destroyed forever.

 Each rippled server decides on the minimum fee to require, which is at least the global base transaction fee, and increases based on the individual server's current load. If a transaction's fee is not high enough, then the server does not relay the transaction to other servers. (*Exception:* If you send a transaction to your own server over an admin connection, it relays the transaction even under high load, so long as the fee meets the global base.)

-Even if some servers have too much load to propagate a transaction, the transaction can still make it into a validated ledger as long as a large enough percentage of validating servers receive it, so the global base fee is generally enough to submit a transaction. If many servers in the network are under high load all at once (for example, due to a DDoS or a global event of some sort) then you must either set the fee higher or wait for the load to decrease. 
+Even if some servers have too much load to propagate a transaction, the transaction can still make it into a validated ledger as long as a large enough percentage of validating servers receive it, so the global base fee is generally enough to submit a transaction. If many servers in the network are under high load all at once (for example, due to a DDoS or a global event of some sort) then you must either set the fee higher or wait for the load to decrease.

 For more information, see the [Transaction Fee wiki article](https://wiki.ripple.com/Transaction_Fee).

 ### Canceling or Skipping a Transaction ###

-An important and intentional feature of the Ripple Network is that a transaction is final as soon as it has been incorporated in a validated ledger. 
+An important and intentional feature of the Ripple Network is that a transaction is final as soon as it has been incorporated in a validated ledger.

-However, if a transaction has not yet been included in a validated ledger, you can effectively cancel it by rendering it invalid. Typically, this means sending another transaction with the same `Sequence` value from the same account. If you do not want to perform the same transaction again, you can perform an [AccountSet](#accountset) transaction with no options. 
+However, if a transaction has not yet been included in a validated ledger, you can effectively cancel it by rendering it invalid. Typically, this means sending another transaction with the same `Sequence` value from the same account. If you do not want to perform the same transaction again, you can perform an [AccountSet](#accountset) transaction with no options.

 For example, if you attempted to submit 3 transactions with sequence numbers 11, 12, and 13, but transaction 11 gets lost somehow or does not have a high enough [transaction fee](#transaction-fees) to be propagated to the network, then you can cancel transaction 11 by submitting an AccountSet transaction with no options and sequence number 11. This does nothing (except destroying the transaction fee for the new transaction 11), but it allows transactions 12 and 13 to become valid.

 This approach is preferable to renumbering and resubmitting transactions 12 and 13, because it prevents transactions from being effectively duplicated under different sequence numbers.

-In this way, an AccountSet transaction with no options is the canonical "no-op" transaction.
+In this way, an AccountSet transaction with no options is the canonical "[no-op](http://en.wikipedia.org/wiki/NOP)" transaction.

 ### LastLedgerSequence ###

-We strongly recommend that you specify the `LastLedgerSequence` parameter on every transaction. Provide a value of about 3 higher than [the most recent ledger index](rippled-apis.html#ledger) to ensure that your transaction is either validated or rejected within a matter of seconds. 
+We strongly recommend that you specify the `LastLedgerSequence` parameter on every transaction. Provide a value of about 3 higher than [the most recent ledger index](rippled-apis.html#ledger) to ensure that your transaction is either validated or rejected within a matter of seconds.

 Without the `LastLedgerSequence` parameter, there is a particular situation that can occur and cause your transaction to be stuck in an undesirable state where it is neither validated nor rejected for a long time. Specifically, if the global base [transaction fee](#transaction-fees) increases after you send a transaction, your transaction may not get propagated enough to be included in a validated ledger, but you would have to pay the (increased) fee in order to send another transaction canceling it. Later, if the transaction fee decreases again, the transaction may become viable again. The `LastLedgerSequence` places a hard upper limit on how long the transaction can wait to be validated or rejected.

-### PreviousTxnID ###
+### AccountTxnID ###

-The `PreviousTxnID` field lets you chain your transactions together, so that a current transaction is not valid unless the previous one is also valid and matches the transaction you expected.
+The `AccountTxnID` field lets you chain your transactions together, so that a current transaction is not valid unless the previous one (by Sequence Number) is also valid and matches the transaction you expected.

-One situation in which this is useful is if you have a primary system for submitting transactions and a passive backup system. If the passive backup system becomes disconnected from the primary, but the primary is not fully dead, and they both begin operating at the same time, you could potentially encounter serious problems like some transactions sending twice and others not at all. Chaining your transactions together with `PreviousTxnID` ensures that, even if both systems are active, only one of them can submit valid transactions at a time.
+One situation in which this is useful is if you have a primary system for submitting transactions and a passive backup system. If the passive backup system becomes disconnected from the primary, but the primary is not fully dead, and they both begin operating at the same time, you could potentially encounter serious problems like some transactions sending twice and others not at all. Chaining your transactions together with `AccountTxnID` ensures that, even if both systems are active, only one of them can submit valid transactions at a time.

-In order to use PreviousTxnID, you must first set the [asfAccountTxnID](#accountset-flags) flag, so that the ledger keeps track of the ID for the account's previous transaction.
+In order to use AccountTxnID, you must first set the [asfAccountTxnID](#accountset-flags) flag, so that the ledger keeps track of the ID for the account's previous transaction.

 ### Memos ###

-The Memos field allows for arbitrary messaging data that can accompany the transaction. It is presented as an array of objects, where each object has the following fields:
+The Memos field allows for arbitrary messaging data that can accompany the transaction. It is presented as an array of objects. Each object has only one field, `Memo`, which in turn contains another object with *one or more* of the following fields:

-| Field | Type | Description |
-|-------|------|-------------|
-| MemoType | String | Arbitrary descriptor of the memo's format. We recommend using MIME types. |
-| MemoData | (Variable) | Any data representing the memo's content. |
-| (...) | (Variable) | Arbitrary additional fields such as `Account`, `RegularKey`, etc. that can be used to support features such as encryption. |
+| Field | Type | [Internal Type](https://wiki.ripple.com/Binary_Format) | Description |
+|-------|------|--------------------------------------------------------|-------------|
+| MemoType | String | VariableLength | Arbitrary hex value; conventionally should be ASCII for a unique relation (according to [RFC 5988](http://tools.ietf.org/html/rfc5988#section-4)) that defines the format of this memo. |
+| MemoData | String | VariableLength | Arbitrary hex value, conventionally containing the content of the memo. |
+| MemoFormat | String | VariableLength | Arbitrary hex value, conventionally containing information on how the memo is encoded, for example as a [MIME type](http://www.iana.org/assignments/media-types/media-types.xhtml) |
+
+The `Memos` field is currently limited to no more than 1KB in size (when serialized in binary format).
+
+Example of a transaction with a Memos field:
+
+```
+{
+    "TransactionType": "Payment",
+    "Account": "rMmTCjGFRWPz8S2zAUUoNVSQHxtRQD4eCx",
+    "Destination": "r3kmLJN5D28dHuH8vZNUZpMC43pEHpaocV",
+    "Memos": [
+        {
+            "Memo": {
+                "MemoType": "5061796d656e7420726561736f6e",
+                "MemoData": "72656e74"
+            }
+        }
+    ],
+    "Amount": "1"
+}
+```

-The memos field is currently limited to no more than 1KB in size.

 ### Flags ###

-The Flags field allows for additional boolean options regarding the behavior of a transaction. They are represented as binary values that can be bitwise-or added to set multiple flags at once.
+The Flags field allows for additional boolean options regarding the behavior of a transaction. They are represented as binary values that can be combined with bitwise-or operations to set multiple flags at once.

 Most flags only have meaning for a specific transaction type. The same bitwise value may be reused for flags on different transaction types, so it is important to pay attention to the `TransactionType` field when setting and reading flags.

@@ -232,9 +270,12 @@ The only flag that applies globally to all transactions is as follows:


 ## Payment ##
+[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/module/app/transactors/Payment.cpp "Source")

 A Payment transaction represents a transfer of value from one account to another. (Depending on the path taken, additional exchanges of value may occur atomically to facilitate the payment.)

+Payments are also the only way to [create accounts](#creating-accounts).
+
 Example payment:

 ```
@@ -242,7 +283,7 @@ Example payment:
  "TransactionType" : "Payment",
  "Account" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
  "Destination" : "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX",
-  "Amount" : { 
+  "Amount" : {
     "currency" : "USD",
     "value" : "1",
     "issuer" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn"
@@ -254,21 +295,35 @@ Example payment:
 ```

 | Field | JSON Type | [Internal Type](https://wiki.ripple.com/Binary_Format) | Description |
-|-------|-----------|---------------|-------------|
-| Amount | String (XRP)<br/>Object (Otherwise) | Amount | The amount of currency sent as part of this transaction. (See [Specifying Currency Amounts](rippled-apis.html#specifying-currency-amounts)) |
+|-------|-----------|--------------------------------------------------------|-------------|
+| Amount | String (XRP)<br/>Object (Otherwise) | Amount | The amount of currency to deliver. *Note:* If the [*tfPartialPayment* flag](#payment-flags) is set, this is not the amount actually received. (Formatted as per [Specifying Currency Amounts](rippled-apis.html#specifying-currency-amounts).) |
 | Destination | String | Account | The unique address of the account receiving the payment. |
 | DestinationTag | Unsigned Integer | UInt32 | (Optional) Arbitrary tag that identifies the reason for the payment to the destination, or the hosted wallet to make a payment to. |
 | InvoiceID | String | Hash256 | (Optional) Arbitrary 256-bit hash representing a specific reason or identifier for this payment. |
-| Paths | Array of path arrays | PathSet | (Optional, but recommended) Array of [payment paths](https://ripple.com/wiki/Payment_paths) to be used for this transaction. If omitted, the paths are chosen by the server. |
-| SendMax | String/Object | Amount | Highest amount of currency this transaction is allowed to cost; this is to compensate for [slippage](http://en.wikipedia.org/wiki/Slippage_%28finance%29). (See [Specifying Currency Amounts](rippled-apis.html#specifying-currency-amounts)) |
+| Paths | Array of path arrays | PathSet | (Optional, auto-fillable) Array of [payment paths](https://ripple.com/wiki/Payment_paths) to be used for this transaction. Must be omitted for XRP-to-XRP transactions. |
+| SendMax | String/Object | Amount | (Optional) Highest amount of source currency this transaction is allowed to cost, including fees, exchanges, and [slippage](http://en.wikipedia.org/wiki/Slippage_%28finance%29). (See [Specifying Currency Amounts](rippled-apis.html#specifying-currency-amounts)) Must be supplied for cross-currency/cross-issue payments (implies source balance). Must be omitted for XRP-to-XRP payments.|
+
+### Creating Accounts ###
+
+The Payment transaction type is the only way to create new accounts in the shared Ripple ledger. To do so, send an amount of XRP that is equal or greater than the [account reserve](https://wiki.ripple.com/Reserves) to a mathematically-valid account address that does not exist yet. When the payment is processed, a new [AccountRoot node](https://wiki.ripple.com/Ledger_Format#AccountRoot) will be added to the ledger to reflect the newly-created account.
+
+If you attempt to send an insufficient amount of XRP, or any other currency, the Payment will fail.

 ### Paths ###

-The `Paths` field is a set of different paths along which the payment can be made. A single transaction can potentially follow multiple paths, for example if the transaction exchanges currency using several different offers in order to achieve the best rate. The source and destination (that is, the endpoints of the path) are omitted from the path array because they are part of the transaction definition.
+The `Paths` field is a set of different paths along which the payment can be made. A single transaction can potentially follow multiple paths, for example if the transaction exchanges currency using several different offers in order to achieve the best rate. The source and destination (that is, the endpoints of the path) are omitted from a path. You can get suggestions of paths from rippled servers using the [`path_find`](#path-find) or [`ripple_path_find`](#ripple-path-find) commands. 

-You can get suggestions of paths from rippled servers using the [`path_find`](#path-find) or [`ripple_path_find`](#ripple-path-find) commands. We recommend always including looking up the paths and including them as part of the transaction, because there are no guarantees on how expensive the paths the server finds will be at the time of submission. (Although `rippled` is designed to search for the cheapest paths possible, it may not always find them. Untrustworthy `rippled` instances could also be modified to change this behavior for profit.)
+If the `Paths` field is provided, the server decides at transaction processing time which paths to use out of the provided set. This decision is deterministic and attempts to minimize costs, but it is not guaranteed to be perfect.
+
+If the `Paths` field is omitted, by definition the payment should take a direct path connecting the source and destination accounts. A direct path could be:
+
+* An XRP-to-XRP transfer.
+* A payment along a single trust line that connects the two accounts in the currency being transferred.
+
+The `Paths` field must not be an empty array, nor an array whose members are all empty arrays.
+
+The `Paths` field can be automatically filled in when the transaction is signed, if the `build_path` field is provided to the [sign](rippled-apis.html#sign) or [submit](rippled-apis.html#submit) commands. However, we recommend pathfinding separately and confirming the results prior to signing, in order to avoid surprises. There are no guarantees on how expensive the paths the server finds will be at the time of submission. (Although `rippled` is designed to search for the cheapest paths possible, it may not always find them. Untrustworthy `rippled` instances could also be modified to change this behavior for profit.)

-An empty `Paths` array indicates a direct transfer: either because the sending and receiving accounts are directly linked by a trust line in the currency being transferred, or because the transaction is sending XRP.

 ### Payment Flags ###

@@ -277,13 +332,29 @@ Transactions of the Payment type support additional values in the [`Flags` field
 | Flag Name | Hex Value | Decimal Value | Description |
 |-----------|-----------|---------------|-------------|
 | tfNoDirectRipple | 0x00010000 | 65536 | Do not use a direct path, if available. This is intended to force the transaction to take arbitrage opportunities. Most clients will not need this. |
-| tfPartialPayment | 0x00020000 | 131072 | Instead of deducting transfer and exchange fees from the sending account's balance, reduce the received amount by the fee amounts. This is useful for refunding payments. Note, the transaction fee is still subtracted from the sender's account. |
+| tfPartialPayment | 0x00020000 | 131072 | Instead of deducting transfer and exchange fees from the sending account's balance, reduce the received amount by the fee amounts. See [Partial Payments](#partial-payments) for more details. |
+
+### Partial Payments ###
+
+A partial payment subtracts fees from the amount received instead of adding to the amount sent. Partial payments are useful for [returning payments](https://wiki.ripple.com/Returning_payments) without incurring additional costs to oneself.
+
+By default, the `Amount` field of a Payment transaction specifies the amount of currency that is *received* by the account that is the destination of the payment. Any additional amount needed for fees or currency exchange is deducted from the sending account, up to the `SendMax` amount. (If `SendMax` is not specified, and fees are necessary to make the transaction the transaction fails.)
+
+The [*tfPartialPayment* flag](#payment-flags) allows you to make a "partial payment" instead. When this flag is enabled for a transaction, the costs of transaction fees and exchanging currencies are deducted from the amount sent instead of from the sender's balance. Consequently, the `Amount` field __*is not guaranteed to be the amount received*__. In fact, __*there is no minimum guaranteed amount*__ that a partial payment actually delivers.
+
+Validated partial payment transactions have a `meta.DeliveredAmount` field, which indicates the amount of currency actually received by the destination account. *Note:* Early partial payments in historical ledgers do not have this field.
+
+A partial payment cannot provide the initial XRP to fund an account; this case returns the error code telNO_DST_PARTIAL. Direct XRP-to-XRP payments also cannot be partial payments temBAD_SEND_XRP_PARTIAL.
+
+*Note:* The amount of XRP used for the [transaction fee](#transaction-fee) is always deducted from the sender's account, regardless of the *tfPartialPayment* flag.



 ## AccountSet ##

-An AccountSet transaction modifies the properties of an account object in the global ledger.
+[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/module/app/transactors/SetAccount.cpp "Source")
+
+An AccountSet transaction modifies the properties of an [account in the global ledger]((https://wiki.ripple.com/Ledger_Format#AccountRoot).

 Example AccountSet:

@@ -301,12 +372,12 @@ Example AccountSet:
 ```

 | Field | JSON Type | [Internal Type](https://wiki.ripple.com/Binary_Format) | Description |
-|-------|-----------|---------------|-------------|
+|-------|-----------|--------------------------------------------------------|-------------|
 | [ClearFlag](#accountset-flags) | Unsigned Integer | UInt32 | (Optional) Unique identifier of a flag to disable for this account. |
 | [Domain](#domain) | String | VariableLength | (Optional) The domain that owns this account, as a string of hex representing the ASCII for the domain in lowercase. |
 | EmailHash | String | Hash128 | (Optional) Hash of an email address to be used for generating an avatar image. Conventionally, clients use [Gravatar](http://en.gravatar.com/site/implement/hash/) to display this image. |
-| MessageKey | String | PubKey | (Optional) Public key for sending encrypted messages to this account. Conventionally, it should be a secp256k1 key, the same encryption that is used by the rest of Ripple |
-| [SetFlag](#accountset-flags) | Unsigned Integer | UInt32 | (Optional) Unique identifier of a flag to enable for this account. |
+| MessageKey | String | PubKey | (Optional) Public key for sending encrypted messages to this account. Conventionally, it should be a secp256k1 key, the same encryption that is used by the rest of Ripple. |
+| [SetFlag](#accountset-flags) | Unsigned Integer | UInt32 | (Optional) Integer flag to enable for this account. |
 | [TransferRate](#transferrate) | Unsigned Integer | UInt32 | (Optional) The fee to charge when users transfer this account's issuances, represented as billionths of a unit. Use `0` to set no fee. |
 | WalletLocator | String | Hash256 | (Optional) Not used. |
 | WalletSize | Unsigned Integer | UInt32 | (Optional) Not used. |
@@ -317,14 +388,16 @@ If none of these options are provided, then the AccountSet transaction has no ef

 The `Domain` field is represented as the hex string of the lowercase ASCII of the domain. For example, the domain *example.com* would be represented as `"6578616d706c652e636f6d"`.

-Client applications can use the [ripple.txt](https://ripple.com/wiki/Ripple.txt) file hosted by the domain to confirm that the account is actually operated by that domain.
+To remove the `Domain` field from an account, send an AccountSet with the Domain set to an empty string.
+
+Client applications can use the [ripple.txt](https://ripple.com/wiki/Ripple.txt) file hosted by the domain to confirm that the account is actually operated by that domain. *Note:* We expect the *host-meta* component of [Gateway Services](https://wiki.ripple.com/Gateway_Services) to replace ripple.txt for this purpose.

 ### AccountSet Flags ###

-There are several options which can be either enabled or disabled for an account. Account Options are represented by different types of flags depending on the situation:
+There are several options which can be either enabled or disabled for an account. Account options are represented by different types of flags depending on the situation:

 * The `AccountSet` transaction type has several "AccountSet Flags" (prefixed *asf*) that can enable an option when passed as the `SetFlag` parameter, or disable an option when passed as the `ClearFlag` parameter.
-* The `AccountSet` transaction type has several **DEPRECATED** transaction flags (prefixed *tf*) that can be used to enable or disable specific account options when passed in the `Flags` parameter. This style is deprecated, and new account options will not have new corresponding transaction flags.
+* The `AccountSet` transaction type has several transaction flags (prefixed *tf*) that can be used to enable or disable specific account options when passed in the `Flags` parameter. This style is discouraged, and new account options will not have new corresponding transaction flags.
 * The `AccountRoot` ledger node type has several ledger-specific-flags (prefixed *lsf*) which represent the state of particular account options within a particular ledger. Naturally, the values apply until a later ledger version changes them.

 The preferred way to enable and disable Account Flags is using the `SetFlag` and `ClearFlag` parameters of an AccountSet transaction. AccountSet flags have names that begin with *asf*.
@@ -336,14 +409,25 @@ The available AccountSet flags are:
 | Flag Name | Decimal Value | Description | Corresponding Ledger Flag |
 |-----------|---------------|-------------|---------------------------|
 | asfRequireDest | 1 | Require a destination tag to send transactions to this account. | lsfRequireDestTag |
-| asfRequireAuth | 2 | Require authorization for users to extend trust to this account. (This prevents users unknown to a gateway from holding funds issued by that gateway.) | lsfRequireAuth |
+| asfRequireAuth | 2 | Require authorization for users to hold balances issued by this account. (This prevents users unknown to a gateway from holding funds issued by that gateway.) | lsfRequireAuth |
 | asfDisallowXRP | 3 | XRP should not be sent to this account. (Enforced by client applications, not by `rippled`) | lsfDisallowXRP |
 | asfDisableMaster | 4 | Disallow use of the master key. Can only be enabled if the account has a [RegularKey](#setregularkey) configured. | lsfDisableMaster |
-| asfAccountTxnID | 5 | Track the ID of this account's most recent transaction. Required for [PreviousTxnID](#previoustxnid) | (None) |
+| asfAccountTxnID | 5 | Track the ID of this account's most recent transaction. Required for [AccountTxnID](#accounttxnid) | (None) |
 | asfNoFreeze | 6 | Permanently give up the ability to freeze individual trust lines. This flag can never be cleared. | lsfNoFreeze |
-| asfGlobalFreeze | 7 | Freeze/Unfreeze all assets issued by this account | lsfGlobalFreeze |
+| asfGlobalFreeze | 7 | Freeze all assets issued by this account. | lsfGlobalFreeze |
+
+The following [Transaction flags](#flags), specific to the AccountSet transaction type, serve the same purpose, but are discouraged:
+
+| Flag Name | Hex Value | Decimal Value | Replaced by AccountSet Flag |
+|-----------|-----------|---------------|-----------------------------|
+| tfRequireDestTag | 0x00010000 | 65536 | asfRequireDest (SetFlag) |
+| tfOptionalDestTag | 0x00020000 | 131072 | asfRequireDest (ClearFlag) |
+| tfRequireAuth | 0x00040000 | 262144 | asfRequireAuth (SetFlag) |
+| tfOptionalAuth | 0x00080000 | 524288 | asfRequireAuth (ClearFlag) |
+| tfDisallowXRP | 0x00100000 | 1048576 | asfDisallowXRP (SetFlag) |
+| tfAllowXRP | 0x00200000 | 2097152 | asfDisallowXRP (ClearFlag) |
+

-The following [Transaction flags](#flags), specific to the AccountSet transaction type, are **DEPRECATED**: *tfRequireDestTag*, *tfOptionalDestTag*, *tfRequireAuth*, *tfOptionalAuth*, *tfDisallowXRP*, *tfAllowXRP*.

 #### Blocking Incoming Transactions ####

@@ -351,7 +435,7 @@ Incoming transactions with unclear purposes may be an inconvenience for some gat

 For example, a destination tag is typically used to identify which hosted balance should be credited when the gateway receives a payment. If the destination tag is omitted, it may be unclear which account should be credited, creating a need for refunds, among other problems. By using the `asfRequireDest` tag, the gateway (or any account) can ensure that every incoming payment has a destination tag, which makes it harder to send an ambiguous payment by accident.

-Accounts can protect against unwanted incoming payments for non-XRP currencies simply by not creating trust lines in those currencies. Since XRP does not require trust, the `asfDisallowXRP` flag is used to discourage users from sending XRP to an account. However, this flag is not enforced in `rippled` because it could potentially cause accounts to become unusable. (If an account did not have enough XRP to meet the reserve and make a transaction that disabled the flag, the account would never be able to send another transaction.) Instead, client applications should disallow or discourage XRP payments to accounts with the `asfDisallowXRP` flag enabled.
+Accounts can protect against unwanted incoming payments for non-XRP currencies simply by not creating trust lines in those currencies. Since XRP does not require trust, the `asfDisallowXRP` flag is used to discourage users from sending XRP to an account. However, this flag is not enforced in `rippled` because it could potentially cause accounts to become unusable. (If an account did not have enough XRP to send a transaction that disabled the flag, the account would be completely unusable.) Instead, client applications should disallow or discourage XRP payments to accounts with the `asfDisallowXRP` flag enabled.

 ### TransferRate ###

@@ -367,59 +451,98 @@ For example, if HighFeeGateway issues USD and sets the `TransferRate` to 1200000

 A SetRegularKey transaction changes the regular key used by the account to sign future transactions.

+```
+{
+    "Flags": 0,
+    "TransactionType": "SetRegularKey",
+    "Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
+    "Fee": "12",
+    "RegularKey": "rAR8rR8sUkBoCZFawhkWzY4Y5YoyuznwD"
+}
+```
+
 | Field | JSON Type | [Internal Type](https://wiki.ripple.com/Binary_Format) | Description |
-|-------|-----------|---------------|-------------|
-| RegularKey | String | PubKey | <span class='draft-comment'>(Optional?)</span> Public key of a new keypair to use as the regular key to this account, as a base-58-encoded string; or the value `0` to remove the existing regular key. |
+|-------|-----------|--------------------------------------------------------|-------------|
+| RegularKey | String | Account | (Optional) The public key of a new keypair, to use as the regular key to this account, as a base-58-encoded string in the same format as an account address. If omitted, removes the existing regular key. |

-Instead of using an account's master key to sign transactions, you can set an alternate key pair, called the "Regular Key". As long as the public key for this key pair is set in the `RegularKey` field of an account this way, then the secret of the Regular Key pair can be used to sign transactions. (The master secret can still be used, too.) 
+Instead of using an account's master key to sign transactions, you can set an alternate key pair, called the "Regular Key". As long as the public key for this key pair is set in the `RegularKey` field of an account this way, then the secret of the Regular Key pair can be used to sign transactions. (The master secret can still be used, too, unless you set the [asfDisableMaster account flag](#accountset-flags).)

-A Regular Key pair can be changed, but a Master Key pair is an intrinsic part of the account's identity (the address is derived from the master public key) so the Master Key cannot be changed. Therefore, using a Regular Key whenever possible is beneficial to security.
+A Regular Key pair is generated in the same way as any other Ripple keys (for example, with [wallet_propose](rippled-apis.html#wallet-propose)), but it can be changed. A Master Key pair is an intrinsic part of the account's identity (the address is derived from the master public key) so the Master Key cannot be changed. Therefore, using a Regular Key to sign transactions instead of the master key whenever possible is beneficial to security.

-When the Regular Key is compromised, you can use the this transaction type to change it. As a special feature, each account is allowed to perform SetRegularKey transaction *without* a transaction fee exactly one time ever. To do so, submit a SetRegularKey transaction with a `Fee` value of 0, signed by the account's master key. (This way, you can potentially take back your account even if an attacker has already used up all the account's spare XRP.) <span class='draft-comment'>(Note: confirm that this is still exactly how that works.)</span>
+If your regular key is compromised, but the master key is not, you can use this method to regain control of your account. As a special feature, each account is allowed to perform SetRegularKey transaction *without* a transaction fee as long as the [*lsfPasswordSpent* flag](https://wiki.ripple.com/Ledger_Format#AccountRoot) for the account is not set. To use this feature, submit a SetRegularKey transaction with a `Fee` value of 0, signed by the account's *master key*. (This way, you don't have to worry about whether the attacker has used up all the account's spare XRP.) The [*lsfPasswordSpent* flag]() is automatically cleared if your account receives a payment of XRP.



 ## OfferCreate ##

-An OfferCreate transaction is effectively a [limit order](http://en.wikipedia.org/wiki/limit_order). It defines an intent to exchange currencies, and typically creates an Offer node in the global ledger. Offers can be partially fulfilled.
+[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/module/app/transactors/CreateOffer.cpp "Source")
+
+An OfferCreate transaction is effectively a [limit order](http://en.wikipedia.org/wiki/limit_order). It defines an intent to exchange currencies, and creates an Offer node in the global ledger if not completely fulfilled when placed. Offers can be partially fulfilled.
+
+```
+{
+    "TransactionType": "OfferCreate",
+    "Account": "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX",
+    "Fee": "12",
+    "Flags": 0,
+    "LastLedgerSequence": 7108682,
+    "Sequence": 8,
+    "TakerGets": "6000000",
+    "TakerPays": {
+      "currency": "GKO",
+      "issuer": "ruazs5h1qEsqpke88pcqnaseXdm6od2xc",
+      "value": "2"
+    }
+}
+```

 | Field | JSON Type | [Internal Type](https://wiki.ripple.com/Binary_Format) | Description |
-|-------|-----------|---------------|-------------|
-| [Expiration](#expiration) | Unsigned Integer | UInt32 | (Optional) Time after which the offer is no longer active, in seconds since the Ripple Epoch. |
-| OfferSequence | Unsigned Integer | UInt32 | (Optional) The sequence number of a previous OfferCreate transaction. If specified, cancel any offer node in the ledger that was created by that transaction. |
+|-------|-----------|--------------------------------------------------------|-------------|
+| [Expiration](#expiration) | Unsigned Integer | UInt32 | (Optional) Time after which the offer is no longer active, in [seconds since the Ripple Epoch](rippled-apis.html#specifying-time). |
+| OfferSequence | Unsigned Integer | UInt32 | (Optional) The sequence number of a previous OfferCreate transaction. If specified, cancel any offer node in the ledger that was created by that transaction. It is not considered an error if the offer specified does not exist. |
 | TakerGets | Object (Non-XRP), or <br/>String (XRP) | Amount | The amount and type of currency being provided by the offer creator. |
 | TakerPays | Object (Non-XRP), or <br/>String (XRP) | Amount | The amount and type of currency being requested by the offer creator. |

 ### Lifecycle of an Offer ###

-When an OfferCreate transaction is processed, it automatically consumes matching offers to the extent possible. (These matching offers may even provide a better exchange rate than specified in the offer; if so, the offer creator could pay less than the full `TakerGets` amount in order to receive the entire `TakerPays` amount.) If that does not completely fulfill the `TakerPays` amount, then the offer becomes a passive offer node in the ledger. (You can use [OfferCreate Flags](#offercreate-flags) to modify this behavior.)
+When an OfferCreate transaction is processed, it automatically consumes matching or crossing offers to the extent possible. (If existing offers provide a better rate than requested, the offer creator could pay less than the full `TakerGets` amount in order to receive the entire `TakerPays` amount.) If that does not completely fulfill the `TakerPays` amount, then the offer becomes an Offer node in the ledger. (You can use [OfferCreate Flags](#offercreate-flags) to modify this behavior.)

 An offer in the ledger can be fulfilled either by additional OfferCreate transactions that match up with the existing offers, or by [Payments](#payment) that use the offer to connect the payment path. Offers can be partially fulfilled and partially funded.

-<span class='draft-comment'>Offer fulfillment ignores trust limits and creates a trust lines with a zero limit as necessary. If an insufficient reserve from the offer maker is available to create the line, the offer is considered unfunded. (Explanation needed)</span>
+You can create an Offer so long as you have at least some (any positive, nonzero amount) of the currency specified by the `TakerGets` parameter of the offer. Any amount of that currency you have, up to the `TakerGets` amount, will be sold until the `TakerPays` amount is satisfied. An offer cannot place anyone in debt.

-You can create an Offer so long as you have at least some <span class='draft-comment'>(details needed)</span> of the currency specified by the `TakerGets` parameter of the offer. Any amount of that currency you have, up to the `TakerGets` amount, will be sold until the `TakerPays` amount is satisfied. An offer cannot place anyone in debt.
+It is possible for an offer to become temporarily or permanently *unfunded*:

-It is possible for an offer to become temporarily *unfunded*:
-
-* The creator no longer has any of the `TakerGets` currency.
-  * The offer will become funded again when the creator obtains more of that currency.
+* If the creator no longer has any of the `TakerGets` currency.
+  * The offer becomes funded again when the creator obtains more of that currency.
 * If the currency required to fund the offer is held in a [frozen trust line](https://wiki.ripple.com/Freeze).
-  * The offer will become funded again when the trust line is no longer frozen.
+  * The offer becomes funded again when the trust line is no longer frozen.
+* If the creator does not have enough XRP for the reserve amount of a new trust line required by the offer. (See [Offers and Trust](#offers-and-trust).)
+  * The offer becomes funded again when the creator obtains more XRP, or the reserve requirements decrease.
+* If the Expiration time included in the offer is later than the close time of the most recently-closed ledger. (See [Expiration](#expiration).)

-An offer becomes *permanently* inactive when any of the following happen:
+An unfunded transaction can remain on the ledger indefinitely, but it does not have any effect. The only ways an offer can be *permanently* removed from the ledger are:

 * It becomes fully claimed by a Payment or a matching OfferCreate transaction.
-* The Expiration date included in the offer is prior to the most recently-closed ledger. (See [Expiration](#expiration).)
 * A subsequent OfferCancel or OfferCreate transaction explicitly cancels the offer.
-* <span class='draft-comment'>The creator of the offer places a new offer that crosses it (categorically? or just if the two offers cancel out? Does tfPassive matter?)</span>
-* <span class='draft-comment'>Unfunded offers are deleted when encountered during transaction processing. (Even if they might become funded later?)</span>
+* A subsequent OfferCreate from the same account crosses the earlier offer. (In this case, the older offer is automatically canceled.)
+* An offer is found to be unfunded during transaction processing, typically because it was at the tip of the orderbook.
+  * This includes cases where one side or the other of an offer is found to be closer to 0 than `rippled`'s precision supports.
+* *Note:* there is a bug that can cause offers to be removed incorrectly in rare circumstances. (See [RIPD-456](https://ripplelabs.atlassian.net/browse/RIPD-456) for status.)
+
+### Offers and Trust ###
+
+The limit values of trust lines (See [TrustSet](#trustset)) do not affect offers. In other words, you can use an offer to acquire more than the maximum amount you trust an issuing gateway to redeem.
+
+However, possessing non-XRP balances still requires a trust line to the account issuing those balances. When an offer is taken, it automatically creates any necessary trust lines, setting their limits to 0. Because [trust lines increase the reserve an account must hold](https://wiki.ripple.com/Reserves), any offers that would require a new trust line also require the account to have the necessary XRP to pay the reserve for that trust line.
+
+A trust line indicates an issuer you trust enough to accept their issuances as payment, within limits. Offers are explicit instructions to acquire certain issuances, so they are allowed to go beyond those limits.

 ### Offer Preference ###

 Existing offers are grouped by "quality", which is measured as the ratio between `TakerGets` and `TakerPays`. Offers with a higher quality are taken preferentially. (That is, the person accepting the offer receives as much as possible for the amount of currency they pay out.) Offers with the same quality are taken on the basis of which offer was placed in the earliest ledger version.

-When offers of the same quality are placed in the same ledger version, the "canonical order" of the transactions, as agreed by consensus, determines which is taken first. <span class='draft-comment'>(Confirm what determines canonical order. This behavior has to be well-defined so that independent servers can remain in sync.)</span>
+When offers of the same quality are placed in the same ledger version, the order in which they are taken is determined by the [canonical order](https://github.com/ripple/rippled/blob/f65cea66ef99b1de149c02c15f06de6c61abf360/src/ripple/app/misc/CanonicalTXSet.cpp "Source: Transaction ordering") in which the transactions were [applied to the ledger](https://github.com/ripple/rippled/blob/develop/src/ripple/app/consensus/LedgerConsensus.cpp#L1404-L1507 "Source: Applying transactions"). This behavior is designed to be deterministic, efficient, and hard to game.

 ### Expiration ###

@@ -435,19 +558,35 @@ Transactions of the OfferCreate type support additional values in the [`Flags` f

 | Flag Name | Hex Value | Decimal Value | Description |
 |-----------|-----------|---------------|-------------|
-| tfPassive | 0x00010000 | 65536 | If enabled, the offer will go straight to being a node in the ledger, without trying to consume matching offers first. |
+| tfPassive | 0x00010000 | 65536 | If enabled, the offer will not consume offers that exactly match it, and instead becomes an Offer node in the ledger. It will still consume offers that cross it. |
 | tfImmediateOrCancel | 0x00020000 | 131072 | Treat the offer as an [Immediate or Cancel order](http://en.wikipedia.org/wiki/Immediate_or_cancel). If enabled, the offer will never become a ledger node: it only attempts to match existing offers in the ledger. |
 | tfFillOrKill | 0x00040000 | 262144 | Treat the offer as a [Fill or Kill order](http://en.wikipedia.org/wiki/Fill_or_kill). Only attempt to match existing offers in the ledger, and only do so if the entire `TakerPays` quantity can be obtained. |
 | tfSell | 0x00080000 | 524288 | Exchange the entire `TakerGets` amount, even if it means obtaining more than the `TakerPays` amount in exchange. |

-<span class='draft-comment'>(Some combinations of these are disallowed, right? For example, tfPassive vs. tfImmediateOrCancel seem mutually exclusive.)</span>
+The following invalid flag combination prompts a temINVALID_FLAG error:
+
+* tfImmediateOrCancel and tfFillOrKill

 ## OfferCancel ##

+[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/module/app/transactors/CancelOffer.cpp "Source")
+
 An OfferCancel transaction removes an Offer node from the global ledger.

+```
+{
+    "TransactionType": "OfferCancel",
+    "Account": "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX",
+    "Fee": "12",
+    "Flags": 0,
+    "LastLedgerSequence": 7108629,
+    "OfferSequence": 6,
+    "Sequence": 7
+}
+```
+
 | Field | JSON Type | [Internal Type](https://wiki.ripple.com/Binary_Format) | Description |
-|-------|-----------|---------------|-------------|
+|-------|-----------|--------------------------------------------------------|-------------|
 | OfferSequence | Unsigned Integer | UInt32 | The sequence number of the offer to cancel. |

 *Tip:* To remove an old offer and replace it with a new one, you can use an [OfferCreate](#offercreate) transaction with an `OfferSequence` parameter, instead of using OfferCancel and another OfferCreate.
@@ -457,27 +596,46 @@ The OfferCancel method returns [tesSUCCESS](https://ripple.com/wiki/Transaction_

 ## TrustSet ##

+[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/module/app/transactors/SetTrust.cpp "Source")
+
 Create or modify a trust line linking two accounts.

+```
+{
+    "TransactionType": "TrustSet",
+    "Account": "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX",
+    "Fee": "12",
+    "Flags": 262144,
+    "LastLedgerSequence": 8007750,
+    "LimitAmount": {
+      "currency": "USD",
+      "issuer": "rsP3mgGb2tcYUrxiLFiHJiQXhsziegtwBc",
+      "value": "100"
+    },
+    "Sequence": 12
+}
+```
+
 | Field | JSON Type | [Internal Type](https://wiki.ripple.com/Binary_Format) | Description |
 |-------|-----------|---------------|-------------|
-| LimitAmount | Object | Amount | The maximum amount of currency, issued by the other party, that that the account is willing to hold. |
-| QualityIn | Unsigned Integer | UInt32 | (Optional) <span class='draft-comment'>% fee for incoming value on this line, represented as an integer over 1,000,000,000</span> |
-| QualityOut | Unsigned Integer | UInt32 | (Optional) <span class='draft-comment'>% fee for outgoing value on this line, represented as an integer over 1,000,000,000</span> |
-
-<span class='draft-comment'>(Where do you specify which account you're extending trust to? In the LimitAmount object?</span>
+| [LimitAmount](#trust-limits) | Object | Amount | Object defining the trust line to create or modify, in the same format as [currency amounts](rippled-apis.html#specifying-currency-amounts). |
+| LimitAmount.currency | String | (Amount.currency) | The currency to this trust line applies to, as a three-letter [ISO 4217 Currency Code](http://www.xe.com/iso4217.php) or a 160-bit hex value according to [currency format](https://wiki.ripple.com/Currency_format). "XRP" is invalid. |
+| LimitAmount.value | String | (Amount.value) | Quoted decimal representation of the limit to set on this trust line. |
+| LimitAmount.issuer | String | (Amount.issuer) | The address of the account to extend trust to. |
+| QualityIn | Unsigned Integer | UInt32 | (Optional) % fee for incoming value on this line, represented as an integer over 1,000,000,000. A value of `0` is shorthand for no fee. |
+| QualityOut | Unsigned Integer | UInt32 | (Optional) % fee for outgoing value on this line, represented as an integer over 1,000,000,000. A value of `0` is shorthand for no fee. |

 ### Trust Limits ###

-All balances on the Ripple Network, except for XRP, represent money owed in the real world. The account that issues those funds in Ripple (identified by the `issuer` field of the currency object) is responsible for paying money back, outside of the Ripple Network, when users redeem their Ripple balances by returning them to the issuing account. 
+All balances on the Ripple Network, except for XRP, represent value owed in the world outside the Ripple Ledger. The account that issues those funds in Ripple (identified by the `issuer` field of the `LimitAmount` object) is responsible for paying the balance back, outside of the Ripple Network, when users redeem their Ripple balances by returning them to the issuing account.

-Since a computer program cannot force the gateway to keep its promise and not default in real life, trust lines represent a way of configuring how much you are willing to trust the issuing account to hold on your behalf. Since a large, reputable issuing gateway is more likely to be able to pay you back than, say, your broke roommate, you can set different limits on each trust line, to indicate the maximum amount you are willing to let the issuing account "owe" you (off the network) for the funds that you hold on the network. In the case that the issuing account defaults or goes out of business, you can lose up to that much money because the balances you hold in the Ripple Network can no longer be exchanged for equivalent balances off the network.
+Since a computer program cannot force the gateway to keep its promise and not default in real life, trust lines represent a way of configuring how much you are willing to trust the issuing account to hold on your behalf. Since a large, reputable issuing gateway is more likely to be able to pay you back than, say, your broke roommate, you can set different limits on each trust line, to indicate the maximum amount you are willing to let the issuing account "owe" you (off the network) for the funds that you hold on the network. In the case that the issuing gateway defaults or goes out of business, you can lose up to that much money because the balances you hold in the Ripple Network can no longer be exchanged for equivalent balances off the network. (The Ripple Ledger will still reflect that you possess the same balance with that issuing gateway, but you won't be able to redeem, making it unlikely to be worth anything.)

-A trust line with a limit of 0 is equivalent to no trust line.
+There are two cases where you can hold a balance on a trust line that is *greater* than your limit: when you acquire more of that currency through [trading](#offercreate), or when you decrease the limit on your trust line.

-### Quality ###
+Since a trust line occupies space in the ledger, [a trust line increases the XRP your account must hold in reserve](https://wiki.ripple.com/Reserves). This applies to the account extending trust, not to the account receiving it.

-<span class='draft-comment'>(TODO)</span>
+A trust line with a limit *and* a balance of 0 is equivalent to no trust line.

 ### TrustSet Flags ###

@@ -486,20 +644,16 @@ Transactions of the TrustSet type support additional values in the [`Flags` fiel
 | Flag Name | Hex Value | Decimal Value | Description |
 |-----------|-----------|---------------|-------------|
 | tfSetAuth | 0x00010000 | 65536 | Authorize the other party to hold issuances from this account. (No effect unless using the [*asfRequireAuth* AccountSet flag](#accountset-flags).) Cannot be unset. |
-| tfSetNoRipple | 0x00020000 | 131072 | Blocks rippling between two trustlines of the same currency, if this flag is set on both. |
-| tfClearNoRipple | 0x00040000 | 262144 | Clears the No-Rippling flag. |
+| tfSetNoRipple | 0x00020000 | 131072 | Blocks rippling between two trustlines of the same currency, if this flag is set on both. (See [No Ripple](https://wiki.ripple.com/No_Ripple) for details.) |
+| tfClearNoRipple | 0x00040000 | 262144 | Clears the No-Rippling flag. (See [No Ripple](https://wiki.ripple.com/No_Ripple) for details.) |
 | tfSetFreeze | 0x00100000 | 1048572 | [Freeze](https://wiki.ripple.com/Freeze) the trustline.
 | tfClearFreeze | 0x00200000 | 2097152 | Unfreeze the trustline. |

-### High Account, Low Account ###
-
-Trust lines are conceptualized as one-directional lines controlled by a single party; however, for optimization purposes, they are represented in the ledger as a single trust two-way trust line. Each account that is a party to a trust line is arbitrarily deemed either the "High" or "Low" account (depending on which one has higher the numerical representation of their account address). Flags and values generally apply to one or the other side of the trust line. <span class='draft-comment'>(This section should probably be rewritten or removed. It doesn't feel useful right now. Maybe more relevant in the ledger format page?)</span>
-
 # Pseudo-Transactions #

 Pseudo-Transactions are never submitted by users, nor propagated through the network. Instead, a server may choose to inject them in a proposed ledger directly. If enough servers inject an equivalent pseudo-transaction for it to pass consensus, then it becomes included in the ledger, and appears in ledger data thereafter.

-Some of the fields that are mandatory for normal transactions do not make sense for psuedo-transactions. In those cases, the pseudo-transaction has the following default values:
+Some of the fields that are mandatory for normal transactions do not make sense for pseudo-transactions. In those cases, the pseudo-transaction has the following default values:

 | Field | Default Value |
 |-------|---------------|
@@ -509,27 +663,15 @@ Some of the fields that are mandatory for normal transactions do not make sense
 | SigningPubKey | "" |
 | Signature | "" |

-## Amendment ##
-
-A new feature. <span class='draft-comment'>Not implemented?</span>
-
-| Field | JSON Type | [Internal Type](https://wiki.ripple.com/Binary_Format) | Description |
-|-------|-----------|---------------|-------------|
-| Amendment | N/A | Hash256 | A unique identifier for the new feature or rule change to be applied. |
-
-<span class='draft-comment'>(Supposedly there's a several-weeks-long waiting period before an Amendment applies. How is that determined? Based on closed ledger time, presumably?)</span>
-
-<span class='draft-comment'>(TODO)</span>
-
 ## Fee ##

 A change in transaction or account fees. This is typically in response to changes in the load on the network.

-| Field | JSON Type | [Internal Type](https://wiki.ripple.com/Binary_Format) | Description |
-|-------|-----------|---------------|-------------|
-| BaseFee | <span class='draft-comment'>String (quoted integer?)</span> | UInt64 | The charge, in drops, for the reference transaction |
-| ReferenceFeeUnits | <span class='draft-comment'>Unsigned Integer?</span> | UInt32 | The cost, in fee units, of the reference transaction |
-| ReserveBase | <span class='draft-comment'>Unsigned Integer?</span> | UInt32 | The base reserve, in drops |
-| ReserveIncrement | <span class='draft-comment'>Unsigned Integer?</span> |UInt32 | The incremental reserve, in drops |
+*Note:* There have been very few, if any, Fee psuedo-transactions, ever. It is possible, but very unlikely, that you may encounter one in a historical ledger.

-<span class='draft-comment'>(TODO)</span>
+| Field | JSON Type | [Internal Type](https://wiki.ripple.com/Binary_Format) | Description |
+|-------|-----------|--------------------------------------------------------|-------------|
+| BaseFee | String (Quoted Integer) | UInt64 | The charge, in drops, for the reference transaction. (See [Transaction Fee Terminology](https://ripple.com/wiki/Transaction_Fee#Fee_Terminology) |
+| ReferenceFeeUnits | Unsigned Integer | UInt32 | The cost, in fee units, of the reference transaction |
+| ReserveBase | Unsigned Integer | UInt32 | The base reserve, in drops |
+| ReserveIncrement | Unsigned Integer | UInt32 | The incremental reserve, in drops |
--- a/websocket_api.md
+++ b/websocket_api.md
@@ -1,5 +1,5 @@
 # WebSocket and JSON-RPC APIs #
-If you want to communicate directly with the `rippled` server, you have three fairly similar options for how to do that. All of these APIs use the same list of commands, with almost entirely the same parameters in each command. Whereas the [Ripple-REST API](?p=ripple-rest-api) provides a simplified interface on top of the WebSocket API for easier integration, these APIs provide the full power of Ripple but require slightly more complexity:
+If you want to communicate directly with the `rippled` server, you have three fairly similar options for how to do that. All of these APIs use the same list of commands, with almost entirely the same parameters in each command. Whereas the [Ripple-REST API](ripple-rest.html) provides a simplified interface on top of the WebSocket API for easier integration, these APIs provide the full power of Ripple but require slightly more complexity:

 * The WebSocket API uses the [WebSocket protocol](http://www.html5rocks.com/en/tutorials/websockets/basics/), available in most browsers and Javascript implementations, to achieve persistent two-way communication. There is not a 1:1 correlation between requests and responses. Some requests prompt the server to send multiple messages back asynchronously; other times, responses may arrive in a different order than the requests that prompted them. 
 * The JSON-RPC API relies on simple request-response communication via HTTP. For commands that prompt multiple responses, you can provide a callback URL.
@@ -386,6 +386,12 @@ Depending on how the `rippled` server is configured, how long it has been runnin

 *Note:* The distinction between `full`, `validating`, and `proposing` is based on synchronization with the rest of the global network, and it is normal for a server to fluctuate between these states as a course of general operation.

+## Modifying the Ledger ##
+
+All changes to Ripple's global shared ledger happen as the result of transactions. Consequently, this means that there is *only one* public API method that causes a change in the state of the Ripple Network at all: the [*submit*](#submit) command. Most of the other methods represent different ways to view the data represented in the Ripple Network, and the remaining ones just generate data for your convenience. (The [wallet_propose](#wallet-propose), [path_find](#path-find), and [random](#random) commands fall into this category.)
+
+For more information on the various transactions you can submit, consult the [Transaction Format](transactions.html).
+
 # API Methods #

 API methods for the Websocket and JSON-RPC APIs are defined by command names, and are divided into Public Commands and Admin Commands. Public Commands are not necessarily meant for the general public, but they are used by any client attached to the server. (Think of Public Commands as being for members or customers of the organization running the server, while the Admin Commands are for the personnel in charge of keeping the server operational.) Public Commands include the general operations for Ripple use, including checking the state of the ledger, finding a path to connecting users, and submitting a transaction, among others. Admin Commands, on the other hand, are meant only for the operators of the server, and include commands for managing the state of the server, the nodes it uses for validation, and other administrative features.
@@ -438,6 +444,7 @@ The `rippled` application, in addition to acting as a server, can be run (as a s
 Accounts are the core unit of authentication in the Ripple Network. Each account can hold balances in multiple currencies, and all transactions must be signed by an account's secret key. In order for an account to exist in a validated ledger version, it must hold a minimum reserve amount of XRP. (The [reserve for an account](https://ripple.com/wiki/Reserves) increases with the amount of data it is responsible for in the shared ledger.) It is expected that accounts will correspond loosely to individual users. 

 ## account_info ##
+[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/module/rpc/handlers/AccountInfo.cpp "Source")

 The `account_info` command retrieves information about an account, its activity, and its XRP balance. All information retrieved is relative to a particular version of the ledger. 

@@ -526,17 +533,18 @@ The response follows the [standard format](#response-formatting), with the resul
 | account_data | Object | Information about the requested account |
 | account_data.Account | String | Address of the requested account |
 | account_data.Balance | String | XRP balance in "drops" represented as a string |
-| account_data.Flags | 32-bit unsigned integer | Integer with different bits representing the status of several [account flags](https://ripple.com/wiki/Transactions#AccountSet_.283.29) |
+| account_data.Flags | 32-bit unsigned integer | Integer with different bits representing the status of several [account flags](transactions.html#accountset-flags) |
 | account_data.LedgerEntryType | String | "AccountRoot" is the type of ledger entry that holds an account's data |
 | account_data.OwnerCount | Integer | Number of other ledger entries (specifically, trust lines and offers) attributed to this account. This is used to calculate the total reserve required to use the account. |
 | account_data.PreviousTxnID | String | Hash value representing the most recent transaction that affected this account |
 | account_data.Sequence | Integer | The sequence number of the next valid transaction for this account. (Each account starts with Sequence = 1 and increases each time a transaction is made.) |
-| account_data.index | String | (Deprecated) Data on another deterministic wallet that can be derived from the account's secret. (Not widely supported; this feature may be dropped in the future.) |
+| account_data.index | String | A unique index for the AccountRoot node that represents this account in the ledger. |
 | ledger_current_index | Integer | (Omitted if `ledger_index` is provided instead) The sequence number of the most-current ledger, which was used when retrieving this information. The information does not contain any changes from ledgers newer than this one.  |
 | ledger_index | Integer | (Omitted if `ledger_current_index` is provided instead) The sequence number of the ledger used when retrieving this information. The information does not contain any changes from ledgers newer than this one. |
-| validated | Boolean | ([Upcoming](https://ripplelabs.atlassian.net/browse/RIPD-275)) True if this data is from a validated ledger version; if omitted or set to false, this data is not final. |
+| validated | Boolean | True if this data is from a validated ledger version; if omitted or set to false, this data is not final. ([New in version 0.26](https://ripplelabs.atlassian.net/browse/RIPD-275)) |

 ## account_lines ##
+[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/module/rpc/handlers/AccountLines.cpp "Source")

 The `account_lines` method returns information about the account's lines of trust, including balances in all non-XRP currencies and assets. All information retrieved is relative to a particular version of the ledger.

@@ -579,11 +587,11 @@ The request accepts the following paramters:
 | ledger_hash | String | (Optional) A 20-byte hex string for the ledger version to use. (See [Specifying a Ledger](#specifying-a-ledger-instance)) |
 | ledger_index | String or Unsigned Integer| (Optional) The sequence number of the ledger to use, or a shortcut string to choose a ledger automatically. (See [Specifying a Ledger](#specifying-a-ledger-instance))|
 | peer | String | (Optional) A unique ID for a second account. If provided, show only lines of trust connecting the two accounts. |
+| limit | Integer | ([Upcoming](https://ripplelabs.atlassian.net/browse/RIPD-343), Optional, default varies) Limit the number of transactions to retrieve. The server is not required to honor this value. |
+| marker | (Not Specified) | ([Upcoming](https://ripplelabs.atlassian.net/browse/RIPD-343)) Server-provided value to specify where to resume retrieving data from. |

 The following parameters are deprecated and may be removed without further notice: `ledger` and `peer_index`.

-This method may be changed in the future to provide better scalability. See [RIPD-343](https://ripplelabs.atlassian.net/browse/RIPD-343) for details and status.
-
 #### Response Format ####

 An example of a successful response:
@@ -884,6 +892,7 @@ The response follows the [standard format](#response-formatting), with a success
 |-------|------|-------------|
 | account | String | Unique address of the account this request corresponds to |
 | lines | Array | Array of trust-line objects, as described below. |
+| marker | (Not Specified) | ([Upcoming](https://ripplelabs.atlassian.net/browse/RIPD-343)) Server-defined value. Pass this to the next call in order to resume where this call left off. |

 Each trust-line object has some combination of the following fields, although not necessarily all of them:

@@ -899,7 +908,9 @@ Each trust-line object has some combination of the following fields, although no
 | quality_in | Unsigned Integer | Ratio for incoming [transit fees](https://ripple.com/wiki/Transit_Fees) represented in billionths. (For example, a value of 500 million represents a 0.5:1 ratio.) As a special case, 0 is treated as a 1:1 ratio. |
 | quality_out | Unsigned Integer | Ratio for outgoing [transit fees](https://ripple.com/wiki/Transit_Fees) represented in billionths. (For example, a value of 500 million represents a 0.5:1 ratio.) As a special case, 0 is treated as a 1:1 ratio. |

+
 ## account_offers ##
+[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/module/rpc/handlers/AccountOffers.cpp "Source")

 The `account_offers` method retrieves a list of offers made by a given account that are outstanding as of a particular ledger version.

@@ -948,11 +959,11 @@ A request can include the following parameters:
 | ledger | Unsigned integer, or String | (Deprecated, Optional) A unique identifier for the ledger version to use, such as a ledger sequence number, a hash, or a shortcut such as "validated". |
 | ledger_hash | String | (Optional) A 20-byte hex string identifying the ledger version to use. |
 | ledger_index | (Optional) Unsigned integer, or String | (Optional, defaults to `current`) The sequence number of the ledger to use, or "current", "closed", or "validated" to select a ledger dynamically. (See Ledger Indexes.) |
+| limit | Integer | ([Upcoming](https://ripplelabs.atlassian.net/browse/RIPD-344), Optional, default varies) Limit the number of transactions to retrieve. The server is not required to honor this value. |
+| marker | (Not Specified) | ([Upcoming](https://ripplelabs.atlassian.net/browse/RIPD-344)) Server-provided value to specify where to resume retrieving data from. |

 The following parameter is deprecated and may be removed without further notice: `ledger`.

-*Note:* This method may be changed in the future to support better scalability. See [RIPD-344](https://ripplelabs.atlassian.net/browse/RIPD-344) for details and status.
-
 #### Response Format ####

 An example of a successful response:
@@ -1003,6 +1014,8 @@ The response follows the [standard format](#response-formatting), with a success
 |-------|------|-------------|
 | account | String | Unique address identifying the account that made the offers |
 | offers | Array | Array of objects, where each object represents an offer made by this account that is outstanding as of the requested ledger version. |
+| marker | (Not Specified) | ([Upcoming](https://ripplelabs.atlassian.net/browse/RIPD-344)) Server-defined value. Pass this to the next call in order to resume where this call left off. |
+

 Each offer object contains the following fields:

@@ -1014,6 +1027,7 @@ Each offer object contains the following fields:
 | taker_pays | String or Object | The amount the account accepting the offer provides, as a String representing an amount in XRP, or a currency specification object. (See [Specifying Currency Amounts](#specifying-currency-amounts)) |

 ## account_tx ##
+[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/module/rpc/handlers/AccountTx.cpp "Source")

 The `account_tx` method retrieves a list of transactions that involved the specified account.

@@ -1082,7 +1096,8 @@ The request includes the following parameters:
 | limit | Integer | (Optional, default varies) Limit the number of transactions to retrieve. The server is not required to honor this value. |
 | marker | (Not Specified) | Server-provided value to specify where to resume retrieving data from. |

-There is also a deprecated legacy variation of the `account_tx` method. For that reason, we recommend *not using any of the following fields*: `offset`, `count`, `descending`, `ledger_max`, `ledger_min`
+[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/module/rpc/handlers/AccountTxSwitch.cpp "Source")
+There is also a deprecated legacy variation of the `account_tx` method. For that reason, we recommend *not using any of the following fields*: `offset`, `count`, `descending`, `ledger_max`, `ledger_min`.

 ##### Iterating over queried data ######

@@ -1594,6 +1609,7 @@ Each transaction object includes the following fields, depending on whether it w
 | validated | Boolean | Whether or not the transaction is included in a validated ledger. Any transaction not yet in a validated ledger is subject to change. |

 ## wallet_propose ##
+[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/module/rpc/handlers/WalletPropose.cpp "Source")

 Use the `wallet_propose` method to generate the keys needed for a new account. The account created this way will only become officially included in the Ripple network when it receives a transaction that provides enough XRP to meet the account reserve. (The `wallet_propose` command does not affect the global network. Technically, it is not strictly necessary for creating a new account: you could generate keys some other way, but that is not recommended.)

@@ -1669,7 +1685,7 @@ The response follows the [standard format](#response-formatting), with a success
 | public_key | String | The public key of the account, in encoded string format. |
 | public_key_hex | String | The public key of the account, in hex format. |

-The key generated by this method can also be used as a regular key for an account if you use the [SetRegularKey transaction type](https://ripple.com/wiki/index.php/API_Example_Transactions#Set_Regular_Key) to do so.
+The key generated by this method can also be used as a regular key for an account if you use the [SetRegularKey transaction type](transactions.html#setregularkey) to do so.



@@ -1678,6 +1694,7 @@ The key generated by this method can also be used as a regular key for an accoun
 The globally-shared ledger is the core of the Ripple Network. Each `rippled` server keeps a current version of the ledger, which contains all the accounts, transactions, offers, and other data in the network in an optimized tree format. As transactions and offers are proposed, each server incorporates them into its current copy of the ledger, closes it periodically, and (if configured) participates in the process of advancing the globally-validated version. After concensus is reached in the network, that ledger version is validated and becomes permanently immutable. Any transactions that were not included in one ledger become candidates to be included in the next validated version.

 ## ledger ##
+[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/module/rpc/handlers/Ledger.cpp "Source")

 Retrieve information about the public ledger.

@@ -1730,8 +1747,8 @@ The request can contain the following parameters:
 | transactions | Boolean | (Optional, defaults to false) If true, return information on transactions in the specified ledger version. |
 | full | Boolean | (Optional, defaults to false) If true, return full information on the entire ledger. (Equivalent to enabling `transactions`, `accounts`, and `expand` *Admin required* |
 | expand | Boolean | (Optional, defaults to false) Provide full JSON-formatted information for transaction/account information instead of just hashes |
-| ledger_hash | String | (Optional) A 20-byte hex string identifying the ledger version to use. |
-| ledger_index | (Optional) Unsigned integer, or String | (Optional, defaults to `current`) The sequence number of the ledger to use, or "current", "closed", or "validated" to select a ledger dynamically. (See Ledger Indexes.) |
+| ledger_hash | String | (Optional) A 20-byte hex string for the ledger version to use. (See [Specifying a Ledger](#specifying-a-ledger-instance)) |
+| ledger_index | String or Unsigned Integer| (Optional) The sequence number of the ledger to use, or a shortcut string to choose a ledger automatically. (See [Specifying a Ledger](#specifying-a-ledger-instance))|

 The `ledger` field is deprecated and may be removed without further notice.

@@ -1799,11 +1816,13 @@ The response follows the [standard format](#response-formatting), with a success
 | parent_hash | String | Unique identifying hash of the ledger that came immediately before this one. |
 | total_coins | String | Total number of XRP drops in the network, as a quoted integer. (This decreases as transaction fees cause XRP to be destroyed.) |
 | transaction_hash | String | Hash of the transaction information included in this ledger, as hex |
+| validated | Boolean | ([Upcoming](https://ripplelabs.atlassian.net/browse/RIPD-569)) If included and set to `true`, the information in this request describes a validated ledger version. Otherwise, the information is subject to change. |

 The following fields are deprecated and may be removed without further notice: `hash`, `seqNum`, `totalCoins`.


 ## ledger_closed ##
+[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/module/rpc/handlers/LedgerClosed.cpp "Source")

 The `ledger_closed` method returns the unique identifiers of the most recently closed ledger. (This ledger is not necessarily validated and immutable yet.)

@@ -1878,6 +1897,8 @@ The response follows the [standard format](#response-formatting), with a success
 | ledger_index | Unsigned Integer | Sequence number of this ledger |

 ## ledger_current ##
+[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/module/rpc/handlers/LedgerCurrent.cpp "Source")
+
 The `ledger_current` method returns the unique identifiers of the current in-progress ledger. This command is mostly useful for testing, because the ledger returned is still in flux.

 #### Request Format ####
@@ -1952,6 +1973,8 @@ The response follows the [standard format](#response-formatting), with a success
 A `ledger_hash` field is not provided, because the hash of the current ledger is constantly changing along with its contents.

 ## ledger_data ##
+[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/module/rpc/handlers/LedgerData.cpp "Source")
+
 The `ledger_data` method retrieves contents of the specified ledger. You can iterate through several calls in order to retrieve the entire contents of a single ledger version.

 #### Request Format ####
@@ -2193,6 +2216,8 @@ The format of each object in the `state` array depends on whether `binary` was s


 ## ledger_entry ##
+[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/module/rpc/handlers/LedgerEntry.cpp "Source")
+
 The `ledger_entry` method returns a single entry from the specified ledger. See [LedgerEntryType](https://ripple.com/wiki/Ledger_Format#Entries) for information on the different types of objects you can retrieve. *Note:* There is no commandline version of this method. You can use the [`json`](#json) command to access this method from the commandline instead.

 #### Request Format ####
@@ -2230,11 +2255,11 @@ An example of the request format:

 This method can retrieve several different types of data. You can select which type of item to retrieve by passing the appropriate parameters. Specifically, you should provide exactly one of the following fields:

-1. `index` - Retrieve an individual ledger entry by its unique index
+1. `index` - Retrieve an individual ledger node by its unique index
 2. `account_root` - Retrieve an account node, similar to the [account_info](#account-info) command
 3. `directory` - Retrieve a directory node, which contains a list of IDs linking things
 4. `offer` - Retrieve an offer node, which defines an offer to exchange currency
-5. `ripple_state` - Retrieve a RippleState node, which defines currency (IOU) balances and credit limits between accounts
+5. `ripple_state` - Retrieve a RippleState node, which a trust line along which non-XRP balances are held

 If you specify more than one of the above items, the server will retrieve only of them; it is undefined which one will be chosen.

@@ -2255,8 +2280,10 @@ The full list of parameters recognized by this method is as follows:
 | ripple_state.accounts | Array | (Required if `ripple_state` specified) 2-length array of account address strings, defining the two accounts linked by this RippleState entry |
 | ripple_state.currency | String | (Required if `ripple_state` specified) String representation of a currency that this RippleState entry relates to, as either a 3-letter currency code or a 40-character hex code |
 | binary | Boolean | (Optional, defaults to false) If true, return hashed data as hex strings. Otherwise, return data in JSON format. |
+| ledger_hash | String | (Optional) A 20-byte hex string for the ledger version to use. (See [Specifying a Ledger](#specifying-a-ledger-instance)) |
+| ledger_index | String or Unsigned Integer| (Optional) The sequence number of the ledger to use, or a shortcut string to choose a ledger automatically. (See [Specifying a Ledger](#specifying-a-ledger-instance))|

-The `generator` parameter is deprecated and may be removed without further notice.
+The `generator` and `ledger` parameters are deprecated and may be removed without further notice.

 #### Response Format ####

@@ -2326,6 +2353,7 @@ Transactions are the only thing that can modify the shared global ledger of the
 There are several sources of complication in transactions. Unlike traditional banking, where a trusted third party (the bank, or the [ACH](http://en.wikipedia.org/wiki/Automated_Clearing_House)) verifies the participants' identities and ensures their balances are adjusted accurately, Ripple uses cryptography and decentralized computing power to accomplish the same thing. Sending XRP, the Ripple Network's native crypto-currency, requires no third party aside from the distributed network itself. However, that is missing out on the key feature of Ripple: unlike individual crypto-currencies, the Ripple Network natively supports balances in any currency. This brings far more power, but it also means that the system must account for [counterparty risk](http://en.wikipedia.org/wiki/Counterparty_risk#Counterparty_risk), currency conversions, and other issues. The Ripple Network must be robust to keep track of which transactions have been completely validated, even when subject to hardware failures, attacks, or natural disasters.

 ## tx ##
+[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/module/rpc/handlers/Tx.cpp "Source")

 The `tx` method retrieves information on a single transaction. 

@@ -2503,7 +2531,7 @@ An example of a successful response:
 ```
 </div>

-The response follows the [standard format](#response-formatting), with a successful result containing the fields of the [Transaction object](https://ripple.com/wiki/Transaction_Format) as well as the following additional fields:
+The response follows the [standard format](#response-formatting), with a successful result containing the fields of the [Transaction object](transactions.html) as well as the following additional fields:

 | Field | Type | Description |
 |-------|------|-------------|
@@ -2512,11 +2540,12 @@ The response follows the [standard format](#response-formatting), with a success
 | ledger_index | Unsigned Integer | The sequence number of the ledger that includes this transaction. |
 | meta | Object | Various metadata about the transaction. |
 | validated | Boolean | True if this data is from a validated ledger version; if omitted or set to false, this data is not final. |
-| (Various) | (Various) | Other fields from the [Transaction object](https://ripple.com/wiki/Transaction_Format) |
+| (Various) | (Various) | Other fields from the [Transaction object](transactions.html) |

 *Note:* If the transaction was not found, it means that the rippled server could not find it from the ledger versions on hand. However, that does not mean that the transaction does not exist; it may simply have been included in an older ledger version that the `rippled` does not have on hand anymore.

 ## transaction_entry ##
+[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/module/rpc/handlers/TransactionEntry.cpp "Source")

 The `transaction_entry` method retrieves information on a single transaction from a specific ledger version. (The [`tx`](#tx) command, by contrast, searches all ledgers for the specified transaction. We recommend using that method instead.) 

@@ -2706,7 +2735,7 @@ The response follows the [standard format](#response-formatting), with a success
 | ledger_index | Unsigned Integer | Sequence number of the ledger version the transaction was found in; this is the same as the one from the request. |
 | ledger_hash | String | (May be omitted) Unique hash of the ledger version the transaction was found in; this is the same as the one from the request. |
 | metadata | Object | Various metadata about the transaction. |
-| tx_json | Object | JSON representation of the [Transaction object](https://ripple.com/wiki/Transaction_Format) |
+| tx_json | Object | JSON representation of the [Transaction object](transactions.html) |

 There are a couple possible reasons the server may fail to find the transaction:

@@ -2715,6 +2744,7 @@ There are a couple possible reasons the server may fail to find the transaction:
 * The server does not have the specified ledger version available. Another server that has the correct version on hand may have a different response.

 ## tx_history ##
+[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/module/rpc/handlers/TxHistory.cpp "Source")

 The `tx_history` method retrieves a selection of the most recent transactions made.

@@ -3591,9 +3621,10 @@ The response follows the [standard format](#response-formatting), with a success
 | index | Unsigned Integer | The value of `start` used in the request. |
 | txs | Array | Array of transaction objects. |

-The fields included in each transaction object vary slightly depending on the type of transaction. See [Transaction Format](https://ripple.com/wiki/Transaction_Format) for details.
+The fields included in each transaction object vary slightly depending on the type of transaction. See [Transaction Format](transactions.html) for details.

 ## path_find ##
+[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/module/rpc/handlers/PathFind.cpp "Source")

 *WebSocket API only!* The `path_find` method searches for a path along which a transaction can possibly be made, and periodically sends updates when the path changes over time. For a simpler version that is supported by JSON-RPC, see [`ripple_path_find`](#ripple-path-find). For payments occurring strictly in XRP, it is not necessary to find a path, because XRP can be sent directly to any account. 

@@ -3606,6 +3637,7 @@ There are three different modes, or sub-commands, of the path_find command. Spec
 Although the `rippled` server attempts to find the cheapest path or combination of paths for making a payment, it is not guaranteed that the paths returned by this method are, in fact, the best paths. Due to server load, pathfinding may not find the best results. Additionally, you should be careful with the pathfinding results from untrusted servers. A server could be modified to return less-than-optimal paths in order to earn money for its operators. If you do not have your own server that you can trust with pathfinding, you should compare the results of pathfinding from multiple servers operated by different parties, to minimize the risk of a single server returning poor results. (*Note:* A server returning less-than-optimal results is not necessarily proof of malicious behavior; it could also be a symptom of heavy server load.)

 ### path_find create ###
+[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/module/rpc/handlers/PathFind.cpp#L38 "Source")

 The `create` subcommand of `path_find` creates an ongoing request to find possible paths along which a payment transaction could be made from one specified account such that another account receives a desired amount of some currency. The initial response contains a suggested path between the two addresses that would result in the desired amount being received. After that, the server sends additional messages, with `"type": "path_find"`, with updates to the potential paths. The frequency of updates is left to the discretion of the server, but it usually means once every few seconds when there is a new ledger version.

@@ -4884,6 +4916,7 @@ Here is an example of an asychronous follow-up from a path_find create request:
 </div>

 ### path_find close ###
+[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/module/rpc/handlers/PathFind.cpp#L46 "Source")

 The `close` subcommand of `path_find` instructs the server to stop sending information about the current open pathfinding request.

@@ -4912,6 +4945,7 @@ The request includes the following parameters:
 If a pathfinding request was successfully closed, the response follows the same format as the initial response to [`path_find create`](#path_find-create). If there was no outstanding pathfinding request, an error is returned instead.

 ### path_find status ###
+[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/module/rpc/handlers/PathFind.cpp#L57 "Source")

 The `status` subcommand of `path_find` requests an immediate update about the client's currently-open pathfinding request.

@@ -4941,6 +4975,7 @@ If a pathfinding request is open, the response follows the same format as the in


 ## ripple_path_find ##
+[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/module/rpc/handlers/RipplePathFind.cpp "Source")

 The `ripple_path_find` method is a simplified version of [`path_find`](#path-find) that provides a single response to be used to make a payment transaction immediately. It is available in both the WebSocket and JSON-RPC APIs. However, the results tend to become outdated as time passes. Instead of making many subsequent calls, you should use [`path_find`](#path-find) instead where possible.

@@ -5257,10 +5292,11 @@ Each element in the `alternatives` array is an object that represents a path fro
 The following fields are deprecated, and may be omitted: `paths_canonical`, and `paths_expanded`. If they appear, you should disregard them.

 ## sign ##
+[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/module/rpc/handlers/Sign.cpp "Source")

 The `sign` method takes a transaction, specified as JSON, and a secret key, and returns a signed binary representation of the transaction that can be submitted. The result is always different, even when you provide the same transaction and secret key.

-*Note:* It is possible and preferable to sign a transaction without connecting to a server instead of using this command. For example, [ripple-lib's rsign.js](https://github.com/ripple/ripple-lib/blob/develop/bin/rsign.js) demonstrates offline signing of a transaction. You should prefer to do offline signing of a transaction, especially when do not control the server you are sending a transaction to. An untrustworthy server can abuse its position to change the transaction before signing it, or worse, use your secret to sign additional arbitrary transactions as if they came from you.
+*Note:* It is possible and preferable to sign a transaction without connecting to a server instead of using this command. For example, [ripple-lib's rsign.js](https://github.com/ripple/ripple-lib/blob/develop/bin/rsign.js) demonstrates offline signing of a transaction. You should prefer to do offline signing of a transaction, especially when you do not control the server you are sending a transaction to. An untrustworthy server can abuse its position to change the transaction before signing it, or worse, use your secret to sign additional arbitrary transactions as if they came from you.

 #### Request Format ####
 An example of the request format:
@@ -5320,14 +5356,16 @@ The request includes the following parameters:

 | Field | Type | Description |
 |-------|------|-------------|
-| tx_json | Object | [Transaction definition](https://ripple.com/wiki/Transaction_Format) in JSON format |
+| tx_json | Object | [Transaction definition](transactions.html) in JSON format |
 | secret | String | Secret key of the account supplying the transaction, used to sign it. Do not send your secret to untrusted servers or through unsecured network connections. |
 | offline | Boolean | (Optional, defaults to false) If true, when constructing the transaction, do not attempt to automatically fill in or validate values. |
+| build_path | Boolean | (Optional) If provided for a Payment-type transaction, automatically fill in the `Paths` field before signing. *Caution:* The server looks for the presence or absence of this field, not its value. This behavior may change. (See [RIPD-173](https://ripplelabs.atlassian.net/browse/RIPD-173) for status.) |

-The server automatically attempts to fill in certain fields from the `tx_json` object if they are omitted, unless you specified `offline` as true. Otherwise, the following fields are automatic:
+The server automatically attempts to fill in certain fields from the `tx_json` object if they are omitted, unless you specified `offline` as true. Otherwise, the following fields from the [transaction format](transactions.html) are automatically filled in:

-* `Sequence` - The server automatically uses the next Sequence number from the sender's account information. Be careful: the next sequence number for the account is not incremented until this transaction is applied. If you sign multiple transactions without submitting and waiting for the response to each one, you must provide the correct sequence numbers in the request. 
-* `Fee` - The server can automatically fill in an appropriate transaction fee (in drops of XRP) unless you specified `offline` as true. Otherwise, you must fill in the appropriate fee. Be careful: a malicious server can specify an excessively high fee.
+* `Sequence` - The server automatically uses the next Sequence number from the sender's account information. Be careful: the next sequence number for the account is not incremented until this transaction is applied. If you sign multiple transactions without submitting and waiting for the response to each one, you must provide the correct sequence numbers in the request. Automatically filled unless `offline` is true.
+* `Fee` - The server can automatically fill in an appropriate transaction fee (in drops of XRP) unless you specified `offline` as true. Otherwise, you must fill in the appropriate fee. Be careful: a malicious server can specify an excessively high fee. Automatically filled unless `offline` is true.
+* `Paths` - For Payment-type transactions (excluding XRP-to-XRP transfers), the Paths field can be automatically filled, as if you did a [ripple_path_find](#ripple-path-find). Only filled if `build_path` is provided. 

 #### Response Format ####

@@ -5394,7 +5432,7 @@ The response follows the [standard format](#response-formatting), with a success
 | Field | Type | Description |
 |-------|------|-------------|
 | tx_blob | String | Binary representation of the fully-qualified, signed transaction, as hex |
-| tx_json | Object | JSON specification of the [complete transaction](https://ripple.com/wiki/Transaction_Format) as signed, including any fields that were automatically filled in |
+| tx_json | Object | JSON specification of the [complete transaction](transactions.html) as signed, including any fields that were automatically filled in |

 *Warning:* If this command results in an error messages, the message can contain the account secret from the request. Make sure that these errors are not visible to others, including:

@@ -5403,8 +5441,70 @@ The response follows the [standard format](#response-formatting), with a success
 * Do not display the error message on a website, even by accident

 ## submit ##
+[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/module/rpc/handlers/Submit.cpp "Source")

-The `submit` method sends a transaction to the network to be confirmed and included in future ledgers. There are two ways to use it: either you can supply JSON along with your secret key (not recommended), or you can take a pre-signed transaction blob (for example, one created with [`sign`](#sign), or better yet, something [signed offline](https://github.com/ripple/ripple-lib/blob/develop/bin/rsign.js)) and submit it as-is.
+The `submit` method sends a [transaction](transactions.html) to the network to be confirmed and included in future ledgers. 
+
+This command has two modes:
+
+* Submit-only mode takes a signed, serialized transaction as a binary blob, and submits it to the network as-is. Since signed transaction objects are immutable, no portion of the transaction can be modified or automatically filled in after submission.
+* Sign-and-submit mode takes a JSON-formatted Transaction object, completes and signs the transaction in the same manner as the [sign command](#sign), and then submits the signed transaction. We recommend only using this mode for testing and development.
+
+To send a transaction as robustly as possible, you should construct and [`sign`](#sign) it in advance, persist it somewhere that you can access even after a power outage, then `submit` it as a `tx_blob`. After submission, monitor the network with the [`tx`](#tx) command to see if the transaction was successfully applied; if a restart or other problem occurs, you can safely re-submit the `tx_blob` transaction: it won't be applied twice since it has the same sequence number as the old transaction. 
+
+### Submit-Only Mode ###
+
+A submit-only request includes the following parameters:
+
+| Field | Type | Description |
+|-------|------|-------------|
+| tx_blob | String | Hex representation of the signed transaction to submit. |
+| fail_hard | Boolean | (Optional, defaults to false) If true, and the transaction fails locally, do not retry or relay the transaction to other servers |
+
+#### Request Format ####
+
+
+<div class='multicode'>
+*WebSocket*
+```
+{
+    "id": 3,
+    "command": "submit",
+    "tx_blob": "1200002280000000240000001E61D4838D7EA4C6800000000000000000000000000055534400000000004B4E9C06F24296074F7BC48F92A97916C6DC5EA968400000000000000B732103AB40A0490F9B7ED8DF29D246BF2D6269820A0EE7742ACDD457BEA7C7D0931EDB7447304502210095D23D8AF107DF50651F266259CC7139D0CD0C64ABBA3A958156352A0D95A21E02207FCF9B77D7510380E49FF250C21B57169E14E9B4ACFD314CEDC79DDD0A38B8A681144B4E9C06F24296074F7BC48F92A97916C6DC5EA983143E9D4A2B8AA0780F682D136F7A56D6724EF53754"
+}
+```
+
+*JSON-RPC*
+```
+{
+    "method": "submit",
+    "params": [
+        {
+            "tx_blob": "1200002280000000240000000361D4838D7EA4C6800000000000000000000000000055534400000000004B4E9C06F24296074F7BC48F92A97916C6DC5EA968400000000000000A732103AB40A0490F9B7ED8DF29D246BF2D6269820A0EE7742ACDD457BEA7C7D0931EDB74473045022100D184EB4AE5956FF600E7536EE459345C7BBCF097A84CC61A93B9AF7197EDB98702201CEA8009B7BEEBAA2AACC0359B41C427C1C5B550A4CA4B80CF2174AF2D6D5DCE81144B4E9C06F24296074F7BC48F92A97916C6DC5EA983143E9D4A2B8AA0780F682D136F7A56D6724EF53754"
+        }
+    ]
+}
+```
+
+*Commandline*
+```
+#Syntax: submit tx_blob
+submit 1200002280000000240000000361D4838D7EA4C6800000000000000000000000000055534400000000004B4E9C06F24296074F7BC48F92A97916C6DC5EA968400000000000000A732103AB40A0490F9B7ED8DF29D246BF2D6269820A0EE7742ACDD457BEA7C7D0931EDB74473045022100D184EB4AE5956FF600E7536EE459345C7BBCF097A84CC61A93B9AF7197EDB98702201CEA8009B7BEEBAA2AACC0359B41C427C1C5B550A4CA4B80CF2174AF2D6D5DCE81144B4E9C06F24296074F7BC48F92A97916C6DC5EA983143E9D4A2B8AA0780F682D136F7A56D6724EF53754
+```
+</div>
+
+
+### Sign-and-Submit Mode ###
+
+A sign-and-submit request includes the following parameters:
+
+| Field | Type | Description |
+|-------|------|-------------|
+| tx_json | Object | [Transaction definition](transactions.html) in JSON format, optionally omitting any auto-fillable fields. |
+| secret | String | (Required if `tx_json` is supplied) Secret key of the account supplying the transaction, used to sign it. Do not send your secret to untrusted servers or through unsecured network connections. |
+| fail_hard | Boolean | (Optional, defaults to false) If true, and the transaction fails locally, do not retry or relay the transaction to other servers |
+| offline | Boolean | (Optional, defaults to false) If true, when constructing the transaction, do not attempt to automatically fill in or validate values. |
+| build_path | Boolean | (Optional) If provided for a Payment-type transaction, automatically fill in the `Paths` field before signing. You must omit this field if the transaction is a direct XRP-to-XRP transfer. *Caution:* The server looks for the presence or absence of this field, not its value. This behavior may change. (See [RIPD-173](https://ripplelabs.atlassian.net/browse/RIPD-173) for status.) |

 #### Request Format ####
 An example of the request format:
@@ -5435,7 +5535,17 @@ An example of the request format:
    "method": "submit",
    "params": [
        {
-            "tx_blob": "1200002280000000240000000361D4838D7EA4C6800000000000000000000000000055534400000000004B4E9C06F24296074F7BC48F92A97916C6DC5EA968400000000000000A732103AB40A0490F9B7ED8DF29D246BF2D6269820A0EE7742ACDD457BEA7C7D0931EDB74473045022100D184EB4AE5956FF600E7536EE459345C7BBCF097A84CC61A93B9AF7197EDB98702201CEA8009B7BEEBAA2AACC0359B41C427C1C5B550A4CA4B80CF2174AF2D6D5DCE81144B4E9C06F24296074F7BC48F92A97916C6DC5EA983143E9D4A2B8AA0780F682D136F7A56D6724EF53754"
+            "secret": "sssssssssssssssssssssssssssss",
+            "tx_json": {
+                "Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
+                "Amount": {
+                    "currency": "USD",
+                    "issuer": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
+                    "value": "1"
+                },
+                "Destination": "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX",
+                "TransactionType": "Payment"
+            }
        }
    ]
 }
@@ -5450,26 +5560,6 @@ submit sssssssssssssssssssssssssssss '{"TransactionType":"Payment", "Account":"r

 [Try it! >](ripple-api-tool.html#submit)

-The request includes the following parameters:
-
-| Field | Type | Description |
-|-------|------|-------------|
-| tx_blob | String | (Do not include if tx_json and secret are supplied) Hex representation of the signed transaction to submit. |
-| tx_json | Object | (Do not include if tx_blob is supplied) [Transaction definition](https://ripple.com/wiki/Transaction_Format) in JSON format |
-| secret | String | (Required if tx_json is supplied) Secret key of the account supplying the transaction, used to sign it. Do not send your secret to untrusted servers or through unsecured network connections. |
-| fail_hard | Boolean | (Optional, defaults to false) If true, and the transaction fails locally, do not retry or relay the transaction to other servers |
-| offline | Boolean | (Optional, defaults to false) If true, when constructing the transaction, do not attempt to automatically fill in or validate values. (No effect when specifying the transaction as tx_blob.) |
-
-The JSON format for `tx_json` varies depending on the type of transaction. In the case of sending non-XRP currency (IOUs), you can obtain appropriate values for the `Paths` field by doing a `find_path` or `ripple_find_path` command first. The `Paths` field is not required for sending XRP. The provided path or paths are used as options for the path the payment takes; the server selects one or more of them to use according to its own criteria. You can omit the `Paths` field, but that leaves it up to the server to choose a path on the fly. Since the total cost of making the payment, including transit fees, is automatically deducted from the sending account, you should find paths ahead of time to avoid getting surprised. 
-
-By default, `rippled` tries to compute the cheapest combination of paths, but it may not have the resources to find the best option. A payment may even be broken up into multiple parts that take different paths if that is the cheapest way. An untrustworthy server could be modified to choose paths maliciously. 
-
-If `offline` is not set to true, then the server tries to automatically fill the `Sequence` and `Fee` parameters appropriately. 
-
-To send a transaction as robustly as possible, you should construct and [`sign`](#sign) it in advance, persist it somewhere that you can access even after a power outage, then `submit` it as a `tx_blob`. After submission, monitor the network with the [`tx`](#tx) command to see if the transaction was successfully applied; if a restart or other problem occurs, you can safely re-submit the `tx_blob` transaction: it won't be applied twice since it has the same sequence number as the old transaction. 
-
-You should provide a [LastLedgerSequence](https://ripple.com/wiki/Transaction_Format#Basic_Transaction_Format) field in your transaction to make sure that it expires quickly in the case that it does not succeed. Otherwise, a transaction may end up in limbo, neither failing nor confirming, for a long time.
-
 #### Response Format ####

 An example of a successful response:
@@ -5550,11 +5640,12 @@ The response follows the [standard format](#response-formatting), with a success

 *Warning:* If this command results in an error messages, the message can contain an account secret, if one was provided in the request. (This is not a problem if the request contained a signed tx_blob instead.) Make sure that these errors are not visible to others, including:

-* Do not write this error to a log file that can be seen by multiple people
-* Do not paste this error to a public place for debugging
-* Do not display the error message on a website, even by accident
+* Do not write an error including your secret to a log file that can be seen by multiple people
+* Do not paste an error including your secret to a public place for debugging
+* Do not display an error message including your secret on a website, even by accident

 ## book_offers ##
+[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/module/rpc/handlers/BookOffers.cpp "Source")

 The `book_offers` method retrieves a list of offers, also known as the [order book](http://www.investopedia.com/terms/o/order-book.asp), between two currencies. If the results are very large, a partial result is returned with a marker so that subsequent requests can resume from where the previous one left off.

@@ -5710,7 +5801,7 @@ The response follows the [standard format](#response-formatting), with a success
 | ledger_current_index | Integer | (Omitted if ledger version provided) Sequence number of the ledger version used when retrieving this data. |
 | ledger_index | Integer | (Omitted if ledger_current_index provided instead) Sequence number, provided in the request, of the ledger version that was used when retrieving this data. |
 | ledger_hash | String | (May be omitted) Hex hash, provided in the request, of the ledger version that was used when retrieving this data. |
-| offers | Array | Array of offer objects, each of which has the fields of an [offer transaction](https://ripple.com/wiki/Transaction_Format#OfferCreate_.287.29) |
+| offers | Array | Array of offer objects, each of which has the fields of an [OfferCreate transaction](transactions.html#offercreate) |

 In addition to the standard Offer fields, the following fields may be included in members of the `offers` array:

@@ -5726,7 +5817,9 @@ In addition to the standard Offer fields, the following fields may be included i
 Using subscriptions, you can have the server push updates to your client when various events happen, so that you can know right away and react accordingly. Subscriptions are only supported in the WebSocket API, where you can receive additional responses in the same channel.

 JSON-RPC support for subscription callbacks is deprecated and may not work as expected.
+
 ## subscribe ##
+[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/module/rpc/handlers/Subscribe.cpp "Source")

 The `subscribe` method requests periodic notifications from the server when certain events happen. 

@@ -5980,11 +6073,12 @@ The `accounts_proposed` subscription works the same way, except it also includes
 | ledger_hash | String | (Omitted for unvalidated transactions) Unique hash of the ledger version that includes this transaction, as hex |
 | ledger_index | Unsigned Integer | (Omitted for unvalidated transactions) Sequence number of the ledger version that includes this transaction |
 | meta | Object | (Omitted for unvalidated transactions) Various metadata about the transaction, including which ledger entries it affected |
-| transaction | Object | The [definition of the transaction](https://ripple.com/wiki/Transaction_Format) in JSON format |
+| transaction | Object | The [definition of the transaction](transactions.html) in JSON format |
 | validated | Boolean | If true, this transaction is included in a validated ledger. Responses from the `transaction` stream should always be validated. |


 ## unsubscribe ##
+[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/module/rpc/handlers/Unsubscribe.cpp "Source")

 The `unsubscribe` command tells the server to stop sending messages for a particular subscription or set of subscriptions.

@@ -6059,6 +6153,7 @@ The response follows the [standard format](#response-formatting), with a success
 There are also commands that retrieve information about the current state of the server. These may be useful for monitoring the health of the server, or in preparing for making other API methods. For example, you may query for the current fee schedule before sending a transaction, or you may check which ledger versions are available before digging into the ledger history for a specific record.

 ## server_info ##
+[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/module/rpc/handlers/ServerInfo.cpp "Source")

 The `server_info` command asks the server for a human-readable version of various information about the `rippled` server being queried.

@@ -6190,6 +6285,7 @@ The `info` object may have some arrangement of the following fields:
 | validation_quorum | Number | Minimum number of trusted validations required in order to validate a ledger version. Some circumstances may cause the server to require more validations. |

 ## server_state ##
+[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/module/rpc/handlers/ServerState.cpp "Source")

 The `server_state` command asks the server for various machine-readable information about the `rippled` server's current state. The results are very similar to [`server_info`](#server-info), but generally the units are chosen to be easier to process instead of easier to read. (For example, XRP values are given in integer drops instead of scientific notation or decimal values, and time is given in milliseconds instead of seconds.)

@@ -6326,6 +6422,7 @@ The `state` object may have some arrangement of the following fields:
 The rippled server also provides a few simple commands purely for convenience.

 ## ping ##
+[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/module/rpc/handlers/Ping.cpp "Source")

 The `ping` command returns an acknowledgement, so that clients can test the connection status and latency.

@@ -6390,6 +6487,7 @@ An example of a successful response:
 The response follows the [standard format](#response-formatting), with a successful result containing no fields. The client can measure the round-trip time from request to response as latency.

 ## random ##
+[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/module/rpc/handlers/Random.cpp "Source")

 The `random` command provides a random number to be used as a source of entropy for random number generation by clients.
Author	SHA1	Message	Date
Rome Reginelli	8fe388de6f	Merge pull request #74 from ripple/gh-pages Dev Portal from Staging to Master for 10/3 push	2014-10-03 13:55:45 -07:00
Rome Reginelli	7228faf419	Merge pull request #73 from mDuo13/gh-pages Small revisions in tx_format and rest tool	2014-10-03 13:22:29 -07:00
mDuo13	e6f753aa72	[TASK] REST API Tool - remove redundant test accts warning	2014-10-02 16:08:45 -07:00
mDuo13	10fa680688	[DOC] tx_format - alphabetized and clarified AccountTxnID, added Creating Accounts section.	2014-10-01 00:13:41 -07:00
mDuo13	b689061d89	[DOC] tx_format revisions as per pull request #72	2014-09-30 16:37:02 -07:00
Rome Reginelli	8303508670	Merge pull request #71 from mDuo13/gh-pages Updates to tx_format	2014-09-29 16:27:42 -07:00
mDuo13	c7c7f30845	[DOC] tx_format revisions & related rippled submit/sign tweaks	2014-09-29 16:23:14 -07:00
Rome Reginelli	96164d68e2	Merge pull request #9 from ripple/master Catching up to master	2014-09-29 11:11:28 -07:00
Rome Reginelli	3abd182ea8	Merge pull request #70 from sublimator/master merging so credit is given where credit is due; I'll update/edit as necessary	2014-09-29 11:08:11 -07:00
Nicholas Dudfield	a4a9b734f8	Update SetRegularKey section Change Internal Type to Account An account is a 160 bit hash of a public key in compressed form (pub \| sha256 \| ripemd160). The RegularKey field has the same json representation as the Account fields, which are likewise hashes.	2014-09-26 18:53:53 +07:00
Nicholas Dudfield	39f4a1cb08	Update Paths section SendMax implies source balance when no direct trustline to Destination Paths MUST be set when cross-currency/cross-issue payments are made Empty Paths may not be serialized (ripple-lib doesn't serialize them, rippled errors) Crash script for empty Paths: ```shell export ALICE='rG1QQv2nh2gr7RCZ1P8YYcBUKCCN633jCn' export BOB='rPMh7Pi9ct699iZUTWaytJUoHcJ7cgyziK' export ROOT='rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh' function close_ledger() { ./build/rippled ledger_accept } function submit() { ./build/rippled submit $1 "$2" } function json-rpc() { curl -X POST -v http://127.0.0.1:5005 -d "$(cat <<RPC { "method" : "$1", "params" : [$2] } RPC )" \| python -c 'import sys,json; print json.dumps(json.loads(sys.stdin.read()), indent=2)' } submit masterpassphrase "$(cat <<TXN { "TransactionType" : "Payment", "Account" : "$ROOT", "Destination" : "$BOB", "Amount" : "1000000000" } TXN )" close_ledger submit bob "$(cat <<TXN { "TransactionType" : "TrustSet", "Account" : "$BOB", "LimitAmount" : {"value" : "500", "currency" : "USD", "issuer" : "$ROOT"} } TXN )" submit masterpassphrase "$(cat <<TXN { "Account" : "$ROOT" ,"TransactionType" : "Payment", "Destination" : "$BOB" ,"Amount" : {"value" : "1", "currency" : "USD", "issuer" : "$ROOT"} , "Paths" : [] } TXN )" # { # "result" : { # "error" : "internal", # "error_code" : 59, # "error_message" : "Exception occurred during transaction", # "request" : { # "command" : "submit", # "secret" : "masterpassphrase", # "tx_json" : { # "Account" : "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh", # "Amount" : { # "currency" : "USD", # "issuer" : "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh", # "value" : "500" # }, # "Destination" : "rPMh7Pi9ct699iZUTWaytJUoHcJ7cgyziK", # "Paths" : [], # "TransactionType" : "Payment" # } # }, # "status" : "error" # } # } ```	2014-09-26 18:47:00 +07:00
Nicholas Dudfield	7582184ea5	Update Memos section: Include `Internal Type` in the table List the `MemoData` and `MemoFormat` fields (TODO: descriptions) Add example json, as the format is "weird" Show that the fields are variable length, and the json for this type is a hex string Make it clear that the 1 kbyte limit applies to the field as serialized For further reference: https://gist.github.com/justmoon/9462822 https://wiki.ripple.com/Example_API_Transactions TODO: Check the semantics and/or usage guidelines behind MemoData/MemoType/MemoFormat	2014-09-26 18:15:42 +07:00
Nicholas Dudfield	4e6adb1f34	Clean trailing whitespace	2014-09-26 18:10:46 +07:00
Nicholas Dudfield	71932be386	PreviousTxnID -> AccountTxnID PreviousTxnID (deprecated) mandates the PreviousTxnID field, present in the transaction to match that in the AccountRoot of the initiating Account. Note that this field is update on EVERY transaction affecting the account (eg. 1 drop inbound payments) See: https://wiki.ripple.com/Transaction_Metadata#Threading Relevant source from Transactor.cpp:211 // Deprecated: Do not use if (mTxn.isFieldPresent (sfPreviousTxnID) && (mTxnAccount->getFieldH256 (sfPreviousTxnID) != mTxn.getFieldH256 (sfPreviousTxnID))) return tefWRONG_PRIOR; if (mTxn.isFieldPresent (sfAccountTxnID) && (mTxnAccount->getFieldH256 (sfAccountTxnID) != mTxn.getFieldH256 (sfAccountTxnID))) return tefWRONG_PRIOR;	2014-09-26 17:58:37 +07:00
Nicholas Dudfield	d79b84ed43	Fix some typos / grammatical errors	2014-09-26 17:51:41 +07:00
Rome Reginelli	1aebd976ea	Merge pull request #69 from ripple/gh-pages Staging to Master for 9/25 push	2014-09-25 18:00:07 -07:00
Rome Reginelli	2430809517	Merge pull request #68 from mDuo13/gh-pages REST API tool improvements	2014-09-25 17:59:10 -07:00
mDuo13	daf5bca353	[FEATURE] REST API Tool breaks out editable components of URL only, move method to a button instead of a dropdown	2014-09-25 17:55:01 -07:00
mDuo13	bd99c824c7	[DOC] REST revisions - intro material and formatting	2014-09-24 18:18:44 -07:00
mDuo13	e0f404ecd7	[FIX] websocket - replaced a missing	2014-09-24 15:38:02 -07:00
Rome Reginelli	202e42b08d	Merge pull request #67 from ripple/gh-pages Preparing for 9/24 patch push	2014-09-24 15:32:38 -07:00
Rome Reginelli	f01f9f529e	Merge pull request #66 from mDuo13/gh-pages [FIX] rippled APIs - update transaction format link in sign command	2014-09-24 13:53:20 -07:00
mDuo13	c834cd8c16	[FIX] rippled APIs - update transaction format link in sign command	2014-09-24 13:50:43 -07:00
Rome Reginelli	2f040e0c28	Merge pull request #65 from mDuo13/gh-pages [FIX] REST tool handle DEV-44 in all cases	2014-09-24 13:43:52 -07:00
mDuo13	937cb2e2bf	[FIX] remove outdated comment	2014-09-24 13:36:14 -07:00
mDuo13	37a23d499b	[FIX] actually fix DEV-44 in all cases	2014-09-24 13:34:52 -07:00
Rome Reginelli	0388898396	Merge pull request #8 from mDuo13/rest_apitool [FIX] REST tool - correctly wipe req body on command select per DEV-44	2014-09-24 13:30:54 -07:00
mDuo13	060c5ad755	[FIX] REST tool - correctly wipe req body on command select as per DEV-44	2014-09-24 13:29:17 -07:00
Rome Reginelli	8be084b979	Merge pull request #64 from ripple/gh-pages REST API tool - remove redundant :443 from URL	2014-09-23 15:32:33 -07:00
mDuo13	8ae50b6597	[MERGE] Merge branch 'gh-pages' of https://github.com/ripple/ripple-dev-portal into gh-pages	2014-09-23 15:30:54 -07:00
mDuo13	c7986b3e45	[FIX] Rest API Tool - remove redundant :443	2014-09-23 15:30:38 -07:00
Rome Reginelli	a2a660fa32	Merge pull request #63 from ripple/gh-pages Dev Portal from Staging to Master for 9/23 push	2014-09-23 14:52:29 -07:00
Rome Reginelli	05a5440f4f	Merge pull request #62 from mDuo13/gh-pages [FIX] REST API Tool mixpanel tracking name	2014-09-23 13:36:22 -07:00
mDuo13	f3e518b25b	[FIX] REST API Tool mixpanel tracking name	2014-09-23 13:35:33 -07:00
Rome Reginelli	746b072803	Merge pull request #61 from mDuo13/gh-pages [FIX] REST API tool fills in a new client_resource_id each pageload	2014-09-23 13:32:52 -07:00
mDuo13	c67a310fc0	[FIX] REST API tool fills in a new client_resource_id each pageload	2014-09-23 13:31:45 -07:00
Rome Reginelli	affd896fe3	Merge pull request #60 from mDuo13/gh-pages API tool fixes	2014-09-23 12:57:58 -07:00
mDuo13	3786fa21e0	[TASK] both API tools: add a throbber to indicate request-in-progress	2014-09-23 12:55:20 -07:00
mDuo13	fb47986f3b	[FIX] REST api tool: POST methods work now	2014-09-23 12:33:06 -07:00
Rome Reginelli	50af081193	Merge pull request #59 from mDuo13/gh-pages residual updates for tx_format and rest-api-tool	2014-09-19 17:31:52 -07:00
mDuo13	2f27bab67b	[DOC] rest - linked to API tool; also fixed some inconsistencies	2014-09-19 17:30:00 -07:00
mDuo13	73a551702f	[DOC] rippled-apis: updated links to transaction format; fixed a dead link to ripple REST	2014-09-19 17:08:29 -07:00
mDuo13	feb3074e8f	[DOC] tx_format: added source code links to explain canonical order	2014-09-19 17:02:27 -07:00
Rome Reginelli	f48045856a	Merge pull request #58 from ripple/Rest-updates [DOC] fixes in submit payment documentation	2014-09-19 16:59:41 -07:00
n0rmz	64fdde5d4b	[DOC] fixes in submit payment documentation	2014-09-19 16:53:36 -07:00
mDuo13	a6f06c399e	[MERGE] tx_format, rest tool	2014-09-19 15:57:11 -07:00
mDuo13	fcabac30da	[TASK] tx_format - ready for deploy; adding TX and consensus to footers	2014-09-19 15:47:30 -07:00
mDuo13	aab362a00a	Merge branch 'mDuo13-rest_apitool' into gh-pages	2014-09-19 15:23:59 -07:00
mDuo13	9588aa68aa	Merge branch 'rest_apitool' of https://github.com/mDuo13/ripple-dev-portal into mDuo13-rest_apitool	2014-09-19 15:23:44 -07:00
mDuo13	f4c222b006	[TASK] split API tool in all headers	2014-09-19 15:21:21 -07:00
mDuo13	eea601176c	[DOC] tx_format: removed some draft warnings	2014-09-19 14:50:21 -07:00
mDuo13	d6b6405543	[TASK] REST apitool - all methods specced, some structural cleanup	2014-09-19 13:17:08 -07:00
mDuo13	b2fa86afc5	[FIX] REST API Tool js file	2014-09-18 18:50:07 -07:00
mDuo13	fd4be275ab	[TASK] Rest API tool through submit payment	2014-09-18 18:49:08 -07:00
Rome Reginelli	58d0f2828f	Merge pull request #55 from ripple/gh-pages Dev Portal from Staging to Master for 9/18 push	2014-09-18 15:17:37 -07:00
Rome Reginelli	ddb285245a	Merge pull request #54 from mDuo13/rest_newwallet [DOC] REST simplified wording on new acct	2014-09-18 15:11:28 -07:00
mDuo13	a46a2a5a05	[DOC] REST simplified wording on new acct	2014-09-18 15:10:24 -07:00
Rome Reginelli	39a9f38e8f	Merge pull request #53 from mDuo13/rest_newwallet [DOC] add version number to new acct call	2014-09-18 15:05:32 -07:00
mDuo13	6aec472374	[DOC] add version number to new acct call	2014-09-18 15:05:00 -07:00
Rome Reginelli	cc39b76a6e	Merge pull request #52 from mDuo13/ripd_fixes rippled APIs updates	2014-09-18 13:55:45 -07:00
mDuo13	fb5b310443	[DOC] ripd status updates	2014-09-18 13:52:08 -07:00
mDuo13	83014bff40	[DOC] update rippled w/ RIPD-343/344 status, source links; tx_format clarifications and example for SetRegularKey	2014-09-18 13:38:30 -07:00
n0rmz	5c3a5190eb	[DOC] Updating /v1/server response	2014-09-17 18:27:02 -07:00
Rome Reginelli	a74deb6a03	Merge pull request #7 from mDuo13/websocket_typos [DOC] rippled APIs: fixed several mistakes, typos	2014-09-17 17:19:39 -07:00
mDuo13	2922fc8b79	[DOC] rippled APIs: fixed several mistakes, typos	2014-09-17 17:17:29 -07:00
mDuo13	77f5fd47b1	[DOC] tx_format revisions w/ feedback from ahbritto	2014-09-17 17:16:16 -07:00
Rome Reginelli	6cb9cc807e	Merge pull request #51 from mDuo13/rest_newwallet [DOC] REST: new account method, +typofixes	2014-09-16 16:31:04 -07:00
mDuo13	7a6f91f078	[DOC] REST: new account method, +typofixes	2014-09-16 16:29:35 -07:00
mDuo13	d57e301cd7	[DOC] tx_format, small rewordings	2014-09-16 15:51:34 -07:00
mDuo13	52a92e6a9e	[DOC] update rippled w/ RIPD-343/344 status, source links; tx_format clarifications and example for SetRegularKey	2014-09-15 16:20:58 -07:00
mDuo13	a44af459c2	[DOC] tx_format examples for most types, expanded some sections, added source links	2014-09-12 16:24:26 -07:00
Rome Reginelli	953a7f54c7	Merge pull request #50 from ripple/gh-pages get tracking fix(?) from gh-pages	2014-09-12 15:23:40 -07:00
Rome Reginelli	2ac4748ae4	Merge pull request #49 from mDuo13/gh-pages [FIX] rippled-apis tracking maybe better?	2014-09-12 15:22:55 -07:00
mDuo13	017c9a2ff4	[FIX] rippled-apis tracking maybe better?	2014-09-12 15:20:54 -07:00
				`@@ -0,0 +1 @@`
				var Plugins;(function(n){var t=function(){function n(n){typeof n=="undefined"&&(n=30);this.space=n}return n}(),i;n.AutosizeInputOptions=t;i=function(){function n(t,i){var r=this;this._input=$(t);this._options=$.extend({},n.getDefaultOptions(),i);this._mirror=$('<span style="position:absolute; top:-999px; left:0; white-space:pre;"/>');$.each(["fontFamily","fontSize","fontWeight","fontStyle","letterSpacing","textTransform","wordSpacing","textIndent"],function(n,t){r._mirror[0].style[t]=r._input.css(t)});$("body").append(this._mirror);this._input.on("keydown keyup input propertychange change",function(){r.update()});(function(){r.update()})()}return n.prototype.getOptions=function(){return this._options},n.prototype.update=function(){var n=this._input.val()\|\|"",t;n!==this._mirror.text()&&(this._mirror.text(n),t=this._mirror.width()+this._options.space,this._input.width(t))},n.getDefaultOptions=function(){return this._defaultOptions},n.getInstanceKey=function(){return"autosizeInputInstance"},n._defaultOptions=new t,n}();n.AutosizeInput=i,function(t){var i="autosize-input",r=["text","password","search","url","tel","email","number"];t.fn.autosizeInput=function(u){return this.each(function(){if(this.tagName=="INPUT"&&t.inArray(this.type,r)>-1){var f=t(this);f.data(n.AutosizeInput.getInstanceKey())\|\|(u==undefined&&(u=f.data(i)),f.data(n.AutosizeInput.getInstanceKey(),new n.AutosizeInput(this,u)))}})};t(function(){t("input[data-"+i+"]").autosizeInput()})}(jQuery)})(Plugins\|\|(Plugins={}))