Migrate old callout syntax

docs/references/http-websocket-apis/api-conventions/ctid.md

@@ -15,7 +15,7 @@ The differences between a CTID and a transaction's [identifying hash](../../../c
 - A CTID identifies a validated transaction based on its network ID, ledger index, and position within the ledger. Since it specifies which network a transaction has been validated on, it can be used in contexts where you are interacting with more than one network, such as connecting to sidechains. A CTID is 64 bits, typically written as 16 characters of uppercase hexadecimal starting with `C`, for example `C005523E00000000`.
 - An transaction's identifying hash identifies a signed transaction based on its contents, regardless of if that transaction has been validated on any chains. Since it's a cryptographic hash, it can also be used to prove that the transaction contents are intact. A transaction hash is 256 bits, typically written as 64 characters of hexadecimal, for example `E08D6E9754025BA2534A78707605E0601F03ACE063687A0CA1BDDACFCD1698C7`.
 
-**Caution:** Do not try to use a CTID for a transaction that has not yet been validated. The canonical order of the transaction can change between when the transaction is initially applied and when it is validated by the consensus process, resulting in a CTID that identifies a different transaction or no transaction at all.
+{% admonition type="warning" name="Caution" %}Do not try to use a CTID for a transaction that has not yet been validated. The canonical order of the transaction can change between when the transaction is initially applied and when it is validated by the consensus process, resulting in a CTID that identifies a different transaction or no transaction at all.{% /admonition %}
 
 ## Structure
 
@@ -26,7 +26,7 @@ A CTID contains the following parts, in order (big-endian):
 3. 16 bits: The transaction index, its place within the ledger's canonical order. This is provided as the field `TransactionIndex` in [transaction metadata](../../protocol/transactions/metadata.md).
 4. 16 bits: The [network ID](../../protocol/transactions/common-fields.md#networkid-field) of the network that validated this transaction.
 
-**Note:** The ledger index is normally stored as a 32-bit unsigned integer which increases by 1 each time a new ledger is created. If a network's ledger index is greater than 268,435,455, it won't fit in 28 bits, so the leading `C` should be incremented to `D`, `E`, or `F` as necessary. This is not expected to be necessary until at least the year 2043.
+{% admonition type="info" name="Note" %}The ledger index is normally stored as a 32-bit unsigned integer which increases by 1 each time a new ledger is created. If a network's ledger index is greater than 268,435,455, it won't fit in 28 bits, so the leading `C` should be incremented to `D`, `E`, or `F` as necessary. This is not expected to be necessary until at least the year 2043.{% /admonition %}
 
 ## See Also
 

docs/references/http-websocket-apis/api-conventions/error-formatting.md

@@ -10,7 +10,7 @@ labels:
 
 It is impossible to list all the possible ways an error can occur. Some may occur in the transport layer (for example, loss of network connectivity), in which case the results vary depending on what client and transport you are using. However, if the `rippled` server successfully receives your request, it tries to respond in a standardized error format.
 
-**Caution:** When your request results in an error, the entire request is copied back as part of the response, so that you can try to debug the error. However, this also includes any secrets that were passed as part of the request. When sharing error messages, be very careful not to accidentally expose important account secrets to others.
+{% admonition type="warning" name="Caution" %}When your request results in an error, the entire request is copied back as part of the response, so that you can try to debug the error. However, this also includes any secrets that were passed as part of the request. When sharing error messages, be very careful not to accidentally expose important account secrets to others.{% /admonition %}
 
 
 Some example errors:

docs/references/http-websocket-apis/api-conventions/rate-limiting.md

@@ -10,7 +10,7 @@ labels:
 
 The `rippled` server limits the rate at which API clients can make requests on public APIs. Rate limiting is based on the IP address of the client, so clients behind [network address translation](https://en.wikipedia.org/wiki/Network_address_translation) share a limit based on their public IP address.
 
-**Tip:** Rate limiting does not apply when the client is connected [as an admin](../../../tutorials/http-websocket-apis/build-apps/get-started.md#admin-access).
+{% admonition type="success" name="Tip" %}Rate limiting does not apply when the client is connected [as an admin](../../../tutorials/http-websocket-apis/build-apps/get-started.md#admin-access).{% /admonition %}
 
 When a client is approaching the rate limit, the server adds the field `"warning": "load"` at the top level of an [API response](response-formatting.md). This warning is not added to every response, but the server may send several such warnings before it disconnects a client.
 

docs/references/http-websocket-apis/api-conventions/request-formatting.md

@@ -97,7 +97,7 @@ The commandline calls JSON-RPC, so its responses always match the JSON-RPC [resp
 
 The commandline always uses the latest [API version](#api-versioning).
 
-**Caution:** The commandline interface is intended for administrative purposes only and is _not a supported API_. New versions of `rippled` may introduce breaking changes to the commandline API without warning!
+{% admonition type="warning" name="Caution" %}The commandline interface is intended for administrative purposes only and is _not a supported API_. New versions of `rippled` may introduce breaking changes to the commandline API without warning!{% /admonition %}
 
 
 ## API Versioning

docs/references/http-websocket-apis/api-conventions/response-formatting.md

@@ -176,7 +176,7 @@ This warning indicates that the server answering the request is running [Reporti
 
 It is generally safe to ignore this warning.
 
-**Caution:** If you request ledger data without explicitly [specifying a ledger version][Specifying Ledgers], Reporting Mode uses the latest validated ledger by default instead of the current in-progress ledger.
+{% admonition type="warning" name="Caution" %}If you request ledger data without explicitly [specifying a ledger version][Specifying Ledgers], Reporting Mode uses the latest validated ledger by default instead of the current in-progress ledger.{% /admonition %}
 
 
 ## See Also

docs/references/http-websocket-apis/api-conventions/rippled-server-states.md

@@ -20,6 +20,6 @@ Depending on how the `rippled` server is configured, how long it has been runnin
 | `validating`   | The server is currently participating in validation of the ledger |
 | `proposing`    | The server is participating in validation of the ledger and currently proposing its own version. |
 
-**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.
+{% admonition type="info" name="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.{% /admonition %}
 
 {% raw-partial file="/docs/_snippets/common-links.md" /%}