commit 9916b7fc1235581bc303396bb83423c3151df687
parent 95e5d5e339dabaef85b0e353eeccdf25970c17e5
Author: Christian Grothoff <christian@grothoff.org>
Date: Tue, 30 Jun 2026 00:54:58 +0200
add missing cross-links
Diffstat:
20 files changed, 45 insertions(+), 45 deletions(-)
diff --git a/core/api-bank-conversion-info.rst b/core/api-bank-conversion-info.rst
@@ -32,7 +32,7 @@ The current protocol version is **v2**.
**Version history:**
-* ``v2``: adds ``/rate`` endpoint
+* ``v2``: adds :http:get:`/rate </rate>` endpoint
**Upcoming versions:**
diff --git a/core/api-challenger.rst b/core/api-challenger.rst
@@ -43,13 +43,13 @@ particular address. However, asking a user to prove access to a particular
address can be expensive as it may involve sending an SMS or even postal mail
depending on the type of address. Thus, challenger does not allow a user
agent to begin an address validation process without prior approval by a
-registered client. Thus, the process begins with a ``/setup/$CLIENT_ID`` request where a
+registered client. Thus, the process begins with a :http:post:`/setup/$CLIENT_ID </setup/$CLIENT_ID>` request where a
client requests challenger to begin an address validation request. The
-``/setup/$CLIENT_ID`` response contains a ``nonce`` which is then used to construct the
+:http:post:`/setup/$CLIENT_ID </setup/$CLIENT_ID>` response contains a ``nonce`` which is then used to construct the
URL of the endpoint to which the client must redirect the user-agent to begin
the address validation and authorization process.
-The client then redirects the user-agent to the ``/authorize/$NONCE`` endpoint
+The client then redirects the user-agent to the :http:get:`/authorize/$NONCE </authorize/$NONCE>` endpoint
of the challenger service, adding its ``state``, ``client_id`` and
``redirect_uri`` as query parameters. The ``redirect_uri`` must match the
redirect URI registered with the client. From this endpoint, the challenger
@@ -64,21 +64,21 @@ service will return a Web page asking the user to provide its address.
of the scope of the standard.
When the user has filled in the form with their address, it will be submitted
-to the ``/challenge/$NONCE`` endpoint and the challenger service will send a
+to the :http:post:`/challenge/$NONCE </challenge/$NONCE>` endpoint and the challenger service will send a
challenge to the user's address and generate an HTML form asking the user to
enter the received challenge value.
The user can then enter the answer to the challenge which is then submitted to
-the ``/solve/$NONCE`` endpoint. If the answer is correct, the user agent will
+the :http:post:`/solve/$NONCE </solve/$NONCE>` endpoint. If the answer is correct, the user agent will
be redirected to the client redirect URI that was specified by the OAuth 2.0
client upon ``/authorize``, together with an authorization grant encoded in
the redirection URI.
Given this authorization grant, the OAuth 2.0 client can then use the
-``/token`` endpoint to obtain an access token which will grant it access to
+:http:post:`/token </token>` endpoint to obtain an access token which will grant it access to
the resource.
-Using the ``/info`` endpoint the client can then finally obtain the (now)
+Using the :http:get:`/info </info>` endpoint the client can then finally obtain the (now)
verified address of the user.
.. contents:: Table of Contents
@@ -95,7 +95,7 @@ The current protocol version is **v6**.
**Version history:**
-* ``v6``: add the ``address_type`` field to ``/config``
+* ``v6``: add the ``address_type`` field to :http:get:`/config </config>`
**Upcoming versions:**
diff --git a/core/api-common.rst b/core/api-common.rst
@@ -498,7 +498,7 @@ Ages
Versions
^^^^^^^^
-We use the type ``LibtoolVersion`` in the design documents to refer to a string
+We use the type `LibtoolVersion` in the design documents to refer to a string
that represents a version with the semantic as defined by
`libtool <https://www.gnu.org/software/libtool/manual/html_node/Libtool-versioning.html>`__.
@@ -509,7 +509,7 @@ that represents a version with the semantic as defined by
// see https://www.gnu.org/software/libtool/manual/html_node/Libtool-versioning.html.
type LibtoolVersion = string;
-We use the type ``SemVer`` to refer to a string that represents a version with
+We use the type `SemVer` to refer to a string that represents a version with
the semantic as defined by `semantic versioning <https://semver.org/>`__.
.. ts:def:: SemVer
diff --git a/core/api-corebank.rst b/core/api-corebank.rst
@@ -62,14 +62,14 @@ Config
Authentication
--------------
-Some endpoints requires the client to authenticate using a bearer token. Tokens can be obtained or refreshed using the ``/accounts/$USERNAME/token`` endpoint.
+Some endpoints requires the client to authenticate using a bearer token. Tokens can be obtained or refreshed using the :http:post:`/accounts/$USERNAME/token </accounts/$USERNAME/token>` endpoint.
This endpoint support authentication via HTTP Basic auth (RFC 7617). When using Basic authentication, the user-id must be the bank's username, and the password the password of the corresponding user.
The user ``admin`` is a special, hard-coded username. Some requests require the client to authenticate as administrator.
.. warning::
- Since **v7** Basic authentication for endpoints other than ``/accounts/$USERNAME/token`` has been deprecated and will no longer be supported in the next release.
+ Since **v7** Basic authentication for endpoints other than :http:post:`/accounts/$USERNAME/token </accounts/$USERNAME/token>` has been deprecated and will no longer be supported in the next release.
.. include:: corebank/post-accounts-USERNAME-token.rst
diff --git a/core/api-exchange.rst b/core/api-exchange.rst
@@ -43,12 +43,12 @@ The currently implemented protocol version is **v37**.
* ``v30``: various minor feature additions
* ``v31``: improvements for AML reporting
* ``v32``: support for extra_wire_subject_metadata
-* ``v33``: addition of accumulated_total_without_fee in ``/batch-deposit``
+* ``v33``: addition of accumulated_total_without_fee in :http:post:`/batch-deposit </batch-deposit>`
* ``v34``: new offline signature; support for open_banking_gateway and
- prepared_transfer_url per wire account in ``/keys``
-* ``v35``: adds ``default_p2p_push_expiration`` to ``/keys``
-* ``v36``: adds ``kyc_swap_tos_acceptance`` to ``/keys``
-* ``v37``: adds ``/aml/$OFFICER_PUB/wallet-credit`` endpoint
+ prepared_transfer_url per wire account in :http:get:`/keys </keys>`
+* ``v35``: adds ``default_p2p_push_expiration`` to :http:get:`/keys </keys>`
+* ``v36``: adds ``kyc_swap_tos_acceptance`` to :http:get:`/keys </keys>`
+* ``v37``: adds :http:get:`/aml/$OFFICER_PUB/wallet-credit </aml/$OFFICER_PUB/wallet-credit>` endpoint
**Upcoming versions:**
@@ -159,7 +159,7 @@ exchange.
Eventually the exchange will need to advertise a policy for how long it will
keep transaction histories for inactive or even fully drained reserves. We
- will therefore need some additional handler similar to ``/keys`` to
+ will therefore need some additional handler similar to :http:get:`/keys </keys>` to
advertise those terms of service.
@@ -401,7 +401,7 @@ either case, the protocol is only used in **abnormal**
situations). In the above cases, the exchange signals to the
wallets that the emergency cash back protocol has been activated
by putting the affected denomination keys into the cash-back
-part of the ``/keys`` response. If and only if this has happened,
+part of the :http:get:`/keys </keys>` response. If and only if this has happened,
coins that were signed with those denomination keys can be cashed
in using this API.
diff --git a/core/api-merchant.rst b/core/api-merchant.rst
@@ -54,7 +54,7 @@ The currently implemented protocol version is **v32**.
* ``v26``: adds unclaim endpoint, enhanced settlement reporting
* ``v27``: adds various fields to a few endpoints
* ``v28``: adds the ``/kycauth`` endpoint for wire transfer subject
- shortening during KYC Auth wire transfers and expands ``/config``.
+ shortening during KYC Auth wire transfers and expands :http:get:`/config </config>`.
* ``v29``: adds ``max_pickup_duration`` to templates (for Paivana)
* ``v30``: adds ``debit_restrictions`` to GET /exchanges (for SPA)
* ``v31``: adds ``/private/accept-tos-early`` and related API changes
@@ -150,7 +150,7 @@ Authentication
Each merchant instance has separate authentication settings for the private API resources
of that instance.
-Currently, the ``/private/auth/`` API supports two main authentication methods in the ``InstanceAuthConfigurationMessage``:
+Currently, the ``/private/auth/`` API supports two main authentication methods in the `InstanceAuthConfigurationMessage`:
* ``external``: (@deprecated since **v20**) With this method, no checks are done by the merchant backend.
Instead, a reverse proxy / API gateway must do all authentication/authorization checks.
@@ -207,7 +207,7 @@ Exchange Status API
The exchange status API exposes basic information about the exchanges
configured for a merchant backend, in particular the acceptable
currencies, master public keys and the status of the merchant backend's
-download of the ``/keys`` from the exchange. This is mostly useful
+download of the :http:get:`/keys </keys>` from the exchange. This is mostly useful
to diagnose configuration problems.
.. include:: merchant/get-exchanges.rst
@@ -759,7 +759,7 @@ may include additional meta-data, such as the amount or contract paid
by the customer. For details on setup and supported event payloads, see the
`Merchant manual – Setting up a webhook <https://docs.taler.net/taler-merchant-manual.html#setting-up-a-webhook>`_.
-Each webhook is bound to an ``event_type``. The backend currently recognizes the following types, which are mirrored in the ``WebhookEventType`` enum so API clients can
+Each webhook is bound to an ``event_type``. The backend currently recognizes the following types, which are mirrored in the `WebhookEventType` enum so API clients can
validate their payloads without guesswork:
.. ts:def:: WebhookEventType
@@ -1394,7 +1394,7 @@ Orders
// After this deadline has passed, no refunds will be accepted.
// Overrides deadline calculated from ``refund_delay`` in
- // ``PostOrderRequest``.
+ // `PostOrderRequest`.
// A value of "never" is not allowed.
refund_deadline?: Timestamp;
@@ -1956,7 +1956,7 @@ listing it in the exchanges array.
}
In addition to the fields described above,
-each object (from ``ContractTerms`` down)
+each object (from `ContractTerms` down)
can mark certain fields as "forgettable" by listing the names of those fields
in a special peer field ``_forgettable``.
(See :ref:`Private order data cleanup <private-order-data-cleanup>`.)
diff --git a/core/bank-conversion-info/get-rate.rst b/core/bank-conversion-info/get-rate.rst
@@ -3,8 +3,8 @@
Since protocol **v2**.
This public endpoint allows clients to get the currenlty applied change rate between the regional currency and the fiat currency of the banking system for this exchange account.
- Those informations should never be used to perform conversions use ``/cashin-rate`` and ``/cashout-rate`` instead.
- Conversion rates can change at any time. Clients must deal with any resulting errors and call ``/cashin-rate`` or ``/cashout-rate`` again to use the new rates.
+ Those informations should never be used to perform conversions use :http:get:`/cashin-rate </cashin-rate>` and :http:get:`/cashout-rate </cashout-rate>` instead.
+ Conversion rates can change at any time. Clients must deal with any resulting errors and call :http:get:`/cashin-rate </cashin-rate>` or :http:get:`/cashout-rate </cashout-rate>` again to use the new rates.
If ``cashin_ratio`` is zero, this means the account cannot cashin, and if ``cash_out`` ratio is zero, this means the account cannot cashout.
**Response:**
diff --git a/core/challenger/get-info.rst b/core/challenger/get-info.rst
@@ -5,7 +5,7 @@
**Request:**
- Must include the token returned to the client from the ``/token`` endpoint
+ Must include the token returned to the client from the :http:post:`/token </token>` endpoint
as a ``Bearer`` token in an ``Authorization`` header.
**Response:**
diff --git a/core/challenger/post-setup-CLIENT_ID.rst b/core/challenger/post-setup-CLIENT_ID.rst
@@ -5,7 +5,7 @@
a ``Bearer`` token) should be included to provide the client's credentials
to authorize access to the challenger service. This token must match the
``client_secret`` from the registration of the client with the challenger
- service (which will also be used in the later ``/token`` request).
+ service (which will also be used in the later :http:post:`/token </token>` request).
**Request:**
diff --git a/core/donau/patch-charities-CHARITY_ID.rst b/core/donau/patch-charities-CHARITY_ID.rst
@@ -3,7 +3,7 @@
Modify a charity.
Only allowed if the request comes with the administrator bearer token.
- **Request:** ``CharityRequest``
+ **Request:** `CharityRequest`
**Response:**
diff --git a/core/exchange/get-config.rst b/core/exchange/get-config.rst
@@ -2,7 +2,7 @@
Return the protocol version and currency supported by this exchange backend,
as well as the list of possible KYC requirements. This endpoint is largely
- for the SPA for AML officers. Merchants should use ``/keys`` which also
+ for the SPA for AML officers. Merchants should use :http:get:`/keys </keys>` which also
contains the protocol version and currency.
**Response:**
diff --git a/core/exchange/get-kyc-spa-ACCESS_TOKEN.rst b/core/exchange/get-kyc-spa-ACCESS_TOKEN.rst
@@ -5,7 +5,7 @@
hash that serves the KYC SPA. This is where the ``/kyc-check/`` endpoint
will in principle redirect clients. The KYC SPA will use the
``$ACCESS_TOKEN`` of its URL to initialize itself via the
- ``/kyc-info/$ACCESS_TOKEN`` endpoint family. The KYC SPA may download
+ :http:get:`/kyc-info/$ACCESS_TOKEN </kyc-info/$ACCESS_TOKEN>` endpoint family. The KYC SPA may download
additional resources via ``/kyc-spa/$FILENAME``. The filenames must not
match base32-encoded 256-bit values.
diff --git a/core/exchange/post-auditors-AUDITOR_PUB-H_DENOM_PUB.rst b/core/exchange/post-auditors-AUDITOR_PUB-H_DENOM_PUB.rst
@@ -1,6 +1,6 @@
.. http:post:: /auditors/$AUDITOR_PUB/$H_DENOM_PUB
- This is used to add an auditor signature to the ``/keys`` response. It
+ This is used to add an auditor signature to the :http:get:`/keys </keys>` response. It
affirms to wallets and merchants that this auditor is indeed auditing
the coins issued by the respective denomination. There is no "delete"
operation for this, as auditors can only stop auditing a denomination
diff --git a/core/exchange/post-kyc-bulk-EXTERN_PUB.rst b/core/exchange/post-kyc-bulk-EXTERN_PUB.rst
@@ -1,6 +1,6 @@
.. http:post:: /kyc-bulk/$EXTERN_PUB
- The ``/kyc-import/$EXTERN_PUB`` POST endpoint allows third parties to
+ The :http:post:`/kyc-import/$EXTERN_PUB </kyc-import/$EXTERN_PUB>` POST endpoint allows third parties to
upload **large** KYC/KYB attachments.
The ``$EXTERN_PUB`` is the public EdDSA key
identifying the 3rd party encoded using Crockford base32 encoding.
diff --git a/core/exchange/post-reveal-melt.rst b/core/exchange/post-reveal-melt.rst
@@ -1,7 +1,7 @@
.. http:post:: /reveal-melt
Reveal previously committed values to the exchange, except for the values
- corresponding to the ``noreveal_index`` returned by the ``/melt`` step.
+ corresponding to the ``noreveal_index`` returned by the :http:post:`/melt </melt>` step.
The base URL for ``/reveal-melt``-request may differ from the main base URL of
the exchange. Clients SHOULD respect the ``reveal_base_url`` returned for the
diff --git a/core/exchange/post-reveal-withdraw.rst b/core/exchange/post-reveal-withdraw.rst
@@ -1,7 +1,7 @@
.. http:post:: /reveal-withdraw
Reveal previously committed values to the exchange, except for the values
- corresponding to the ``noreveal_index`` returned by the ``/withdraw`` step.
+ corresponding to the ``noreveal_index`` returned by the :http:post:`/withdraw </withdraw>` step.
The base URL for ``/reveal-withdraw``-request may differ from the main base URL of
the exchange. Clients SHOULD respect the ``reveal_base_url`` returned for the
diff --git a/core/exchange/post-withdraw.rst b/core/exchange/post-withdraw.rst
@@ -21,7 +21,7 @@
:http:statuscode:`201 Created`:
The request was successful, and ``max_age`` was set.
The response is a `AgeWithdrawResponse`. The client is expected
- to call ``/reveal-withdraw`` next.
+ to call :http:post:`/reveal-withdraw </reveal-withdraw>` next.
Note that repeating exactly the same request will again yield the same
response, so if the network goes down during the transaction or before the
client can commit the coins signature to disk, the coins are not lost.
@@ -53,8 +53,8 @@
The response comes with a standard
`ErrorDetail` response with error-code
``TALER_EC_EXCHANGE_GENERIC_DENOMINATION_KEY_UNKNOWN``.
- This suggests the wallet has outdated ``/keys`` and
- should fetch the latest ``/keys``.
+ This suggests the wallet has outdated :http:get:`/keys </keys>` and
+ should fetch the latest :http:get:`/keys </keys>`.
:http:statuscode:`409 Conflict`:
One of the following reasons occured:
diff --git a/core/mailbox/post-register.rst b/core/mailbox/post-register.rst
@@ -4,11 +4,11 @@
May be used to update encryption keys.
May incur cost.
The mailbox identity is given through the keys field
- in the ``MailboxMetadata`` field.
+ in the `MailboxMetadata` field.
**Request**
- The body of the request must be a ``MailboxRegistrationRequest``.
+ The body of the request must be a `MailboxRegistrationRequest`.
**Details:**
diff --git a/core/merchant/post-orders-ORDER_ID-pay.rst b/core/merchant/post-orders-ORDER_ID-pay.rst
@@ -97,7 +97,7 @@
(and then return signatures with refunds). If a coin was already spent
(this includes re-using the same coin after a refund),
the response will include the ``exchange_url`` for which the payment failed,
- in addition to the response from the exchange to the ``/batch-deposit`` request.
+ in addition to the response from the exchange to the :http:post:`/batch-deposit </batch-deposit>` request.
Applicable error codes:
* ``MERCHANT_POST_ORDERS_ID_PAY_INSUFFICIENT_FUNDS``: Exchange reported insufficient
@@ -207,7 +207,7 @@
// blinded envelopes. The donation tokens will be present
// at the offset matching the place where a donation receipt
// was indicated in the outputs array, and of course be skipped
- // if the ``PayWalletData`` did not have a ``donau`` field.
+ // if the `PayWalletData` did not have a ``donau`` field.
// @since protocol **v21**
token_sigs?: SignedTokenEnvelope[];
diff --git a/core/merchant/post-private-accept-tos-early.rst b/core/merchant/post-private-accept-tos-early.rst
@@ -7,7 +7,7 @@
``tos_accepted_early`` field of `MerchantAccountKycRedirect`.
This is intended for deployments where the exchange has set
- ``kyc_swap_tos_acceptance`` in its ``/keys`` response, meaning
+ ``kyc_swap_tos_acceptance`` in its :http:get:`/keys </keys>` response, meaning
the frontend swaps the terms-of-service and KYC auth
authentication steps in the user experience.
