> ## Documentation Index
> Fetch the complete documentation index at: https://docs.oleria.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Ticketing Studio

> Connect any ticketing system that has a documented API. An AI research agent reads the API, drafts a connector manifest, and hands it to you to review and connect.

Connecting a ticketing system other than Jira or ServiceNow normally means an engineering request and a release cycle. Ticketing Studio removes that step: name your ticketing system and provide a link to its API documentation, and an AI research agent reads it, maps the system's ticket operations to the way Oleria raises tickets, and produces a connector manifest for you to review. Nothing connects until you approve it and Oleria tests the connection against your live ticketing system.

Once connected, Oleria raises tickets in that system from risks and posture findings, the same as with [Jira](/workspace/jira-ticketing) or [ServiceNow](/workspace/servicenow-ticketing).

## Prerequisites

* The Administrator role in Oleria to add a ticketing system. See [role permissions](/administration/default-user-roles).
* No other ticketing system connected. Oleria supports one connected ticketing system at a time.
* A link to the ticketing system's API documentation. You can provide more than one link.
* Credentials for the ticketing system that use a supported [authentication method](#supported-authentication-methods): an API key, a bearer token, a username and password, or OAuth 2.0 client credentials. Use credentials that can create tickets.

## How Ticketing Studio works

<Steps>
  <Step title="Provide the API documentation">
    Navigate to **Settings** → **Ticketing System** and select **Get started** on the **Ticketing Studio** tile. Under **Which ticketing system do you use?**, pick your ticketing system from the list, or select **Something else…** and enter a **Ticketing system name** and a **Link to its API documentation**. Select **Add another link** to provide more documentation pages.

    Optionally, open **Advanced** and add **Instructions** for the research agent, for example: `Tickets must go to the Security queue; we use API v2`.

    If you pick a ready-to-connect system, select **Connect** and go straight to [connecting it](#ready-to-connect-ticketing-systems). Otherwise, select **Start research**. If Oleria finds it already has a tested integration for the system you named, research stops there and you provide credentials to connect.
  </Step>

  <Step title="The agent researches the API">
    **Oleria AI Researcher** reads the documentation and drafts a connector. It streams its progress through each stage and lists the exact documentation pages it read.

    | Stage | What happens |
    | :- | :- |
    | Checking known integrations | Looks for a tested integration for your ticketing system |
    | Reading the API documentation | Finds the authentication method, base URL, and the endpoints for each ticket operation |
    | Drafting the connector | Produces the full connector manifest |
    | Validating | Checks the draft, as described in the next step |
    | Saving the draft | Stores the validated manifest for you to review |

    If the documentation doesn't describe a usable API, or the system uses an authentication method Ticketing Studio doesn't support yet, research stops and tells you why. Select **Try different docs** to point the agent at documentation for a different API of the same system.
  </Step>

  <Step title="A deterministic validator checks every draft">
    Every manifest is checked by a validator that runs outside any AI model. It is a mechanical, rule-based check: a draft that fails returns specific errors, the agent fixes that piece, and only a fully validated manifest advances.
  </Step>

  <Step title="Review and connect">
    Review the **Supported operations** and anything Oleria AI could not confirm from the documentation, then select **Continue to connect**. Provide credentials, and Oleria tests the connection against your live ticketing system before anything goes live. See [Connection test](#connection-test).
  </Step>
</Steps>

## Ready-to-connect ticketing systems

Some ticketing systems already have a tested integration, so no research is needed. Pick one under **Which ticketing system do you use?**, select **Connect**, and provide its credentials.

| Ticketing system | Status |
| :- | :- |
| Linear | Ready to connect |
| Zendesk | Ready to connect |

The list also offers common ticketing systems, such as Freshservice, Freshdesk, PagerDuty, Asana, monday.com, ClickUp, GitHub Issues, and GitLab, with their API documentation links already filled in. Picking one of these starts research.

## Supported authentication methods

Ticketing Studio detects the ticketing system's authentication scheme during research and builds the credential form from it. The form also asks for the system's base URL, or just your subdomain for systems such as Zendesk, and any system-specific values, such as the project or team that tickets go to.

| Method | Credentials |
| :- | :- |
| API key | Key |
| Bearer token | Token |
| Basic auth | Username, password |
| OAuth 2.0 client credentials | Client ID, client secret |

<Note>
  Ticketing systems that only support SAML or certificate-based authentication aren't supported yet.
</Note>

## Connection test

To check access when you connect, Oleria creates one test ticket and then deletes it, or closes it if the ticketing system doesn't allow deletes. This is the same check that Jira and ServiceNow setup does. The test ticket is titled `[Oleria] connection test` and is safe to delete if it remains.

* If the test ticket is created, the connection succeeds.
* If the credentials aren't permitted to create tickets, the connection still succeeds as a read-only connection, and Oleria shows which operations the credentials allow.
* If the ticketing system rejects the credentials, the connection fails with the error from the ticketing system. For a ready-to-connect system, check the credentials and try again. For a researched integration, the integration itself may be wrong; select **Discard and start over**.
* If the ticketing system rejects the test ticket for any other reason, the connection fails with the error from the ticketing system. The integration itself may be wrong, so correcting the credentials won't help. Select **Discard and start over**, and add instructions or more specific documentation.

For incident and on-call tools where a new ticket pages people, such as PagerDuty or Opsgenie, the research agent drafts the connector to skip the test ticket. Before you connect one of these, select **Manifest** during review and check that it contains `connectionTest: false`. Otherwise the test ticket pages your on-call team. When the test ticket is skipped, Oleria still checks the credentials with a read-only request, and **Create tickets** shows **Not checked yet** until Oleria creates its first ticket.

## What this connection can do

After you connect, Oleria shows each ticket operation and whether the credentials allow it.

| Status | Meaning |
| :- | :- |
| Verified | Oleria has performed the operation with these credentials. |
| Not checked yet | Verified the first time Oleria uses it. |
| Not permitted | The ticketing system refused the operation for these credentials. |

The operations are **Create tickets**, **Update tickets**, **Add notes**, **Close tickets**, and **Reopen tickets**, depending on which ones the ticketing system's API supports.

These statuses are informational. Oleria keeps trying an operation marked **Not permitted**, so you don't need to reconnect: grant the permission in your ticketing system, and the next successful use marks it **Verified**.

## Managing a Ticketing Studio connection

A ticketing system connected through Ticketing Studio is managed from **Settings** → **Ticketing System**, the same as Jira or ServiceNow. Select **View details** on its tile to see:

* **Ticketing system connection details** - the ticketing system, its instance, its status, and who connected it and when.
* **What this connection can do** - the status of each ticket operation, as described in [What this connection can do](#what-this-connection-can-do).

To remove the ticketing system, select **Remove** and then **Yes, remove**. Removing a ticketing system does not delete tickets Oleria already created in it.

## A manifest, not custom code

A traditional ticketing connector is code an engineer writes, compiles, and ships. Ticketing Studio produces a manifest instead: a structured description of the ticketing system's authentication, ticket endpoints, and field mappings. A generic runtime reads the manifest and behaves as the connector, so a new ticketing system is a configuration change, not a release. The manifest is the integration: select **Manifest** during review to see it, or **Copy manifest** to share it.

## Get started

<CardGroup cols={2}>
  <Card title="Ticketing" icon="ticket" href="/workspace/ticketing-overview">
    Create and view tickets from risks once your ticketing system is connected.
  </Card>

  <Card title="Integration Studio" icon="wand-magic-sparkles" href="/integrations/integration-studio">
    Connecting an app for access data instead? Use Integration Studio.
  </Card>

  <Card title="Jira" icon="jira" href="/workspace/jira-ticketing">
    Using Jira? Connect it directly instead.
  </Card>

  <Card title="ServiceNow" icon="server" href="/workspace/servicenow-ticketing">
    Using ServiceNow? Connect it directly instead.
  </Card>
</CardGroup>

## Contact us

For questions about Ticketing Studio, or to request a hand-built integration for a ticketing system Ticketing Studio can't connect, contact us at [support@oleria.com](mailto:support@oleria.com).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.