API Spec

type [Required]

The type of API as a string, e.g. type: openapi.

Whilst the spec.type of a API may be any string, visualisation is only available for a small subset. Further to this, understanding is made easier by sticking to a small set of well-known and common values. Thus we recommend that when specifying an API one of the following is used in this field:

• openapi - an API definition in YAML or JSON format based on the OpenAPI version 2 or version 3 spec
• asyncapi - an API definition based on the AsyncAPI spec
• graphql - an API definition based on GraphQL schemas for consuming GraphQL based APIs
• grpc - an API definition based on Protocol Buffers to use with gRPC

lifecycle [Required]

The lifecycle state of the API as a string, e.g. lifecycle: production.

Whilst the spec.type of a Component or API may be any string, understanding is made easier by sticking to a small set of well-known and common values. Thus we recommend that when specifying an entity one of the following is used in this field:

• experimental - an experiment or early, non-production entity, signaling that users may not prefer to consume it over other more established entities, or that there are low or no reliability guarantees
• production - an established, owned, maintained entity
• deprecated - an entity that is at the end of its lifecycle, and may disappear at a later point in time

owner [Required]

An entity reference to the owner of the entity, e.g. owner: user:enu43627. Users and Groups are automatically populated, and can listed in the catalog by filtering by Kind of User or Group respectively.

The owner of an entity is the group or user that bears ultimate responsibility for the entity, and has the authority and capability to develop and maintain it. They will be the point of contact if something goes wrong, or if features are to be requested. The main purpose of this field is for display purposes in Backstage, so that people looking at catalog items can get an understanding of to whom this entity belongs. It is not to be used by automated processes to for example assign authorization in runtime systems. There may be others that also develop or otherwise touch the entity, but there will always be one ultimate owner.

system [Optional]

An entity reference to the System that the entity belongs to, e.g. developer-portal. There is no requirement for this System to be created within the same location; Existing Systems can be listed in the catalog by filtering by Kind of System.

definition [Required]

The definition of the API, as a multi-line string, based on the format defined by type.

For example, where type is openapi:

definition: |
  openapi: 3.0.0
  info:
    title: Backstage API
    version: 0.0.1

Tip

The API schema can be located in another file and imported by using substitutions, e.g.:

definition:
    $text: ./schema-file.json

$text, $json & $yaml are available, for more details see the backstage docs