OAS 3 This guide is for OpenAPI 3.0.

Using $ref

When you document an API, it is common to have some features which you use across several of API resources. In that case, you can create a snippet for such elements in order to use them multiple times when you need it. With OpenAPI 3.0, you can reference a definition hosted on any location. It can be the same server, or another one – for example, GitHub, SwaggerHub, and so on. To reference a definition, use the $ref keyword:
$ref: 'reference to definition'
For example, suppose you have the following schema object, which you want to use inside your response:
JSON Example YAML Example
"components": {
  "schemas": {
    "user": {
      "properties": {
        "id": {
          "type": "integer"
        "name": {
          "type": "string"
          type: integer
          type: string
To refer that object, you need to add $ref with the corresponding path to your response:
JSON Example YAML Example
"responses": {
  "200": {
    "description": "The response",
    "schema": {
      "$ref": "#/components/schemas/user" 
    description: The response
      $ref: '#/components/schemas/User'
The value of $ref uses the JSON Reference notation, and the portion starting with # uses the JSON Pointer notation. This notation lets you specify the target file or a specific part of a file you want to reference. In the previous example, #/components/schemas/User means the resolving starts from the root of the current document, and then finds the values of components, schemas, and User one after another.

$ref Syntax

According to RFC3986, the $ref string value (JSON Reference) should contain a URI, which identifies the location of the JSON value you are referencing to. If the string value does not conform URI syntax rules, it causes an error during the resolving. Any members other than $ref in a JSON Reference object are ignored. Check this list for example values of a JSON reference in specific cases:
  • Local Reference$ref: '#/definitions/myElement' # means go to the root of the current document and then find elements definitions and myElement one after one.
  • Remote Reference$ref: 'document.json' Uses the whole document located on the same server and in the same location.
    • The element of the document located in the same folder$ref: 'document.json#/myElement'
    • The element of the document located in the parent folder$ref: '../document.json#/myElement'
    • The element of the document located in another folder$ref: '../another-folder/document.json#/myElement'
  • URL Reference$ref: 'http://path/to/your/resource' Uses the whole document located on the different server.
    • The specific element of the document stored on the different server$ref: 'http://path/to/your/resource.json#/myElement'
    • The document on the different server, which uses the same protocol (for example, HTTP or HTTPS) – $ref: '//anotherserver.com/files/example.json'
Note: When using local references such as #/components/schemas/User in YAML, enclose the value in quotes: '#/components/schemas/User'. Otherwise it will be treated as a comment.

Escape Characters

/ and ~ are special characters in JSON Pointers, and need to be escaped when used literally (for example, in path names).
Character Escape With
~ ~0
/ ~1
For example, to refer to the path /blogs/{blog_id}/new~posts, you would use:
$ref: '#/paths/~1blogs~1{blog_id}~1new~0posts'


Places Where $ref Can Be Used

A common misconception is that $ref is allowed anywhere in an OpenAPI specification file. Actually $ref is only allowed in places where the OpenAPI 3.0 Specification explicitly states that the value may be a reference. For example, $ref cannot be used in the info section and directly under paths:
openapi: 3.0.0

# Incorrect!
  $ref: info.yaml
  $ref: paths.yaml
However, you can $ref individual paths, like so:
    $ref: '../resources/users.yaml'
    $ref: '../resources/users-by-id.yaml'

$ref and Sibling Elements

Any sibling elements of a $ref are ignored. This is because $ref works by replacing itself and everything on its level with the definition it is pointing at. Consider this example:
      type: string
      format: date

      $ref: '#/components/schemas/Date'
      description: Date schema extended with a `default` value... Or not?
      default: 2000-01-01
In the second schema, the description and default properties are ignored, so this schema ends up exactly the same as the referenced Date schema.


Did not find what you were looking for? Ask the community
Found a mistake? Let us know