### API Overview: The Griffin API

Source: https://docs.griffin.com/redocusaurus/plugin-redoc-0.yaml

## Introduction

The Griffin API is based on [REST](https://en.wikipedia.org/wiki/Representational_state_transfer).
It has resource-oriented URLs, accepts [JSON](https://www.json.org/json-en.html)-encoded request bodies, returns [JSON](https://www.json.org/json-en.html)-encoded responses, and uses standard HTTP response verbs and response codes.

Our API deviates from strict RESTful principles if it makes sense to do so, such as when we enforce tighter access controls around certain operations.
For example, when closing a bank account: rather than send a PATCH request to the [bank account](#tag/Bank-accounts) resource to update it's status to `"closed"`, we provide a dedicated account closure resource.

Anyone can [create an account](https://app.griffin.com/register) with Griffin and try out our API in [sandbox mode](/docs/guides/sandbox-vs-live-mode).

New to Griffin? Check out our [getting started guide](/docs/guides/get-started-with-the-api).

## Navigation

Our API is designed to be navigated programmatically. When you request any resource, you will find the URLs for related resources in the response body.

The API is structured as a tree with your [organization](#tag/Organizations) at the top. Everything that you own will be a sub-resource of your organization.

To bootstrap the navigation process, request the [index](#tag/Navigation/paths/~1v0~1index/get) endpoint: the response will contain your `organization-url`.

For a walkthrough, see our [getting started guide](/docs/guides/get-started-with-the-api).

## Pagination

Our list APIs support pagination (e.g. [list bank accounts](#tag/Bank-accounts/paths/~1v0~1organizations~1%7Borganization-id%7D~1bank~1accounts/get) and [list payments](#tag/Payments/paths/~1v0~1bank~1accounts~1%7Bbank-account-id%7D~1payments/get)).
By default, a list API returns up to 25 results. If there are more results available, the response payload will include links to the previous/next pages.

### Change page size

You can request a different number of results (between 1 and 200, inclusive) by using the `page[size]` query parameter:

```
GET /v0/organizations/:id/bank/accounts?page[size]=100
```

### Navigating between pages

List responses will include a `links` object with `prev` and `next` attributes, as shown below.
Perform a GET request to the value of the attribute to fetch the previous/next page of results.

```
{
  "accounts": [
    // ...
  ],
  "links": {
    "prev": "/v0/organizations/og.IG9yZ2FuaXphdGlvbi1pZA/bank/accounts?page[before]=djE6WxSPxfYUTnCU9XtWzj9gGA",
    "next": "/v0/organizations/og.IG9yZ2FuaXphdGlvbi1pZA/bank/accounts?page[after]=djE6aw79PXZySUOL16LD8HRJ3A"
  }
}

```
If there is no previous or next page available, the value of the attribute will be  null.

Any other query parameters included in the initial request will also be included in the response payload's links.
If you want to change parameters (see [filtering and sorting](#section/Filtering-and-sorting)), request the first page and follow the links from there.

## Filtering and sorting

### Sort results

By default, resources will be listed in descending order, usually based on the `created-at` attribute.
You can change the sorting behaviour of a list of results by using the `sort` query parameter.

For example, to list bank accounts in ascending order (oldest first):

```
GET /v0/organizations/:id/bank/accounts?sort=created-at
```

To _explicitly_ sort in descending order (newest first), prefix the sort attribute with `-`:

```
GET /v0/organizations/:id/bank/accounts?sort=-created-at
```

### Filter results

Some list APIs allow you to filter the results.
Filters are expressed as nested data structures encoded into query parameters.
For example, you can list bank accounts that are in either the `opening` or `open` state with:

```
GET /v0/organizations/:id/bank/accounts?filter[account-status][in][]=opening&filter[account-status][in][]=open
```

Similarly, you can list legal persons with a specific `application-status`:

```
GET /v0/organizations/:id/legal-persons?filter[application-status][eq]=accepted
```

### Include resources

Some list APIs allow you to include associated resources in the response, reducing the number of requests needed to fetch related data.
For instance, when listing bank accounts, you can include each bank account's beneficiary legal person by using the `include` query parameter:

```
GET /v0/organizations/:id/bank/accounts?include=beneficiary
```

The response returns the usual list of bank accounts, but it will also have an `included` object with a `legal-persons` attribute:

```
{
  "accounts": [
    // ...
  ],
  "links": {
    // ...
  }
  "included": {
    "legal-persons": [
      // ...
    ]
  }
}
```

Check the documentation for each list API to see all options for sorting and filtering

## Request limits

Each organization is allowed up to 50 concurrent (in-flight) API requests. Exceeding this threshold results in a 429 - Too Many Requests response. Upon receiving a 429 response, you should implement a backoff strategy, pausing to allow your outstanding requests to complete before attempting new requests. To manage your request rate effectively and avoid surpassing this limit, consider using a controlled approach such as a finite pool of threads or workers.

The Submit Payment API imposes an additional limit: there may be at most 3 concurrent requests to submit a payment from a single bank account. For more details, see the [Submit Payment API documentation](#tag/Payments/paths/~1v0~1payments~1%7Bpayment-id%7D~1submissions/post).

## Versioning

The Griffin API is versioned via a prefix in the URL.
The current version is v0.
An example endpoint is: https://api.griffin.com/v0/index.

We will not break your integration with a particular version for as long as we support that version.
If we release a new version, you will have 12 months to upgrade to it.

```yaml
# The Griffin API
# Version: 1.0.0

## Introduction

The Griffin API is based on [REST](https://en.wikipedia.org/wiki/Representational_state_transfer).
It has resource-oriented URLs, accepts [JSON](https://www.json.org/json-en.html)-encoded request bodies, returns [JSON](https://www.json.org/json-en.html)-encoded responses, and uses standard HTTP response verbs and response codes.

Our API deviates from strict RESTful principles if it makes sense to do so, such as when we enforce tighter access controls around certain operations.
For example, when closing a bank account: rather than send a PATCH request to the [bank account](#tag/Bank-accounts) resource to update it's status to `"closed"`, we provide a dedicated account closure resource.

Anyone can [create an account](https://app.griffin.com/register) with Griffin and try out our API in [sandbox mode](/docs/guides/sandbox-vs-live-mode).

New to Griffin? Check out our [getting started guide](/docs/guides/get-started-with-the-api).

## Navigation

Our API is designed to be navigated programmatically. When you request any resource, you will find the URLs for related resources in the response body.

The API is structured as a tree with your [organization](#tag/Organizations) at the top. Everything that you own will be a sub-resource of your organization.

To bootstrap the navigation process, request the [index](#tag/Navigation/paths/~1v0~1index/get) endpoint: the response will contain your `organization-url`.

For a walkthrough, see our [getting started guide](/docs/guides/get-started-with-the-api).

## Pagination

Our list APIs support pagination (e.g. [list bank accounts](#tag/Bank-accounts/paths/~1v0~1organizations~1%7Borganization-id%7D~1bank~1accounts/get) and [list payments](#tag/Payments/paths/~1v0~1bank~1accounts~1%7Bbank-account-id%7D~1payments/get)).
By default, a list API returns up to 25 results. If there are more results available, the response payload will include links to the previous/next pages.

### Change page size

You can request a different number of results (between 1 and 200, inclusive) by using the `page[size]` query parameter:

```
GET /v0/organizations/:id/bank/accounts?page[size]=100
```

### Navigating between pages

List responses will include a `links` object with `prev` and `next` attributes, as shown below.
Perform a GET request to the value of the attribute to fetch the previous/next page of results.

```
{
  "accounts": [
    // ...
  ],
  "links": {
    "prev": "/v0/organizations/og.IG9yZ2FuaXphdGlvbi1pZA/bank/accounts?page[before]=djE6WxSPxfYUTnCU9XtWzj9gGA",
    "next": "/v0/organizations/og.IG9yZ2FuaXphdGlvbi1pZA/bank/accounts?page[after]=djE6aw79PXZySUOL16LD8HRJ3A"
  }
}

```
If there is no previous or next page available, the value of the attribute will be  null.

Any other query parameters included in the initial request will also be included in the response payload's links.
If you want to change parameters (see [filtering and sorting](#section/Filtering-and-sorting)), request the first page and follow the links from there.

## Filtering and sorting

### Sort results

By default, resources will be listed in descending order, usually based on the `created-at` attribute.
You can change the sorting behaviour of a list of results by using the `sort` query parameter.

For example, to list bank accounts in ascending order (oldest first):

```
GET /v0/organizations/:id/bank/accounts?sort=created-at
```

To _explicitly_ sort in descending order (newest first), prefix the sort attribute with `-`:

```
GET /v0/organizations/:id/bank/accounts?sort=-created-at
```

### Filter results

Some list APIs allow you to filter the results.
Filters are expressed as nested data structures encoded into query parameters.
For example, you can list bank accounts that are in either the `opening` or `open` state with:

```
GET /v0/organizations/:id/bank/accounts?filter[account-status][in][]=opening&filter[account-status][in][]=open
```

Similarly, you can list legal persons with a specific `application-status`:

```
GET /v0/organizations/:id/legal-persons?filter[application-status][eq]=accepted
```

### Include resources

Some list APIs allow you to include associated resources in the response, reducing the number of requests needed to fetch related data.
For instance, when listing bank accounts, you can include each bank account's beneficiary legal person by using the `include` query parameter:

```
GET /v0/organizations/:id/bank/accounts?include=beneficiary
```

The response returns the usual list of bank accounts, but it will also have an `included` object with a `legal-persons` attribute:

```
{
  "accounts": [
    // ...
  ],
  "links": {
    // ...
  }
  "included": {
    "legal-persons": [
      // ...
    ]
  }
}
```

Check the documentation for each list API to see all options for sorting and filtering

## Request limits

Each organization is allowed up to 50 concurrent (in-flight) API requests. Exceeding this threshold results in a 429 - Too Many Requests response. Upon receiving a 429 response, you should implement a backoff strategy, pausing to allow your outstanding requests to complete before attempting new requests. To manage your request rate effectively and avoid surpassing this limit, consider using a controlled approach such as a finite pool of threads or workers.

The Submit Payment API imposes an additional limit: there may be at most 3 concurrent requests to submit a payment from a single bank account. For more details, see the [Submit Payment API documentation](#tag/Payments/paths/~1v0~1payments~1%7Bpayment-id%7D~1submissions/post).

## Versioning

The Griffin API is versioned via a prefix in the URL.
The current version is v0.
An example endpoint is: https://api.griffin.com/v0/index.

We will not break your integration with a particular version for as long as we support that version.
If we release a new version, you will have 12 months to upgrade to it.

# Base URL: Not specified
```

--------------------------------

### GET /v0/onboarding/applications/{onboarding-application-id}

Source: https://docs.griffin.com/redocusaurus/plugin-redoc-0.yaml

Fetch an onboarding application.

```markdown
### Parameters

- **onboarding-application-id** (string, path, required)

### Responses

#### 200 - response

Empty response body

#### 401 - Requires an API key to continue

Requires an API key to continue

#### 404 - response

### Example Usage

```bash
curl -X GET "https://api.example.com/v0/onboarding/applications/{onboarding-application-id}"
```

```

--------------------------------

### GET /v0/webhooks/{webhook-id}

Source: https://docs.griffin.com/redocusaurus/plugin-redoc-0.yaml

Fetch a webhook

```markdown
### Parameters

- **webhook-id** (string, path, required)

### Responses

#### 200 - response

Empty response body

#### 401 - Requires an API key to continue

Requires an API key to continue

#### 404 - response

### Example Usage

```bash
curl -X GET "https://api.example.com/v0/webhooks/{webhook-id}"
```

```

--------------------------------

### GET /v0/verifications/{verification-id}

Source: https://docs.griffin.com/redocusaurus/plugin-redoc-0.yaml

Fetch the verification.

```markdown
### Parameters

- **verification-id** (string, path, required)

### Responses

#### 200 - response

Empty response body

#### 400 - response

#### 401 - Requires an API key to continue

Requires an API key to continue

#### 404 - response

### Example Usage

```bash
curl -X GET "https://api.example.com/v0/verifications/{verification-id}"
```

```

--------------------------------

### GET /v0/roles

Source: https://docs.griffin.com/redocusaurus/plugin-redoc-0.yaml

Yields a list of all Role resources.

```markdown
### Responses

#### 200 - response

Empty response body

### Example Usage

```bash
curl -X GET "https://api.example.com/v0/roles"
```

```

--------------------------------

### GET /v0/workflows/{workflow-id}

Source: https://docs.griffin.com/redocusaurus/plugin-redoc-0.yaml

Fetch the workflow.

```markdown
### Parameters

- **workflow-id** (string, path, required)

### Responses

#### 200 - response

Empty response body

#### 401 - Requires an API key to continue

Requires an API key to continue

#### 404 - response

### Example Usage

```bash
curl -X GET "https://api.example.com/v0/workflows/{workflow-id}"
```

```

--------------------------------

### GET /v0/bank/products/{bank-product-id}

Source: https://docs.griffin.com/redocusaurus/plugin-redoc-0.yaml

Fetches a bank account product by ID

```markdown
### Parameters

- **bank-product-id** (string, path, required)

### Responses

#### 200 - response

Empty response body

#### 401 - Requires an API key to continue

Requires an API key to continue

#### 404 - response

### Example Usage

```bash
curl -X GET "https://api.example.com/v0/bank/products/{bank-product-id}"
```

```

--------------------------------

### POST /v0/organizations/{organization-id}/onboarding/applications

Source: https://docs.griffin.com/redocusaurus/plugin-redoc-0.yaml

Create an onboarding application and submit it for processing.

  The request body must include a `workflow-url` to determine checks to be performed by the verification.
  The workflow specified determines which claims must exist for the subject profile, and any related profile (i.e. directors and people with significant control of a corporation).

  ---

  At the moment we only support 3 reliance workflows: Reliance LTD Company, Reliance Individual and Reliance Sole Trader.

  You need to provide different claims depending on the type of customer you wish to onboard via reliance.
  | LTD Company | Individual | Sole trader |
  | ----------- | ---------- | ----------- |
  | Subject profile:<br>`uk-company-register`<br>`trading-address`<br>`reliance-verification`<br><br>Related profiles:<br>`individual-identity`<br>`individual-residence`<br>`reliance-verification` | Subject profile:<br>`individual-identity`<br>`individual-residence`<br>`reliance-verification` | Subject profile:<br>`business-name`<br>`individual-identity`<br>`individual-residence`<br>`reliance-verification` |

  For more information, check out our [onboarding guides](/docs/tags/onboarding).
  

```markdown
### Parameters

- **request-create-onboarding-application** (object, body, required)
- **organization-id** (string, path, required)

### Responses

#### 201 - The created application

Empty response body

#### 400 - Responds with bad-request if the body does not conform to the schema.

Responds with bad-request if the body does not conform to the schema.

#### 401 - Requires an API key to continue

Requires an API key to continue

#### 404 - response

#### 422 - Unprocessable Entity: specific error details will be provided, if available

Unprocessable Entity: specific error details will be provided, if available

### Example Usage

```bash
curl -X POST "https://api.example.com/v0/organizations/{organization-id}/onboarding/applications"
```

```

--------------------------------

### GET /v0/legal-persons/{legal-person-id}

Source: https://docs.griffin.com/redocusaurus/plugin-redoc-0.yaml

Yields the legal-person.

```markdown
### Parameters

- **legal-person-id** (string, path, required)

### Responses

#### 200 - response

Empty response body

#### 401 - Requires an API key to continue

Requires an API key to continue

#### 404 - response

### Example Usage

```bash
curl -X GET "https://api.example.com/v0/legal-persons/{legal-person-id}"
```

```

--------------------------------

### GET /v0/webhooks/{webhook-id}/actions/test

Source: https://docs.griffin.com/redocusaurus/plugin-redoc-0.yaml

Get the status of the latest test event

```markdown
### Parameters

- **webhook-id** (string, path, required)

### Responses

#### 200 - response

Empty response body

#### 401 - Requires an API key to continue

Requires an API key to continue

#### 404 - response

### Example Usage

```bash
curl -X GET "https://api.example.com/v0/webhooks/{webhook-id}/actions/test"
```

```

--------------------------------

### GET /v0/admissions/{admission-id}

Source: https://docs.griffin.com/redocusaurus/plugin-redoc-0.yaml

Yields an admission.

```markdown
### Parameters

- **admission-id** (string, path, required)

### Responses

#### 200 - response

Empty response body

#### 400 - response

#### 401 - Requires an API key to continue

Requires an API key to continue

#### 403 - response

#### 404 - response

### Example Usage

```bash
curl -X GET "https://api.example.com/v0/admissions/{admission-id}"
```

```

--------------------------------

### GET /v0/roles/{role-id}

Source: https://docs.griffin.com/redocusaurus/plugin-redoc-0.yaml

Yields the Role resource.

```markdown
### Parameters

- **role-id** (string, path, required)

### Responses

#### 200 - response

Empty response body

#### 400 - response

#### 404 - response

### Example Usage

```bash
curl -X GET "https://api.example.com/v0/roles/{role-id}"
```

```

--------------------------------

### GET /v0/index

Source: https://docs.griffin.com/redocusaurus/plugin-redoc-0.yaml

Contains various global URL paths. Follow `api-key-url` to discover your `organization-url`.

```markdown
### Responses

#### 200 - response

Empty response body

#### 401 - Requires an API key to continue

Requires an API key to continue

### Example Usage

```bash
curl -X GET "https://api.example.com/v0/index"
```

```

--------------------------------

### GET /v0/organizations/{organization-id}/webhooks

Source: https://docs.griffin.com/redocusaurus/plugin-redoc-0.yaml

Get all webhooks for the organization

```markdown
### Parameters

- **organization-id** (string, path, required)

### Responses

#### 200 - response

Empty response body

#### 400 - response

#### 401 - Requires an API key to continue

Requires an API key to continue

### Example Usage

```bash
curl -X GET "https://api.example.com/v0/organizations/{organization-id}/webhooks"
```

```

--------------------------------

### GET /v0/users/{user-id}

Source: https://docs.griffin.com/redocusaurus/plugin-redoc-0.yaml

Get the User resource for the current user.

```markdown
### Parameters

- **user-id** (string, path, required)

### Responses

#### 200 - response

Empty response body

#### 400 - response

#### 401 - Requires an API key to continue

Requires an API key to continue

#### 404 - response

### Example Usage

```bash
curl -X GET "https://api.example.com/v0/users/{user-id}"
```

```

--------------------------------

### GET /v0/ping

Source: https://docs.griffin.com/redocusaurus/plugin-redoc-0.yaml

Check your connection to the Griffin API.

```markdown
### Responses

#### 204 - No content

Empty response body

### Example Usage

```bash
curl -X GET "https://api.example.com/v0/ping"
```

```

--------------------------------

### GET /v0/payees/{payee-id}

Source: https://docs.griffin.com/redocusaurus/plugin-redoc-0.yaml

Returns the payee details.

```markdown
### Parameters

- **payee-id** (string, path, required)

### Responses

#### 200 - response

Empty response body

#### 400 - response

#### 401 - Requires an API key to continue

Requires an API key to continue

#### 404 - response

### Example Usage

```bash
curl -X GET "https://api.example.com/v0/payees/{payee-id}"
```

```

--------------------------------

### GET /v0/submissions/{submission-id}

Source: https://docs.griffin.com/redocusaurus/plugin-redoc-0.yaml

Yields a submission.

```markdown
### Parameters

- **submission-id** (string, path, required)

### Responses

#### 200 - response

Empty response body

#### 400 - response

#### 401 - Requires an API key to continue

Requires an API key to continue

#### 403 - response

#### 404 - response

### Example Usage

```bash
curl -X GET "https://api.example.com/v0/submissions/{submission-id}"
```

```

--------------------------------

### GET /v0/verifications/{verification-id}/profiles

Source: https://docs.griffin.com/redocusaurus/plugin-redoc-0.yaml

GET a verification's profiles. A profile is the collection of claims used in a verification.

```markdown
### Parameters

- **verification-id** (string, path, required)

### Responses

#### 200 - response

Empty response body

#### 401 - Requires an API key to continue

Requires an API key to continue

#### 404 - response

### Example Usage

```bash
curl -X GET "https://api.example.com/v0/verifications/{verification-id}/profiles"
```

```

--------------------------------

### GET /v0/organizations/{organization-id}

Source: https://docs.griffin.com/redocusaurus/plugin-redoc-0.yaml

Yields the organization details

```markdown
### Parameters

- **organization-id** (string, path, required)

### Responses

#### 200 - response

Empty response body

#### 400 - response

#### 401 - Requires an API key to continue

Requires an API key to continue

#### 404 - response

### Example Usage

```bash
curl -X GET "https://api.example.com/v0/organizations/{organization-id}"
```

```

--------------------------------

### GET /v0/bank/accounts/{bank-account-id}

Source: https://docs.griffin.com/redocusaurus/plugin-redoc-0.yaml

Fetch a bank account

```markdown
### Parameters

- **bank-account-id** (string, path, required)

### Responses

#### 200 - response

Empty response body

#### 400 - response

#### 401 - Requires an API key to continue

Requires an API key to continue

#### 404 - response

### Example Usage

```bash
curl -X GET "https://api.example.com/v0/bank/accounts/{bank-account-id}"
```

```

--------------------------------

### GET /v0/security/message-signature/verify

Source: https://docs.griffin.com/redocusaurus/plugin-redoc-0.yaml

Yields the status of the http signature validation

```markdown
### Parameters

- **header-signature** (string, header, optional): Message Signatures: signature header containing a signature label with the components used to generate the signature
- **header-signature-input** (string, header, optional): Message Signatures: signature-input header containing a signature label with the components used to generate the signature

### Responses

#### 200 - response

Empty response body

### Example Usage

```bash
curl -X GET "https://api.example.com/v0/security/message-signature/verify"
```

```

--------------------------------

### GET /v0/memberships/{membership-id}

Source: https://docs.griffin.com/redocusaurus/plugin-redoc-0.yaml

Returns the [user's](#tag/Users) [membership](#tag/Memberships) information.

```markdown
### Parameters

- **membership-id** (string, path, required)

### Responses

#### 200 - response

Empty response body

#### 400 - response

#### 401 - Requires an API key to continue

Requires an API key to continue

#### 404 - response

### Example Usage

```bash
curl -X GET "https://api.example.com/v0/memberships/{membership-id}"
```

```

--------------------------------

### GET /v0/memberships/{membership-id}/roles

Source: https://docs.griffin.com/redocusaurus/plugin-redoc-0.yaml

Returns the [roles](#tag/Roles) assigned to this [membership](#tag/Memberships).

```markdown
### Parameters

- **membership-id** (string, path, required)

### Responses

#### 200 - response

Empty response body

#### 400 - response

#### 401 - Requires an API key to continue

Requires an API key to continue

### Example Usage

```bash
curl -X GET "https://api.example.com/v0/memberships/{membership-id}/roles"
```

```

--------------------------------

### GET /v0/payments/{payment-id}

Source: https://docs.griffin.com/redocusaurus/plugin-redoc-0.yaml

Yields payment details

```markdown
### Parameters

- **payment-id** (string, path, required)

### Responses

#### 200 - response

Empty response body

#### 400 - response

#### 401 - Requires an API key to continue

Requires an API key to continue

#### 404 - response

### Example Usage

```bash
curl -X GET "https://api.example.com/v0/payments/{payment-id}"
```

```

--------------------------------

### GET /v0/api-keys/{api-key-id}

Source: https://docs.griffin.com/redocusaurus/plugin-redoc-0.yaml

Returns the API key without `api-key-secret`.

```markdown
### Parameters

- **api-key-id** (string, path, required)

### Responses

#### 200 - response

Empty response body

#### 400 - response

#### 401 - Requires an API key to continue

Requires an API key to continue

#### 404 - response

### Example Usage

```bash
curl -X GET "https://api.example.com/v0/api-keys/{api-key-id}"
```

```