Nothing but APIs under api.taler.net

3 files changed, 23 insertions, 19 deletions

diff --git a/docs/example-essay-store.rst b/docs/example-essay-store.rst
index 8ba28df6..1d533d98 100644
--- a/docs/example-essay-store.rst
+++ b/docs/example-essay-store.rst
@@ -30,7 +30,8 @@ https://git.taler.net/merchant-frontends.git/tree/talerfrontends/blog
 and is implemented in Python+Flask.
 
 The desired effect is the homepage showing a list of buyable articles, and once the
-user clicks one of them, they will either get the Taler :ref:`contract <contract>`
+user clicks one of them, they will either get the Taler
+`contract <https://api.taler.net/api-merchnat.html#contract>`_
 or a credit card paywall if they have no Taler wallet installed.
 
 Each article links thus to a `offer URL`, having the following
@@ -248,10 +249,12 @@ for the contract, the transaction ID, and the article name; respectively,
 ``now``, ``tid``, and ``article_name``.
 
 After ``make_contract`` returns, the variable ``contract`` will hold a
-`dict` type that complies with a contract :ref:`proposition <proposition>`.
+`dict` type that complies with a contract
+`proposition <https://api.taler.net/api-merchnat.html#proposition>`_
 We then call ``sign_contract`` feeding it with the proposition, so that
 it can forward it to the backend and return it signed.  Finally we return
-the signed proposition, complying with the :ref:`Offer <contract>` object.
+the signed proposition, complying with the
+`Offer <https://api.taler.net/api-merchant.html#contract>`_ object.
 
 For simplicity, any article costs the same price, so the frontend
 doesn't need to map articles to prices.
@@ -300,10 +303,10 @@ fulfillment URL parameters.  See below the URL layout:
 
 The way the contract is reconstructed is exactly the same as it was generated
 in the previous steps:  we need to call ``make_contract`` to get the original
-:ref:`proposition <proposition>` and then ``sign_contract``.  Recall that aside
-from allowing the backend to add missing fields to the proposition, ``sign_contract``
-returns the contract hashcode also, that we should compare with the ``uuid``
-parameter provided by the wallet.
+`proposition <https://api.taler.net/api-merchnat.html#proposition>`_ and then
+``sign_contract``.  Recall that aside from allowing the backend to add missing
+fields to the proposition, ``sign_contract`` returns the contract hashcode also,
+that we should compare with the ``uuid`` parameter provided by the wallet.
 
 In our blog, all the fulfillment logic is implemented in the function ``article``,
 defined in ``talerfrontends/blog/blog.py``.  It is important to note that this
@@ -551,8 +554,8 @@ Pay logic
 ---------
 
 The pay handler for the blog is implemented by the function
-``pay`` at ``talerfrontends/blog/blog.py``.  Its main duty is
-to receive the :ref:`deposit permission <DepositPermission>`
+``pay`` at ``talerfrontends/blog/blog.py``.  Its main duty is to receive the
+`deposit permission <https://api.taler.net/api-merchant.html#DepositPermission>`_
 from the wallet, forward it to the backend, and return the outcome
 to the wallet.  See below the main steps of its implementation.
 
diff --git a/docs/operate-exchange.rst b/docs/operate-exchange.rst
index 874b837c..38293bbc 100644
--- a/docs/operate-exchange.rst
+++ b/docs/operate-exchange.rst
@@ -106,12 +106,15 @@ For example, the utility may be invoked as follows::
 
 Note that the value given to option `-t` must match the value in the JSON's field ``"type"``.
 
-The generated file will be echoed by the exchange when serving :ref:`/wire <wire-req>` requests.
+The generated file will be echoed by the exchange when serving
+`/wire <https://api.taler.net/api-exchange.html#wire-req>`_
+requests.
 
 Outgoing
 ^^^^^^^^
 
-This exchange's bank account is used to give money to merchants, after successful :ref:`deposits <deposit-par>`
+This exchange's bank account is used to give money to merchants, after successful
+`deposits <https://api.taler.net/api-exchange.html#deposit-par>`_
 operations. If `test` is the chosen wireformat, the outcoming bank account is configured by the following
 options under `[exchange-wire-outcoming-test]`:
 
diff --git a/docs/operate-merchant.rst b/docs/operate-merchant.rst
index 484d6eba..7f88a00b 100644
--- a/docs/operate-merchant.rst
+++ b/docs/operate-merchant.rst
@@ -88,7 +88,8 @@ pattern::
 
    schema://hostname/
 
-`master_key` is the base32 encoding of the exchange's master key (see :ref:`/keys <keys>`).
+`master_key` is the base32 encoding of the exchange's master key
+(see `/keys <https://api.taler.net/api-exchange.html#keys>`_).
 In our demo, we use the following configuration::
 
    [merchant-exchange-test]
@@ -180,18 +181,15 @@ instance `Tor` as follows::
   [merchant-instance-wireformat-Tor]
   TEST_RESPONSE_FILE = ${TALER_CONFIG_HOME}/merchant/wire/tor.json
 
-Please note that :ref:`Taler messagging<merchant-api>` is designed so that the merchant
-frontend can instruct the backend on which instance has to be used in the various operations.
-This information is optional, and if not given, the backend will act as the `default` instance.
+Please note that `Taler messagging <https://api.taler.net/api-merchant.html#merchant-api>`_
+is designed so that the merchant frontend can instruct the backend on which instance has to
+be used in the various operations. This information is optional, and if not given,
+the backend will act as the `default` instance.
 
 ++++++++++++
 Installation
 ++++++++++++
 
-
-
-
-
 In order to compile your merchant backend, you firstly need to install the GNU Taler
 exchange.  As of other dependencies, the merchant backend needs exactly the same ones
 as the exchange does.  Follow :ref:`those instructions <exchange-install>` to build