Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
SEO Metadata

Requirement Yogi - REST API

REST API in Confluence


titleNew! REST API documentation on!


titleExperimental API

Our API is subject to changes.

  • When we annotate @Public, we attempt with "best effort" to keep the API backwards-compatible for as long as possible.
    • If we want to deprecate, we will annotate with @Deprecated for a few versions, then remove it in the major version (in "platform.major.micro" versioning scheme, for example in 2.2.0).
    • We may add parameters, not remove them.
  • When we annotate @Internal, we don't even try to keep it stable, it usually changes from 1 micro version to another. Those APIs are tightly couples with the Javascript.
  • When we don't annotate, please consider it as @Internal.

This documentation is only designed for programmers. It is provided as is, and programmers are expected to be good enough to solve problems.


Base URL


The "base URL" is the address of Confluence. It could be:


Try with {baseUrl}/admin/viewgeneralconfig.action to ensure you have the right one. In the following documentation, we will omit the base URL.


Also available inside of the application: Atlassian's REST API Browser

(tick) Install and use Atlassian's REST API Browser and explore URLs inside of your Confluence / or Jira application:

titleNew! REST API documentation on!


Go to

 → All the documentation for developers
  • The REST API for version 2.5 → The first version of the REST documentation
  • → All the REST and Javadocs for all versions
  • ...

     for our developer portal.

    REST Resources in Confluence

    Verb and URLComments and query string arguments
    GET /rest/reqs/1/requirement2/{spaceKey}

    Search for requirements.

    • q = The query, using the Search Syntax.
    • spaceKey = The scope of the search. This is different from the spaceKey in the GET path. If the spaceKey in the query string isn't provided, and if the "Isolate Spaces" option is ticked in the Requirement Yogi administration, then the search will be restricted by default to the spaceKey provided in the GET path; Otherwise the spaceKey provided in the GET path has no effect.
    • offset = The pagination offset
    • limit = The pagination limit
    • order = The SQL ORDER BY clause (by default: "REQKEY ASC, BASELINE DESC")
    • includeArchived = true / false whether the archived requirements should be included. Otherwise, only current (ACTIVE) requirements are displayed.
    • baselineCondition = Do not use.
    • suggest = Do not use.
    POST /rest/reqs/1/requirement2/{spaceKey}Do not use.
    PUT /rest/reqs/1/requirement2/{spaceKey}Do not use.
    GET /rest/reqs/1/requirement2/{spaceKey}/{key}

    Get a requirement.

    • v = {integer} – Return the version of the requirement in baseline 'v'
    • expand = Use "references" if references to pages need to be expanded.
    POST /rest/reqs/1/requirement2/{spaceKey}/{key}Do not use.
    PUT /rest/reqs/1/requirement2/{spaceKey}/{key}Do not use.
    DELETE /rest/reqs/1/requirement2/{spaceKey}/{key}Do not use.
    GET /rest/reqs/1/requirement3Do not use.
    GET /rest/reqs/1/baseline/{spaceKey}

    Get the list of baselines in this space.

    • expand: Use "details" if you need to get the link to the baseline page and the number of requirements.
    POST /rest/reqs/1/baseline/{spaceKey}/1/create

    Freeze a baseline. The body must be in JSON:

    Code Block
        name: "The name of the baseline",
        ceo: the ID of the page which the baseline is attached to (cannot be null),
        queryString: the RY search query

    The ceo is the baseline page. It is not the page which contains the original definition of the requirements. It can be any arbitrary page, its title will be synchronized with the name of the baseline, and if there is a Baseline macro on it, this macro will show the count of requirements.

    The queryString is the list of all requirements which must be copied and archived in this baseline.

    POST /rest/reqs/1/baseline/{spaceKey}/1/create-instant

    Create and freeze instantly a baseline. There will be no parent page for this baseline. The body must be JSON:

    Code Block
        name: "The name of the baseline",
        fromCeo: the pageId of a page with requirements to freeze, cannot be null,
        fromCeoWithChildren: true/false.

    If fromCeoWithChildren is true, the requirements of all the child pages will be baselined too.

    DELETE /rest/reqs/1/baseline/{spaceKey}/{baseline}Delete a baseline. No JSON body.
    PUT /rest/reqs/1/baseline/{spaceKey}/{baseline}/labelChange the label of a baseline. Use a text/plain body.
    GET /rest/reqs/1/baseline/{spaceKey}/{baseline}/pagesReturns the list of pages which have requirements of this baseline.
    POST /rest/reqs/1/syncDeprecated. Do not use.
    POST /rest/reqs/1/helpers/reindex/{contentId}

    Reindexes a page. It will only mark the requirements are ACTIVE/DELETED and flag them as "Needs excerpt", which means those requirements will appear with a red dot. The next time a user views the page, excerpts will be gathered and saved as the text and properties of requirements, and the red dot will disappear.

    GET /rest/reqs/1/integration

    Returns the list of application links and their RY configuration.

    Permissions: Confluence administrators only.

    • Admins can deactivate a Jira applink in the administration of Confluence, just for Requirement Yogi,
    • Admins can choose which API version they use.
    • API versions are usually updated when a user performs a search in the Link dialog in Jira. If Jira notices that Confluence supports, say, API v4, and Jira does too, then it will upgrade to the maximum supported by both.
    POST /rest/reqs/1/integration

    Create an integration. Don't do it.

    Permissions: Confluence administrators only.

    GET /rest/reqs/1/integration/{serviceId}

    Returns the details of the integration:

    Code Block
        serviceId: the applink id or the internal UUID for this integration,
        applinkId: same as serviceId, if it is an application link,
        label: the name of the instance (ex: "Customer support Jira"),
        displayUrl: Jira's URL,
        rpcUrl: Jira's backend URL,
        endpoint: the address of the Requirement Yogi endpoints inside of Jira. It is empty for v0, has a value for v1 and above. It would only vary if a person programmed a new endpoint for, say, BitBucket Server or Dassault Catia,
        sendErrorsToEmail: the email API errors are sent to,
        sendErrorsToEmailThrottle: the throttle between sending each API error email,
        userKey: the user to connect to Jira,
        username: for information only, the login of the user,
        version: the API version to use,
        countMessagesInQueue: the count of messages currently NEW in the queue,
        status: "ACTIVE" or "DISABLED"

    Permissions: Confluence administrators only.

    PUT /rest/reqs/1/integration/{serviceId}

    Updates the descriptor.

    Permissions: Confluence administrators only.

    GET /rest/reqs/1/integration/{serviceId}/queue/outbound?limit=50

    Get the list of messages which will be sent to Jira in the next synchronization (every 3 mintues):

    • serviceId: The applink id, or the internal UUID,
    • limit: The maximum number of messages to return,
    • includeDone: true/false,
    • includeLastRespnse: true/false
    PUT /rest/reqs/1/integration/{serviceId}/queue/outbound/{messageId}

    PUT sends this item to Jira. No body necessary.

    DELETE removes this message from the list.