Update gatsby to v5

content-new/docs/api.mdx

@@ -0,0 +1,5 @@
+---
+title: "API"
+order: 1
+metaTitle: "API"
+---

content-new/docs/api/overview.mdx

@@ -0,0 +1,8 @@
+---
+title: "Overview"
+order: 1
+---
+
+## Overview
+
+For GET requests, you can use one or more query parameters. In the response we will return a HTTP status code. Some endpoints return JSON bodies that include HAL (Hypertext Application Language) links.

content-new/docs/api/parameters.json

@@ -0,0 +1,38 @@
+{
+  "authorization": {
+    "name": "Authorization",
+    "type": "string",
+    "location": "header",
+    "required": true,
+    "methods": ["get", "post", "patch", "delete", "request"],
+    "body": "<p>Your API token retrieved from the portal.</p>",
+    "example": "curl -v -X GET https://institution-api-sim.clearbank.co.uk/v3/Accounts \\ \n -H \"Authorization: Bearer <<your api token>> \""
+  },
+  "digitalSignature": {
+    "name": "DigitalSignature",
+    "type": "string",
+    "location": "header",
+    "required": true,
+    "methods": ["post", "patch", "delete", "request"],
+    "body": "<p>This is a hash of the request body signed with your private key.</p>",
+    "example": null
+  },
+  "xRequestId": {
+    "name": "X-Request-Id",
+    "type": "string",
+    "location": "header",
+    "required": true,
+    "methods": ["post", "patch", "delete", "request"],
+    "body": "<p>This is what we use for idempotency and enables a duplication check. You generate this identifier which must be unique for any subsequent requests sent for at least 24 hours after the initial request was sent.</p><p> If an <code>X-Request-Id</code> Header is not supplied, or is invalid, a <code>400</code>:Bad Request HTTP status code response will be returned.</p><p>If ClearBank&reg; detects a duplicate, a <code>409</code>: Conflict HTTP status code response will be returned.<p>",
+    "example": null
+  },
+  "xCorrelationId": {
+    "name": "X-Correlation-Id",
+    "type": "string",
+    "location": "header",
+    "required": false,
+    "methods": ["response"],
+    "body": "<p>This is a unique identifier generated by ClearBank&reg; for the request. ClearBank&reg; would require this identifier for troubleshooting purposes. Therefore, it is recommended you store this response header.</p>",
+    "example": null
+  }
+}

content-new/docs/api/parameters.ts

@@ -0,0 +1,9 @@
+export interface Parameter {
+  name: string
+  type: string
+  location: string
+  required: boolean
+  methods: string[]
+  body: string
+  example?: string
+}

content-new/docs/api/support-lify-cycle.mdx

@@ -0,0 +1,24 @@
+---
+title: "Support life cycle"
+order: 4
+---
+
+import Callout from "src/components/callout";
+
+## Support life cycle
+
+All endpoints and webhooks released by ClearBank will be supported for a minimum of 12 months before these are reviewed for withdrawal.
+
+Following the initial 12-month period, all endpoints and webhooks will be reviewed every 6 months. This review will allow us to decide whether an endpoint or webhook should be withdrawn.
+If we decide to withdraw an endpoint or webhook, you will be issued a written notification 6 months prior to the date from which that version will no longer be supported.
+
+This means that all endpoints and webhooks will ideally be supported for a minimum of 18 months (this includes initial support for 12 months along with a 6-month advance notice period prior to withdrawal).
+
+The only exception to this approach would be for us to withdraw an endpoint or webhook sooner due to regulatory or scheme obligations, or in case of API incompatibility.
+
+As a matter of practice, you are urged to ensure that you upgrade to the latest version of an endpoint or webhook as soon as one is released.
+
+<Callout colour="blue">
+  Any changes to our API versioning approach will be communicated to you at
+  least 6 months prior to implementation.
+</Callout>

content-new/docs/api/versioning.mdx

@@ -0,0 +1,17 @@
+---
+title: "Versioning"
+order: 3
+---
+
+## Versioning
+
+Providing developers with a seamless integration experience is at the core of our API versioning approach. We work in an agile environment and iteratively release the latest versions of individual endpoints and webhooks.
+
+We follow the Semantic Versioning specification (https://semver.org/):
+
+- Internally, we update minor and patch versions whenever we add optional functionality and backwards compatible changes.
+- Whenever we introduce a breaking change, we will provision a new major version of the API.
+
+All API endpoints are versioned through the URI path; for example, /v2/Accounts. Endpoint details can be found on the Developer Portal.
+
+A backwards compatible change does not affect existing integrations for tolerant readers, for example the addition of new optional fields for an API request, response or a webhook payload. A breaking change could affect existing integrations, for example the addition of a new mandatory field or removal of an existing field.

content-new/docs/embedded-banking.mdx

@@ -0,0 +1,5 @@
+---
+title: "Embedded Banking"
+order: 5
+metaTitle: "Embedded Banking"
+---

content-new/docs/embedded-banking/fscs-protected-deposits.mdx

@@ -0,0 +1,59 @@
+---
+title: "FSCS protected deposites"
+order: 1
+---
+
+import EndpointBlock from "src/components/endpoint-block";
+import * as CONSTANTS from "./retail-customers.constants"
+
+## FSCS protected deposites
+
+FSCS-protected deposits are a part of our embedded banking proposition. An FSCS-protected deposit is a physical account held with ClearBank and is only available to our embedded banking customers for the purpose of sending and/or receiving payments. The balance of an FSCS-protected deposit is held by ClearBank and can be viewed via the ClearBank Portal and the API. Additionally, FSCS-protected deposits are reconciled for you by ClearBank.
+
+<EndpointBlock
+  type="post"
+  title="Create a retail customer"
+  description={CONSTANTS.postCustomersRetailDescription}
+  endpoints={[
+    {
+      path: "/v1/customers/retail",
+      version: "1.0.Retail"
+    }
+  ]}
+/>
+
+<EndpointBlock
+  type="post"
+  title="Create an account"
+  endpoints={[
+    {
+      path: "/v4/Accounts",
+      version: "4.0.Sterling",
+      webhooks: [
+        'account-created-webhook-v1'
+      ]
+    }
+  ]}
+/>
+
+<EndpointBlock
+  type="patch"
+  title="Update an existing retail customer’s personal information"
+  endpoints={[
+    {
+      path: "/v1/customers/retail/{customerId}",
+      version: "1.0.Retail"
+    }
+  ]}
+/>
+
+<EndpointBlock
+  type="put"
+  title="Update an existing retail customer’s address"
+  endpoints={[
+    {
+      path: "/v1/customers/retail/{customerId}/currentaddress",
+      version: "1.0.Retail"
+    }
+  ]}
+/>

content-new/docs/embedded-banking/retail-customers.constants.tsx

@@ -0,0 +1,9 @@
+import React from "react";
+
+export const postCustomersRetailDescription = (
+  <>
+    <p>
+      Once you have created a retail customer, create a new FSCS protected current account using the retail customer’s unique Id.
+    </p>
+  </>
+);

content-new/docs/gbp-accounts.mdx

@@ -0,0 +1,5 @@
+---
+title: "GBP Accounts"
+order: 2
+metaTitle: "GBP Accounts"
+---

content-new/docs/gbp-accounts/account-types.mdx

@@ -0,0 +1,31 @@
+---
+title: "Account types"
+order: 1
+---
+
+import Callout from "src/components/callout";
+
+## Overview
+
+There are several types of accounts that can be created. Which you should use will depend on your agreement with ClearBank, and the purpose of the account.
+
+When you join ClearBank you are given these five accounts by default:
+
+![Image showing your initial set of accounts](/assets/images/Accounts-Day1.svg "Initial set of accounts")
+
+Your **institution account** is not an account of its own; it is a superset of all your other accounts. Your **operating account** holds your own operational funds and your **general segregation account** can be used for multiple customers' funds that need to be safeguarded. Note that a segregation account should not be used to hold any of your own funds.
+
+You can create additional operational and safeguarding accounts as needed. You can also create virtual accounts within a general segregation account or a general client account.  
+
+![Image showing correct usage of usageType/kind](/assets/images/Accounts-Usage.svg "Correct usage of usageType/kind")
+
+It is important to **select the correct usage for the account when you create it, as this cannot be amended later**. The account usage determines, for example, whether the account can be used for safeguarding funds.
+
+When you create a real account:
+- For sterling accounts - use the **UsageType** field to select YourFunds, SegregatedDesignated, or SegregatedGeneral, as shown above. If you need to create a client account, first create a safeguarding account through the API, then contact client services through FreshDesk to have the type transferred to a client account. 
+
+- For multi-currency accounts - use the **Kind** field to select YourFunds, DesignatedSegregated,  GeneralSegregated, DesignatedClient, or GeneralClient. 
+
+The UsageType or Kind value determines the autogenerated prefix assigned to the account, for example, 'Gen Seg Acc Retl'. The prefixes for each account are shown in the figure above.
+
+The endpoints described below are used to manage sterling accounts. For multi-currency accounts, see  [Multi-currency Accounts](./multicurrency-accounts).

content-new/docs/gbp-accounts/bacs-payment-data.mdx

@@ -0,0 +1,4 @@
+---
+title: "BACS Payment data"
+order: 4
+---