Fix link to ipfs-add documentation

Author: hsanjuan

content/documentation/reference/api.md

@@ -44,7 +44,7 @@ There are considerations to take into account here:
 
 Currently IPFS Cluster supports adding with two DAG-formats (`?format=` query parameter):
 
-* By default it uses the `unixfs` format. In this mode, the request body is expected to be a multipart just like described in [`/api/v0/add` documentation](https://docs.ipfs.io/reference/http/api/#api-v0-add). The `/add` endpoint supports the same optional parameters as IPFS does and produces exactly the same DAG as go-ipfs when adding files. In UnixFS, files uploaded in the request are chunked and a DAG is built replicating the desired folder layout. This is done by the cluster peer.
+* By default it uses the `unixfs` format. In this mode, the request body is expected to be a multipart just like described in [`/api/v0/add` documentation](https://docs.ipfs.tech/reference/kubo/rpc/#api-v0-add). The `/add` endpoint supports the same optional parameters as IPFS does and produces exactly the same DAG as go-ipfs when adding files. In UnixFS, files uploaded in the request are chunked and a DAG is built replicating the desired folder layout. This is done by the cluster peer.
 * Alternatively, the `/add` endpoint also accepts a CAR file with `?format=car` format. In this case, the CAR file already includes the blocks that need to be added to IPFS and Cluster does not do any further processing (similarly to `ipfs dag import`). At the moment, the `/add` endpoint will process only a single CAR file and this file must have only one root (the one that will be pinned). CAR files allow adding arbitrary IPLD-DAGs through the Cluster API.
 
 <div class="tipbox warning">Using the <code>/add</code> endpoint with Nginx in front as a reverse proxy may cause problems. Make sure to add <code>?stream-channels=false</code> to every Add request to avoid them.<br /><br />The problems manifest themselves as "connection reset by peer while reading upstream" errors in the logs. They are caused by read after write on the HTTP request/response cycle: Nginx refuses any application that has started sending the response body to read further from the request body (<a href="https://trac.nginx.org/nginx/ticket/1293" target="_blank">see bug report</a>). IPFS and IPFS Cluster send object updates while adding files, therefore triggering the situation, which is otherwise legal per HTTP specs. The issue depends on Nginx internal buffering and may appear very sporadically or not at all, but it exists.</div>