Documentation Library

Search for information on Hornbill Documentation.


{{docApp.searchResultFilteredItems.length}} results for "{{docApp.currentResultsSearchText}}" in {{docApp.searchFilterBySpecificBookTitle}}

Have questions about this site?

What is this site?

  • This website is Hornbill's new product documentation website and is currently under development.
  • It is intended that all existing and future public-facing documentation we produce will be available to search, browse and share.
  • Hornbill's current documentation is available at Hornbill Wiki but over time this content will be migrated to this documentation site.
  • Please feel free to have a look around at any time.

Why has Hornbill created this site?

  • Hornbill's products have moved on considerably since we introduced it almost 10 years ago. At the time, the MediaWiki tool was sufficient, but we have outgrown it.
  • Our customers are more enterprise focused and more self-sufficient than ever before, so for 2023 and beyond we have established a new documentation platform and team to drive our documentation initiative forwards.
  • We are aiming to deprecate the use of Hornbill Wiki for most Hornbill related documentation.
  • We want to enable our growing partner network with product resources and information, documentation beyond our Wiki approach is required.
  • We could definitely do with some help, and may even pay for some! If you have domain knowledge and would like to help, please check out our Hornbill Docs Contributor Guide and contact the Hornbill docs team at

What will this site be good for?

  • Community contribution will be facilitated, encouraged, and most welcome.
  • High quality documentation, will be kept up to date as rapidly as our products evolve.
  • Real-time content search and discovery.
  • Articles organized into books, books into libraries, creating a more natural and logical structure to our documentation.
  • Legacy API documentation and various other documentation sources will all be consolidated into a single unified documentation system.
  • Documentation available in browser as well as printable/viewable as PDF on demand.
  • Personalized documentation experience, allowing dark/light mode, article subscriptions, social media sharing and other useful features.
  • Almost all publicly available documentation on will be open-source and available to fork on GitHub, allowing customers to derive their own custom documentation around Hornbill products should they wish to.

What is the timeline for this site?

  • We have taken the decision to publish and make available early, there is very little content at this time.
  • As and when we have completed/usable documentation, it will be published here.
  • We have a host of additional features we wish to add over time, so please watch this space.
  • We expect most of our existing documentation should be reviewed/migrated to over the coming months.
  • The documentation project will be ongoing, will continue to expand, evolve and improve day-by-day.

{{docApp.libraryHomeViewProduct.title ||}}


  1. {{book.title}}

{{group.title ||}}


  1. {{book.title}}



The Hornbill platform includes a feature called KeySafe. The purpose of the KeySafe feature is to provide a safe and secure way of storing credentials, API keys and other security-sensitive information that needs to be available at the point of use, when making API/Integration calls to other systems. Any enterprise system that takes security seriously, that has to deal with a large numbers of integrations with third-parties, a secure, central store for sensitive security information is required.

In more typical integration approaches, credentials used for integrations are often just kept in plain text file, on a server, relying on the local administration control of the server itself to secure that information. Because the Hornbill Platform is a cloud based service, we created a way of safely and securely storing these credentials, API keys, certificates and other sensitive information that ensures that this information is encrypted at rest, locked away, and only used at the exact point of use.

When working with cloud and on-premise systems in relation to machine-to-machine integrations and automation, there are a number of commonly used authentication standards, such as OAuth, JWT, API Keys, userId/password, private/public keys and many others. Further more, implementations of these standards have wide variations of implementation detail, but all of these standards ultimately require some level of security identifier/token/password to be stored, simply because machine-to-machine integrations and automation’s do not have the benefit of human interaction to verify credentials at the point of use. In order to cater for the wide range of requirements, KeySafe is essentially a specially encrypted database of KeySafe records. Hornbill KeySafe includes a large number of pre-configured KeySafe types and templates covering many hundreds of integrates that Hornbill works with.

Authentication Scheme Implementation

As well as the secure storage of credentials, Hornbill KeySafe also implements a large number of pre-integrated interactive authentication schemes for a wide rage of products and services. Although there are only a handful of standards that are typically used for authentication, for example OAuth 1.1, OAuth 2.0, SAML and others, the fact is there are a vast range of variations of these implementations that while follow the standards have different ways of configuring/setting up an authentication. Each different product often requires specific variations and in many cases, specific browser based interactions in order to establish the initial authentication keys/certs. KeySafe has the capability of acting as a client that facilitates being authorized by a third-party identity provider interactively, supporting OAuth 1.1, OAuth 2 and many other variations and product-specific type. The product-specific implementation KeySafe types built by Hornbill provide a simplified, GUI driven method for establishing these credentials.


Access to KeySafe is controlled by Hornbill system rights, which means you can configure and control access to KeySafe, locking down access to individuals, groups, teams etc… We have built in multiple layers of security into the KeySafe system to ensure the secret keys and other security assets stored in KeySafe remain safe and secure.

KeySafe Access Controls

Many pre-built integrations and import tools make use of KeySafe to store credentials, these integrations typically make use of API Keys on the Hornbill platform. When creating a KeySafe entry, it is possible to restrict the use of individual KeySafe records to a specific API Key(s). It is required you apply these access controls whenever you create a KeySafe entry that will be used by any integration that makes use of an API key in order to give that API key permission to access that specific credential.

Limited Security Surface

As well as all KeySafe content being encrypted at rest, and in motion, KeySafe credentials are generally not available for viewing/observing through the administrative user interfaces either, setting a password on a identity record for example is a one-way operation, the administrator configuring the KeySafe entry can set a password credential, but cannot subsequently view it once set. The various integration points that make use of KeySafe entry’s, credentials content is transmitted to the point of integration encrypted, we only decrypt and use the credentials at the exact point its needed, and we never store credentials on any local disk files or in any caches, making KeySafe very secure.


All KeySafe content is encrypted using AES-256 with a combination of a 256-bit private key, which is unique for each Hornbill instance, the encryption uses time-based variability to further strengthen the encryption applied.

Use Without Sight of Credentials

One of the key benefits of KeySafe is the ability for someone with higher privilege level to create a valid credential within KeySafe, and then be able to grant limited use-only access to that credential to other users. This makes it possible for, say a business process designer to use the credentials for a specific integration or service, without any possibility of having sight of the credential details. The benefits of this feature include:

  • Controlled Exposure of Sensitive Information: When configuring an integration point for an organization-wide system like Email for example, you may want various people to make use of integrated email service, but do no want them exposed to the actual credential details (such as knowing the password or API key for a service).

  • Central Management of Credentials: When integrating with a system from multiple points of access, you need the ability to manage these access credentials centrally, such that if you have a security event that requires a credentials change, you can make this change in one location, instead of having to keep track of of all the places these credentials are being used, and having to change them in multiple places.

In This Document