Update docs (#650)

* Update doc strings with new ws url

* Update names and routes to match current config

* Update route and names to match api split

* Update routes/names to match api split

* 🎨

* drop generic

---------

Co-authored-by: ff137 <[email protected]>

Author: cl0ete

app/main.py

@@ -46,11 +46,11 @@
 
 Our WebSocket endpoints are as follows:
 
-1. `/ws/topic/{topic}`: (Admin only) This endpoint allows admins to receive all webhook events on a specific topic (e.g. `connections`, `credentials`, `proofs`, `endorsements`).
+1. `/v1/ws/topic/{topic}`: (Admin only) This endpoint allows admins to receive all webhook events on a specific topic (e.g. `connections`, `credentials`, `proofs`, `endorsements`).
 
-2. `/ws/{wallet_id}`: This endpoint allows authenticated users to receive webhook events associated with a specific wallet ID.
+2. `/v1/ws/{wallet_id}`: This endpoint allows authenticated users to receive webhook events associated with a specific wallet ID.
 
-3. `/ws/{wallet_id}/{topic}`: Similar to above, but with topic-specific subscription.
+3. `/v1/ws/{wallet_id}/{topic}`: Similar to above, but with topic-specific subscription.
 
 For authentication, the WebSocket headers should include `x-api-key`: `<your key>`.
 

docs/Bootstrap Trust Ecosystem.md

@@ -8,9 +8,9 @@
 
 ## 2. Generate a New DID
 
-1. Access the API through [Governance Cloud API](http://localhost:8100/docs)
+1. Access the API through [CloudAPI-Governance](http://localhost:8200/docs)
 2. Authenticate with `governance.`+`APIKEY` role
-3. Generate a new DID with a `POST` to the following API endpoint: `/wallet/dids/`
+3. Generate a new DID with a `POST` to the following API endpoint: `/v1/wallet/dids/`
 4. An example successful response to generate a DID would look like this:
 
    ```json
@@ -90,8 +90,8 @@ Verkey: BUxNgHYEYm5bsTEpjo9Dkgr5zGA4feeiuiq32HfqyCKg
 
 ## 5. Set Public DID
 
-1. Go to the [Governance Cloud API](http://localhost:8100/docs)
-2. Execute the PUT endpoint to set a Public DID: `/wallet/dids/public?did=`
+1. Go to the [CloudAPI-Governance](http://localhost:8200/docs)
+2. Execute the PUT endpoint to set a Public DID: `/v1/wallet/dids/public?did=`
 3. Use the DID that you anchored to the ledger in step 3
 4. A successful response should look like this. You can also query the Public DID Endpoint `/wallet/dids/public` of the Governance Agent to confirm that the public DID is now set:
 

docs/Common Steps.md

@@ -2,7 +2,14 @@
 
 This document will guide you through some common steps and interactions. Please read it carefully, and feel free to open an issue if further questions arise or if you spot a mistake.
 
->**Note:** It is always helpful to inspect the CloudAPI Swagger UI to understand the available endpoints, their expected inputs, and the corresponding outputs. If requests fail, check the Swagger UI to ensure you've called the correct endpoint with the correct data. The Swagger UI is accessible at [http://localhost:8100/docs](http://localhost:8100/docs) under a vanilla setup. If you find any model to be unclear from the document below, try finding it in Swagger UI before opening an issue. This document describes only some basic steps; more detailed workflows can be found [here](./Example%20Flows.md).
+>**Note:** It is always helpful to inspect the CloudAPI Swagger UI to understand the available endpoints, their expected inputs, and the corresponding outputs. If requests fail, check the Swagger UI to ensure you've called the correct endpoint with the correct data. The Swagger UI is accessible at:
+>
+> * CloudAPI-Multitenant-Admin -> [http://localhost:8100/docs](http://localhost:8100/docs)
+> * CloudAPI-Governance -> [http://localhost:8200/docs](http://localhost:8200/docs)
+> * CloudAPI-Tenant -> [http://localhost:8300/docs](http://localhost:8300/docs)
+> * CloudAPI-Public (trust registry) -> [http://localhost:8400/docs](http://localhost:8400/docs)
+>
+> under a vanilla setup. If you find any model to be unclear from the document below, try finding it in Swagger UI before opening an issue. This document describes only some basic steps; more detailed workflows can be found [here](./Example%20Flows.md).
 
 It is also recommended to set up a webhook listener (refer to our [Webhooks doc](./Webhooks.md)). This will significantly aid in understanding the activities occurring in the ACA-Py instances in the background.
 
@@ -25,7 +32,7 @@ The admin "wallet" is already configured as it is not a subwallet on a multi-ten
    }
    ```
 
-Send this to the `/admin/tenants` endpoint. You can omit the roles field altogether or pass "issuer" and/or "verifier". All payloads are documented in Swagger, so if in doubt, consult the [Swagger docs](http://localhost:8100/docs).
+Send this to the `/tenant-admin/v1/admin/tenants` endpoint. You can omit the roles field altogether or pass "issuer" and/or "verifier". All payloads are documented in Swagger, so if in doubt, consult the [CloudAPI-Multitenant-Admin](http://localhost:8100/docs).
 
 Creating a tenant with roles will update the trust registry by writing an entry for an `actor`, including wallet details and its associated roles.
 
@@ -53,7 +60,7 @@ To create schemas and effectively write them to the ledger as well as registerin
    }
    ```
 
-   Note that you will need to have a public DID to do so (if your agent lacks one, you can use the governance role to create one: see [Bootstrapping the Trust Ecosystem](./Bootstrap%20Trust%20Ecosystem.md)). Run the request with the header from 1. and the payload from 2. against the CloudAPI URL and endpoint `/admin/governance/schemas/` (POST method). Upon success, the created schema will be returned.
+   Note that you will need to have a public DID to do so (if your agent lacks one, you can use the governance role to create one: see [Bootstrapping the Trust Ecosystem](./Bootstrap%20Trust%20Ecosystem.md)). Run the request with the header from 1. and the payload from 2. against the [CloudAPI-Governance URL](http://localhost:8200/docs) and endpoint `/v1/definitions/schemas` (POST method). Upon success, the created schema will be returned.
 
 ## Issuing a Credential
 
@@ -62,7 +69,7 @@ To create schemas and effectively write them to the ledger as well as registerin
 3. Issuer creates credential definition
 4. Create a connection between the issuer and prospect holder
 
-   1. Create an invitation using either the issuer or the holder using the `/connections` endpoint of the CloudAPI. Here, you will also need to authenticate via the header, e.g., using
+   1. Create an invitation using either the issuer or the holder using the `/v1/connections/create-invitation` endpoint of the [CloudAPI-Tenant URL](http://localhost:8300/docs). Here, you will also need to authenticate via the header, e.g., using
 
       ```json
       { "x-api-key": "tenant.WALLET_TOKEN" }

docs/Governance as Code.md

@@ -4,7 +4,7 @@
 
 Schemas are used to define attributes related to credentials. To define schemas for your trust ecosystem, follow the steps below:
 
-1. Access the API through the [Governance Cloud API](http://localhost:8100/docs).
+1. Access the API through the [Governance Cloud API](http://localhost:8200/docs).
 2. Authenticate with `governance.` + `APIKEY` role.
 3. Generate a new schema with a `POST` to the following API endpoint: `/v1/definitions/schemas`.
 
@@ -27,9 +27,9 @@ Creating new tenants in the multi-tenant environment for the various tenant type
 
 Tenants are custodial wallets created within the Trust Ecosystem's multitenant AcaPy agent. To create new tenants for your trust ecosystem, follow the steps below:
 
-1. Access the API through the [Governance Cloud API](http://localhost:8100/docs).
+1. Access the API through the [CloudAPI-Multitenant-Admin](http://localhost:8100/docs).
 2. Authenticate with `tenant-admin.` + `APIKEY` role.
-3. Create a new tenant with a `POST` to the following API endpoint: `/admin/tenants/`, using the example request body below.
+3. Create a new tenant with a `POST` to the following API endpoint: `/tenant-admin/v1/admin/tenants/`, using the example request body below.
 
 ```json
 {
@@ -62,9 +62,9 @@ An example of a successful response to create a new Issuer Tenant:
 
 Tenants, functioning as custodial wallets, are established within the Trust Ecosystem's multitenant AcaPy agent. Follow the steps below to create new tenants for your trust ecosystem:
 
-1. Access the API through [Governance Cloud API](http://localhost:8100/docs)
+1. Access the API through [CloudAPI-Multitenant-Admin](http://localhost:8100/docs)
 2. Authenticate using the `tenant-admin.`+`APIKEY` role
-3. Generate a new tenant with a `POST` request to the API endpoint `/admin/tenants/` using the request body detailed in the example below
+3. Generate a new tenant with a `POST` request to the API endpoint `/tenant-admin/v1/admin/tenants/` using the request body detailed in the example below
 
    ```json
    {
@@ -97,9 +97,9 @@ Tenants, functioning as custodial wallets, are established within the Trust Ecos
 
 Similar to Verifiers, Tenants for Holders are created within the Trust Ecosystem's multitenant AcaPy agent. Follow these steps to create new Holders for your trust ecosystem:
 
-1. Access the API through [Governance Cloud API](http://localhost:8100/docs)
+1. Access the API through [CloudAPI-Multitenant-Admin](http://localhost:8100/docs)
 2. Authenticate using `tenant-admin.`+`APIKEY` role
-3. Generate a new tenant with a `POST` to the API endpoint `/admin/tenants/` using the request body in the example below
+3. Generate a new tenant with a `POST` to the API endpoint `/tenant-admin/v1/admin/tenants/` using the request body in the example below
 
    ```json
    {
@@ -131,7 +131,7 @@ Credential definitions are expected to be created by all **_Issuers_** within th
 
 To create credential definitions through the `Transaction Endorser Protocol` for trust ecosystem _issuers_, follow the steps below:
 
-1. Access the [Cloud API Swagger UI](http://localhost:8100/docs)
+1. Access the [CloudAPI-Tenant Swagger UI](http://localhost:8300/docs)
 2. Authenticate as an Issuer using `tenant.`+`JWTKey` x-api-key
 3. Create a new schema with a `POST` to the API endpoint `/v1/definitions/credentials` using the request body illustrated in the example below.
 
@@ -158,13 +158,13 @@ To create credential definitions through the `Transaction Endorser Protocol` for
 
 To query entries in the Trust Registry, adhere to the following steps:
 
-1. Access the [Cloud API Swagger UI](http://localhost:8100/docs)
+1. Access the [CloudAPI-Public Swagger UI](http://localhost:8400/docs)
 2. Authenticate as an Issuer using `tenant.`+`JWTKey` role
 
    >NOTE: The Trust Registry is currently public and accessible to anyone on the internet
 
 3. The trust-registry has 5 GET endpoints:
-   - `GET`  `/trust-registry/schemas` will return all schemas on the trust registry
+   - `GET`  `/v1/trust-registry/schemas` will return all schemas on the trust registry
 
      Response:
 
@@ -197,7 +197,7 @@ To query entries in the Trust Registry, adhere to the following steps:
     ]
     ```
 
-   - `GET` `/trust-registry/schemas/{schema_id}` will return the schema based on id passed
+   - `GET` `/v1/trust-registry/schemas/{schema_id}` will return the schema based on id passed
 
      Response:
 
@@ -210,7 +210,7 @@ To query entries in the Trust Registry, adhere to the following steps:
     }
     ```
 
-   - `GET` `/trust-registry/actors` will return all actors on the trust registry
+   - `GET` `/v1/trust-registry/actors` will return all actors on the trust registry
    - Optionally one of the following query parameters can be passed to get a specific actor:
      - `actor_did`
      - `actor_id`
@@ -251,5 +251,5 @@ To query entries in the Trust Registry, adhere to the following steps:
     ]
     ```
 
-   - `GET` `/trust-registry/actors/issuers` will return all actors with `issuer` as a role
-   - `GET` `/trust-registry/actors/verifiers` will return all actors with `verifier` as a role
+   - `GET` `/v1/trust-registry/actors/issuers` will return all actors with `issuer` as a role
+   - `GET` `/v1/trust-registry/actors/verifiers` will return all actors with `verifier` as a role

docs/Quick Start Guide.md

@@ -44,9 +44,11 @@ This guide provides a simple walkthrough for starting, managing, and stopping a
 
 Once the project is running, you'll have access to several services via Swagger interfaces. These can be found at the following URLs:
 
-- [ACA-Py CloudAPI Admin](http://localhost:8100/docs)
+- [CloudAPI-Multitenant-Admin](http://localhost:8100/docs)
+- [CloudAPI-Governance](http://localhost:8200/docs)
+- [CloudAPI-Tenant](http://localhost:8300/docs)
+- [CloudAPI-Public](http://localhost:8400/docs)
 - [ACA-Py Governance Agent Admin](http://localhost:3021)
-- [ACA-Py CloudAPI Multitenant](http://localhost:8100/docs)
 - [ACA-Py Multitenant Agent Admin](http://localhost:4021)
 - [Webhooks](http://localhost:3010/docs)
 - [Trust Registry](http://localhost:8001/docs)

docs/README.md

@@ -11,9 +11,16 @@
 
 ## First Steps
 
-After spinning up the containers following the [Quick Start Guide](Quick%20Start%20Guide.md), you are ready to rumble. Navigating to the [Swagger UI](http://localhost:8100/docs/) provides a good overview of the intended functionalities. You'll see that there are `generic` endpoints for common actions, wallet specific actions, and admin actions. On top of that, you'll find trust registry and webhooks endpoints.
+After spinning up the containers following the [Quick Start Guide](Quick%20Start%20Guide.md), you are ready to rumble. Navigating to the **Swagger UI** :
 
->NOTE: Regardless of the multitude of containers and mechanisms running, [CloudAPI](http://localhost:8100) and its [Swagger UI](http://localhost:8100/docs) are the main interaction points intended between clients and the stack. This should be the only endpoint clients should interact with. There is no need (and no intention to allow) for clients to directly interact with the webhooks or trust registry container. For a production deployment or a close-to-production/smoke-testing deployment, you are well advised to only expose this endpoint to clients and leave all other endpoints unexposed to the outside world.
+- [CloudAPI-Multitenant-Admin](http://localhost:8100/docs)
+- [CloudAPI-Governance](http://localhost:8200/docs)
+- [CloudAPI-Tenant](http://localhost:8300/docs)
+- [CloudAPI-Public](http://localhost:8400/docs)
+
+ provides a good overview of the intended functionalities. You'll see that there are endpoints for common actions, wallet specific actions, and admin actions. On top of that, you'll find trust registry and webhooks endpoints.
+
+>NOTE: Regardless of the multitude of containers and mechanisms running in **CloudAPI**, its aforementioned Swagger UI's are the main interaction points intended between clients and the stack. This should be the only endpoints clients should interact with. There is no need (and no intention to allow) for clients to directly interact with the webhooks or trust registry container. For a production deployment or a close-to-production/smoke-testing deployment, you are well advised to only expose this endpoint to clients and leave all other endpoints unexposed to the outside world.
 
 ### Using the Swagger UI
 

docs/Webhooks.md

@@ -81,11 +81,11 @@ How this works is that either procedure instantiates a client connecting to the
 
 There are five different endpoints for listening to server-sent events (SSE).
 
-- `GET` `/sse/{wallet_id}`
-- `GET` `/sse/{wallet_id}/{topic}`
-- `GET` `/sse/{wallet_id}/{topic}/{desired_state}`
-- `GET` `/sse/{wallet_id}/{topic}/{field}/{field_id}`
-- `GET` `/sse/{wallet_id}/{topic}/{field}/{field_id}/{desired_state}`
+- `GET` `/v1/sse/{wallet_id}`
+- `GET` `/v1/sse/{wallet_id}/{topic}`
+- `GET` `/v1/sse/{wallet_id}/{topic}/{desired_state}`
+- `GET` `/v1/sse/{wallet_id}/{topic}/{field}/{field_id}`
+- `GET` `/v1/sse/{wallet_id}/{topic}/{field}/{field_id}/{desired_state}`
 
 Valid topics are same as noted above.
 

docs/examples/1. Onboarding.md

@@ -1,6 +1,6 @@
 # 1: Onboarding Tenants
 
-When onboarding users, also referred to as tenants or wallets, you need to use the `tenant-admin` role. Below, you will find the curl commands used to create an `Issuer`, `Verifier` and a `Holder`. If you are using the [Swagger UI](http://localhost:8100/docs) to do the onboarding, just use the JSON in the field marked with `-d` in the curl commands.
+When onboarding users, also referred to as tenants or wallets, you need to use the `tenant-admin` role. Below, you will find the curl commands used to create an `Issuer`, `Verifier` and a `Holder`. If you are using the [CloudAPI-Multitenant-Admin Swagger UI](http://localhost:8100/docs) to do the onboarding, just use the JSON in the field marked with `-d` in the curl commands.
 
 The difference between an `Issuer`, `Verifier` and `Holder` is that issuers and verifiers have privileged roles, and are therefore written to the trust registry, allowing them to issue credentials and to verify proof requests in our ecosystem. A holder is a regular tenant without a role, and therefore cannot act as an issuer or verifier. They are all "tenants", and therefore each will have a tenant access token.
 
@@ -10,7 +10,7 @@ The difference between an `Issuer`, `Verifier` and `Holder` is that issuers and
 
 ```bash
 curl -X 'POST' \
-  'http://localhost:8100/v1/admin/tenants' \
+  'http://localhost:8100/tenant-admin/v1/admin/tenants' \
   -H 'accept: application/json' \
   -H 'Content-Type: application/json' \
   -H 'x-api-key: tenant-admin.adminApiKey' \
@@ -45,7 +45,7 @@ The `access_token` is what must be used as x-api-key to act as this tenant.
 
 ```bash
 curl -X 'POST' \
-  'http://localhost:8100/v1/admin/tenants' \
+  'http://localhost:8100/tenant-admin/v1/admin/tenants' \
   -H 'accept: application/json' \
   -H 'Content-Type: application/json' \
   -H 'x-api-key: tenant-admin.adminApiKey' \
@@ -79,7 +79,7 @@ Response:
 
 ```bash
 curl -X 'POST' \
-  'http://localhost:8100/v1/admin/tenants' \
+  'http://localhost:8100/tenant-admin/v1/admin/tenants' \
   -H 'accept: application/json' \
   -H 'Content-Type: application/json' \
   -H 'x-api-key: tenant-admin.adminApiKey' \

docs/examples/2. Create Schema.md

@@ -4,7 +4,7 @@ Only the `Governance` role can create Schemas. Note the `x-api-key` used in the
 
 ```bash
 curl -X 'POST' \
-  'http://localhost:8100/v1/definitions/schemas' \
+  'http://localhost:8200/v1/definitions/schemas' \
   -H 'accept: application/json' \
   -H 'Content-Type: application/json' \
   -H 'x-api-key: governance.adminApiKey' \

docs/examples/3. Create Credential Definition.md

@@ -4,7 +4,7 @@ Once a schema has been created by the governance agent, the `Issuer` can create
 
 ```bash
 curl -X 'POST' \
-  'http://localhost:8100/v1/definitions/credentials' \
+  'http://localhost:8300/v1/definitions/credentials' \
   -H 'accept: application/json' \
   -H 'Content-Type: application/json' \
   -H 'x-api-key: tenant.<Issuer token>' \

docs/examples/4. Create Connection with Issuer.md

@@ -10,7 +10,7 @@ As the `Issuer` we create a connection invitation.
 
 ```bash
 curl -X 'POST' \
-  'http://localhost:8100/v1/connections/create-invitation' \
+  'http://localhost:8300/v1/connections/create-invitation' \
   -H 'accept: application/json' \
   -H 'Content-Type: application/json' \
   -H 'x-api-key: tenant.<Issuer token>' \
@@ -48,7 +48,7 @@ The `Holder` accepts the connection by using the `invitation` object above, and
 
 ```bash
 curl -X 'POST' \
-  'http://localhost:8100/v1/connections/accept-invitation' \
+  'http://localhost:8300/v1/connections/accept-invitation' \
   -H 'accept: application/json' \
   -H 'Content-Type: application/json' \
   -H 'x-api-key: tenant.<Holder token>' \