Replace redundant frontmatter with basic Markdown heading

Author: spikeheap

docs/api-specifications/accounts-api.md

@@ -1,12 +1,9 @@
----
-id: accounts-api
-title: Accounts API
----
+# Accounts API
 
 ## Purpose
-To identify all information to be captured with regards to the Accounts domain. 
-As part of our solution we are proposing to develop an Account entity and API that will serve accounts related data for our housing streams and any other projects that may require information relating to an account. This means that we can offer a deeper, more citizen-centric self-service capability, enabling even more service transactions to be carried out online. 
-For the purposes of establishing context, the definition of an account as it relates to this entity is a record of a financial basis that links a user to a service. 
+To identify all information to be captured with regards to the Accounts domain.
+As part of our solution we are proposing to develop an Account entity and API that will serve accounts related data for our housing streams and any other projects that may require information relating to an account. This means that we can offer a deeper, more citizen-centric self-service capability, enabling even more service transactions to be carried out online.
+For the purposes of establishing context, the definition of an account as it relates to this entity is a record of a financial basis that links a user to a service.
 
 ## Functions
 - Accounts - Account information relating to a person or organisation.  This could be for a person’s rent account, benefit account or any other account a person (or organisation) may hold with the council.
@@ -63,7 +60,7 @@ Accounts workshop - https://ideaflip.com/b/75dgi3rx6h2t/
                         "type": "service charges",
                         "frequency":"weekly",
                         "amount":100.20”
-                    } 
+                    }
                 ],
             "tenure": {
                 "tenancyId": 31254,
@@ -116,7 +113,7 @@ Accounts workshop - https://ideaflip.com/b/75dgi3rx6h2t/
             “primaryTenants”:[
                 “fullName”:””,
                 “fullName”:””
-            ],            
+            ],
             “fullAddress”,”1 Hillman Street, Hackney, E8 1DY”
             },
             }
@@ -202,7 +199,7 @@ Accounts workshop - https://ideaflip.com/b/75dgi3rx6h2t/
 5. PATCH **/accounts/{id}**
 
     **Function:** Updates a person’s account details
-    
+
     **Request Payload:**
     ```
     {
@@ -240,7 +237,7 @@ Accounts workshop - https://ideaflip.com/b/75dgi3rx6h2t/
 ## Properties/Column Mappings
 The following db columns have been identified as common and useful in the context of an account.
 
-| Name | Type | Table Field Name | Description | 
+| Name | Type | Table Field Name | Description |
 |------|------|------------------|-------------|
 | Id | UUID | id | A unique id in the database |
 | TargetId | String | target_id | A reference to the person holding this account|
@@ -281,7 +278,7 @@ The following db columns have been identified as common and useful in the contex
 
 
 ## Other considerations
-- How do we reflect positive and negative activities on an account?  
+- How do we reflect positive and negative activities on an account?
 - Do we need to supply an account balance at a specific date? - Let’s not do this.
 - Do we want to have a further breakdown within this API of what makes up an account balance?
 
@@ -294,4 +291,4 @@ The following db columns have been identified as common and useful in the contex
 ![Accounts API component architecture](./doc-images/accounts_api_component_architecture.png)
 
 ## Event Driven Architecture
-![Accounts API event driven architecture](./doc-images/accounts_event_driven_arch.png)
+![Accounts API event driven architecture](./doc-images/accounts_event_driven_arch.png)

docs/api-specifications/activities_api.md

@@ -1,7 +1,4 @@
----
-id: activities_api
-title: Activity History API
----
+# Activity History API
 
 ## Purpose:
 To identify all information to be captured with regards to the Activities(Record logging) domain.

docs/api-specifications/asessment_process.md

@@ -1,8 +1,4 @@
----
-id: assessment_process
-title: Assessment Process
-
----
+# Assessment Process
 ## Purpose
 The purpose of this process is to provide a clear,open and  consistent method of providing new and amended API specifications, evaluating them and getting them published in a way that is easy for a wider audience to access.
 

docs/api-specifications/asset_info.md

@@ -1,7 +1,4 @@
----
-id: asset_info
-title: Asset Information API
----
+# Asset Information API
 
 ## Purpose
 To identify all information to be captured with regards to the Core-Asset domain.
@@ -31,7 +28,7 @@ We have agreed on a flexible approach to following HACT standards for Asset info
 - I can find if any facilities are linked to the property.
 - I can direct the required repairs information to the team.
 
-** As a Repairs service user I would like to see what type of property it is so that: **  
+** As a Repairs service user I would like to see what type of property it is so that: **
 - I can decide what action they can take. For example: if it is a house and the roof is leaking then it will be a house repair similarly if it is a block then it will be a block repair.
 - I can find out if the property comes under new build and direct the required team to take action.
 
@@ -53,7 +50,7 @@ We have agreed on a flexible approach to following HACT standards for Asset info
 - I can find out the rent group of the property (HRA information).
 
 
-** As a Repairs/Tenancy and Leaseholder service user I need to know the LLPG reference so that: **  
+** As a Repairs/Tenancy and Leaseholder service user I need to know the LLPG reference so that: **
 - I can identify the location of the property.
 - I can see the status of the property (whether the property belongs to a block/estate etc)
 
@@ -95,7 +92,7 @@ endpoints are relevant
 ** As an application support analyst**
  I need to understand the queries being used by the API so that I can deal with support requests accordingly and resolve the potential issues in the underlying data.
 
-** As a data analyst I need to connect to the API via Qlik so that: **  
+** As a data analyst I need to connect to the API via Qlik so that: **
 data is easy to interpret and available for further reporting purposes.
 
 ** As a data analyst I need to know the LLPG reference so that: **
@@ -390,7 +387,7 @@ Not found
 
        {
        "DevErrorMessages  ": ["validation errors"],
-       "UserErrorMessage": "Your item could not be updated for the following  
+       "UserErrorMessage": "Your item could not be updated for the following
               reasons..."
        }
 500
@@ -466,7 +463,7 @@ Not found
        "rootAsset": "6f22e9ae-3e8a-4e0e-af46-db02eb87f8e6",
     }
 ```
- 
+
  **Response:**
 
  Code 200 OK returning the [full payload](#example-full-payload).

docs/api-specifications/configuration.md

@@ -1,8 +1,4 @@
----
-id: configuration
-title: Configuration
-
----
+# Configuration
 
 ## Purpose
 
@@ -32,7 +28,7 @@ There are a few options regarding what the boundary is for defining and retrievi
 
 ## Our users and their needs:
 
-** As a consumer I need to have an API specification (e.g. Swagger doc, README), so that: **  
+** As a consumer I need to have an API specification (e.g. Swagger doc, README), so that: **
 - I can have a clear understanding of the endpoints which are available
 - I know what the requests and responses should look like
 - Endpoints:

docs/api-specifications/contact_details.md

@@ -1,11 +1,8 @@
----
-id: contact_details
-title: Contact Details API
----
+# Contact Details API
 
 ## Purpose
 
-The purpose of this document is to propose the implementation of a Contact Details microservice to interact with contact details data we hold for a person/organization. In the initial implementation, the microservice will focus on the Housing domain, but it should be built in a reusable way so it can be extended to other service areas in the future.  
+The purpose of this document is to propose the implementation of a Contact Details microservice to interact with contact details data we hold for a person/organization. In the initial implementation, the microservice will focus on the Housing domain, but it should be built in a reusable way so it can be extended to other service areas in the future.
 
 - Contact details can be related to a person/organization and include one or multiple (both historical and current)
 - email address

docs/api-specifications/contact_us.md

@@ -1,8 +1,4 @@
----
-id: contact_us
-title: Contact Our Development Team
-
----
+# Contact Our Development Team
 
 ## For any enquiries please speak to:
 

docs/api-specifications/contracts_api.md

@@ -1,10 +1,7 @@
----
-id: contracts_api
-title: Contracts API
----
+# Contracts API
 ## Purpose
 
-The temporary housing platform requires an agreement in place which provides a model representing the details to enbable the use of the property by Hackney contractually. 
+The temporary housing platform requires an agreement in place which provides a model representing the details to enbable the use of the property by Hackney contractually.
 
 As part of our solution, we are proposing to develop the Contracts API. This API will be designed to keep the asset and people models clean and provide a link between these objects as well as holding all the contractual information between the parties.
 
@@ -26,7 +23,7 @@ This API was discussed at TDA 25/05/22 off the back of the need to move data off
 
 **Endpoint Status**: PROPOSED
 
-**Purpose:**  
+**Purpose:**
 Gets one or more Contracts from the Contract table.  Requests can be made by specifying a ref path parameter or searching for Tenures based on a series of parameters.
 
 **Endpoint URL's:**
@@ -222,7 +219,7 @@ Gets one or more Contracts from the Contract table.  Requests can be made by spe
 }
 ```
 - /contracts/{contractId}
- 
+
  Get individual contract
 
 **Response:**
@@ -433,4 +430,4 @@ Updates a new Contract
 Removes a new Contract
 
 **Endpoint URL's:**
-- /contracts/{contractId}
+- /contracts/{contractId}

docs/api-specifications/equality-information-api.md

@@ -1,7 +1,4 @@
----
-id: equality-information-api
-title: Equality Information API
----
+# Equality Information API
 
 ## Purpose
 To identify all information to be captured with regards to the equality information domain related to a person.

docs/api-specifications/housing_search.md

@@ -1,7 +1,4 @@
----
-id: housing_search
-title: Housing Search API
----
+# Housing Search API
 ## Purpose
 
 To define how a new proposed search service will work. The microservice will be reusable across different housing services and will provide searching functionality for both people and properties. The service will make use of ElasticSearch as a search engine (for performance benefits and to support free-text and fuzzy search) and will aggregate assets and people data for ease of search purposes.
@@ -25,24 +22,24 @@ ElasticSearch will be updated by a Lambda function, holding business logic, that
 - I want the ability to filter the details of the results returned in an asset search
 - So that I can easily look through the different results and find accommodation matching my requirements
 
-### Searching 
+### Searching
 
 Searching is achieved by providing `searchText` as a string parameter.
 
 **Search by :**
 1. Person - First name, Middle name, Last name
 2. Asset - Address line 1, Postcode, Asset type
-3. Tenure - Payment Reference, FullAddress of TenuredAsset , Household Members FullName  
+3. Tenure - Payment Reference, FullAddress of TenuredAsset , Household Members FullName
 4. Transactions - Sender name, Transaction Type, Payment Reference, Bank Account Number, Transaction Date, Transaction Amount
 5. Staff - first Name, last name, email
 
 ### Filtering
 
 Filter parameters will be added to
-`/search/assets/all` and searchText will be optional giving the ability to filter of specific fields without the need to search by text. 
+`/search/assets/all` and searchText will be optional giving the ability to filter of specific fields without the need to search by text.
 We propose to enforce a rule of at least one parameter to mitigate against the API being abused and returning every asset.
 
-**Filter by :** 
+**Filter by :**
 1. Asset - assetStatus, numberOfBedrooms, numberOfBedSpaces, numberOfCots, groundFloor, privateBathroom, privateKitchen, stepFree, isTemporaryAccomodation, parentAssetId
 
 ### Considerations
@@ -58,7 +55,7 @@ We propose to enforce a rule of at least one parameter to mitigate against the A
 
 https://app.swaggerhub.com/apis/Hackney/housingSearchApi/1.0.0
 
-## Architecture diagram 
+## Architecture diagram
 
 https://drive.google.com/file/d/1UYnYkGrOn83KXZgoCcVwb8tVg5MNehRz/view
 
@@ -116,4 +113,4 @@ Allows to search on fields which do not exist only on platform APIs. It allows t
 
 We discussed the need for filter parameters without searchText so that we can refine lists based purely on the filter params.
 It was decided to use the `/search/assets/all` to produce this outcome.
-Reference doc can be found [here](https://docs.google.com/document/d/1ZMa2dKqV5XfgFiyA0RL9hCqy1QLoo53VnOJPpGxQA_s/edit#heading=h.dx6cih64yr6k)
+Reference doc can be found [here](https://docs.google.com/document/d/1ZMa2dKqV5XfgFiyA0RL9hCqy1QLoo53VnOJPpGxQA_s/edit#heading=h.dx6cih64yr6k)