Message Signatures confirm the identity of the sender and integrity of request messages. Key points: - Uses Ed25519 algorithm - Requires registering a public key with Griffin - Signatures cover specific message components - Includes `Signature-Input` and `Signature` headers [How to create message signatures](/docs/guides/how-to-create-message-signatures) provides a detailed guide.
swagger: '2.0'
info:
title: The Griffin API keys Message Signatures API
version: ''
description: "## Introduction\n\nThe Griffin API is based on [REST](https://en.wikipedia.org/wiki/Representational_state_transfer).\nIt 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.\n\nOur API deviates from strict RESTful principles if it makes sense to do so, such as when we enforce tighter access controls around certain operations.\nFor 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.\n\nAnyone 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).\n\nNew to Griffin? Check out our [getting started guide](/docs/guides/get-started-with-the-api).\n\n## Navigation\n\nOur API is designed to be navigated programmatically. When you request any resource, you will find the URLs for related resources in the response body.\n\nThe 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.\n\nTo bootstrap the navigation process, request the [index](#tag/Navigation/paths/~1v0~1index/get) endpoint: the response will contain your `organization-url`.\n\nFor a walkthrough, see our [getting started guide](/docs/guides/get-started-with-the-api).\n\n## Pagination\n\nOur 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)).\nBy 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.\n\n### Change page size\n\nYou can request a different number of results (between 1 and 200, inclusive) by using the `page[size]` query parameter:\n\n```\nGET /v0/organizations/:id/bank/accounts?page[size]=100\n```\n\n### Navigating between pages\n\nList responses will include a `links` object with `prev` and `next` attributes, as shown below.\nPerform a GET request to the value of the attribute to fetch the previous/next page of results.\n\n```\n{\n \"accounts\": [\n // ...\n ],\n \"links\": {\n \"prev\": \"/v0/organizations/og.IG9yZ2FuaXphdGlvbi1pZA/bank/accounts?page[before]=djE6WxSPxfYUTnCU9XtWzj9gGA\",\n \"next\": \"/v0/organizations/og.IG9yZ2FuaXphdGlvbi1pZA/bank/accounts?page[after]=djE6aw79PXZySUOL16LD8HRJ3A\"\n }\n}\n\n```\nIf there is no previous or next page available, the value of the attribute will be null.\n\nAny other query parameters included in the initial request will also be included in the response payload's links.\nIf you want to change parameters (see [filtering and sorting](#section/Filtering-and-sorting)), request the first page and follow the links from there.\n\n## Filtering and sorting\n\n### Sort results\n\nBy default, resources will be listed in descending order, usually based on the `created-at` attribute.\nYou can change the sorting behaviour of a list of results by using the `sort` query parameter.\n\nFor example, to list bank accounts in ascending order (oldest first):\n\n```\nGET /v0/organizations/:id/bank/accounts?sort=created-at\n```\n\nTo _explicitly_ sort in descending order (newest first), prefix the sort attribute with `-`:\n\n```\nGET /v0/organizations/:id/bank/accounts?sort=-created-at\n```\n\n### Filter results\n\nSome list APIs allow you to filter the results.\nFilters are expressed as nested data structures encoded into query parameters.\nFor example, you can list bank accounts that are in either the `opening` or `open` state with:\n\n```\nGET /v0/organizations/:id/bank/accounts?filter[account-status][in][]=opening&filter[account-status][in][]=open\n```\n\nSimilarly, you can list legal persons with a specific `application-status`:\n\n```\nGET /v0/organizations/:id/legal-persons?filter[application-status][eq]=accepted\n```\n\n### Include resources\n\nSome list APIs allow you to include associated resources in the response, reducing the number of requests needed to fetch related data.\nFor instance, when listing bank accounts, you can include each bank account's beneficiary legal person by using the `include` query parameter:\n\n```\nGET /v0/organizations/:id/bank/accounts?include=beneficiary\n```\n\nThe response returns the usual list of bank accounts, but it will also have an `included` object with a `legal-persons` attribute:\n\n```\n{\n \"accounts\": [\n // ...\n ],\n \"links\": {\n // ...\n }\n \"included\": {\n \"legal-persons\": [\n // ...\n ]\n }\n}\n```\n\nCheck the documentation for each list API to see all options for sorting and filtering\n\n## Request limits\n\nEach 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.\n\n## Versioning\n\nThe Griffin API is versioned via a prefix in the URL.\nThe current version is v0.\nAn example endpoint is: https://api.griffin.com/v0/index.\n\nWe will not break your integration with a particular version for as long as we support that version.\nIf we release a new version, you will have 12 months to upgrade to it."
host: api.griffin.com
basePath: /
schemes:
- https
consumes:
- application/json
produces:
- application/json
security:
- api-key-auth: []
tags:
- name: Message Signatures
description: 'Message Signatures confirm the identity of the sender and integrity of request messages.
Key points:
- Uses Ed25519 algorithm
- Requires registering a public key with Griffin
- Signatures cover specific message components
- Includes `Signature-Input` and `Signature` headers
[How to create message signatures](/docs/guides/how-to-create-message-signatures) provides a detailed guide.'
paths:
/v0/security/message-signature/verify:
get:
tags:
- Message Signatures
description: Yields the status of the http signature validation
security: []
parameters:
- type: string
in: header
name: header-signature
description: 'Message Signatures: signature header containing a signature label with the components used to generate the signature'
- type: string
in: header
name: header-signature-input
description: 'Message Signatures: signature-input header containing a signature label with the components used to generate the signature'
responses:
'200':
schema:
type: object
properties:
message:
type: string
busy:
type: boolean
required:
- message
- busy
title: httpsig-debug-response
description: ''
summary: HTTP Signature Debug
post:
tags:
- Message Signatures
description: Yields the status of the http signature validation
security: []
parameters:
- type: string
in: header
name: header-signature
description: 'Message Signatures: signature header containing a signature label with the components used to generate the signature'
- type: string
in: header
name: header-signature-input
description: 'Message Signatures: signature-input header containing a signature label with the components used to generate the signature'
responses:
'200':
schema:
type: object
properties:
message:
type: string
busy:
type: boolean
required:
- message
- busy
title: httpsig-debug-response
description: ''
put:
tags:
- Message Signatures
description: Yields the status of the http signature validation
security: []
parameters:
- type: string
in: header
name: header-signature
description: 'Message Signatures: signature header containing a signature label with the components used to generate the signature'
- type: string
in: header
name: header-signature-input
description: 'Message Signatures: signature-input header containing a signature label with the components used to generate the signature'
responses:
'200':
schema:
type: object
properties:
message:
type: string
busy:
type: boolean
required:
- message
- busy
title: httpsig-debug-response
description: ''
delete:
tags:
- Message Signatures
description: Yields the status of the http signature validation
security: []
parameters:
- type: string
in: header
name: header-signature
description: 'Message Signatures: signature header containing a signature label with the components used to generate the signature'
- type: string
in: header
name: header-signature-input
description: 'Message Signatures: signature-input header containing a signature label with the components used to generate the signature'
responses:
'200':
schema:
type: object
properties:
message:
type: string
busy:
type: boolean
required:
- message
- busy
title: httpsig-debug-response
description: ''
patch:
tags:
- Message Signatures
description: Yields the status of the http signature validation
security: []
parameters:
- type: string
in: header
name: header-signature
description: 'Message Signatures: signature header containing a signature label with the components used to generate the signature'
- type: string
in: header
name: header-signature-input
description: 'Message Signatures: signature-input header containing a signature label with the components used to generate the signature'
responses:
'200':
schema:
type: object
properties:
message:
type: string
busy:
type: boolean
required:
- message
- busy
title: httpsig-debug-response
description: ''
securityDefinitions:
api-key-auth:
type: apiKey
in: header
name: Authorization
description: 'API token authentication.
It should follow the format: `GriffinAPIKey g-test-MyKey-XXXXXXX`'
x-tagGroups:
- name: Getting started
tags:
- API keys
- Connectivity
- Navigation
- Events
- Webhooks
- Message Signatures
- name: Customer verifications
tags:
- Legal persons
- Legal person history
- Claims
- Workflows
- Verifications
- Decisions
- Companies House
- Reliance onboarding
- name: Banking
tags:
- Bank accounts
- Bank account events
- Bank account restrictions
- Bank account holds
- Pooled account membership
- Payments
- Transactions
- Payees
- Confirmation of payee
- Open banking
- name: Team management
tags:
- Organizations
- Users
- Roles
- Memberships
- Invitations
x-id:
- default