> ## 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.

# Integration Studio

> Connect any app 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.

Building a connector for an app outside Oleria's application catalog normally means an engineering request and a release cycle. Integration Studio removes that step: provide a link to the app's API documentation, and an AI research agent reads it, maps the app's data to Oleria's identity model, and produces a connector manifest for you to review. Nothing connects until you approve it and Oleria tests the connection against the live app.

## How Integration Studio works

<Steps>
  <Step title="Provide the API documentation">
    From the Integrations page, start a new Integration Studio connector. Provide an integration name and a link to the app's API documentation, OpenAPI/Swagger spec, or Postman collection. Select which data to track (identities, roles and groups, permissions, or a combination) and optionally enable remediations.
  </Step>

  <Step title="The agent researches the API">
    The research agent runs four sequential stages. Each stage streams its reasoning and the exact documentation pages it read, and completes with a confidence indicator (High, Medium, or Low) based on how much of the result came from a machine-readable spec versus was inferred from partial or human-written docs.

    | Stage                | Produces                                                   |
    | :------------------- | :--------------------------------------------------------- |
    | API descriptor       | Authentication type, base URL, endpoints, and pagination   |
    | Data mapping         | Maps API resources to the data types you selected to track |
    | Application manifest | The full connector manifest                                |
    | Plugin metadata      | Display name, icon, and category for the integration tile  |

    A low-confidence stage flags the specific gap and what it limits - for example, a remediation that can't be generated without a documented endpoint for it.
  </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 manifest, the endpoints discovered, and any remediations the agent proposed. Provide credentials, and Oleria tests the connection against the live app before anything goes live.
  </Step>
</Steps>

## Supported authentication methods

Integration Studio detects the app's authentication scheme during research and pre-fills the credential form. You can override the detected type if it's wrong.

| Method       | Fields                                |
| :----------- | :------------------------------------ |
| API key      | Key, header name, header value format |
| Bearer token | Token                                 |
| Basic auth   | Username, password                    |

Every credential form requires a passing **Test connection** before you can connect. A failed test returns the specific cause: invalid credentials, insufficient scopes, an unreachable base URL, or an unexpected error from the app.

<Note>
  OAuth 2.0 (client credentials and authorization code), custom header, and two-step/session token authentication are coming soon.
</Note>

## Remediations

If you enable remediations during setup, the research agent maps the app's endpoints to actions Oleria can take directly against it, not just read from it. This is what lets a connector you build through Integration Studio participate in the same governance workflows as any connector in the application catalog:

* **[Identity lifecycle management (ILM)](/governance/employee-lifecycle-leaver)** - disable or deprovision an account as part of a joiner/mover/leaver workflow.
* **[Access reviews](/governance/access-review)** - revoke access or remove a group membership when a certification campaign flags it.
* **Access requests** - grant or remove access as part of a request-and-approval workflow.

Each proposed remediation is reviewed individually before it goes live.

* Remediations generated with low confidence default to off.
* Destructive or irreversible remediations (a hard delete, a permanent revoke) always default to off and carry a distinct risk indicator, regardless of confidence.
* Integration Studio has no built-in undo for a triggered remediation - reversing one means taking the opposite action manually in the target app (for example, re-enabling an account you disabled).

## Managing an Integration Studio connector

An Integration Studio connector is managed from its own detail page, the same as any other integration:

* **Manifest** - view or edit each artifact (API descriptor, data mapping, application manifest, plugin metadata) individually.
* **Sync health** - a log of sync attempts with record counts and errors. Errors are specific: an expired auth token, a rate limit with a retry time, or a field-mapping mismatch with a count of affected records.
* **Settings** - update credentials, update the docs URL and re-run research, enable or disable individual remediations, rename, or delete the connector.

Updating the docs URL and re-running research produces a diff against the current manifest: changed sections are highlighted, unchanged sections stay collapsed. You choose whether to apply the new manifest or discard it and keep the current one.

## A manifest, not custom code

A traditional connector is code an engineer writes, compiles, and ships. Integration Studio produces a manifest instead: a structured description of the app's authentication, endpoints, pagination, and field mappings. A generic runtime reads the manifest and behaves as the connector, so a new integration is a configuration change, not a release. This is the same manifest format behind the connectors Oleria's engineers build for the application catalog, so a connector built through Integration Studio runs on the same foundation as any other.

## How it fits with the rest of Oleria

An Integration Studio connector feeds the same workflows as every connector in the application catalog:

<CardGroup cols={2}>
  <Card title="Access Inventory" icon="shield-check">
    Posture findings extend to the new app the same as any built-in connector.
  </Card>

  <Card title="Governance" icon="clipboard-check">
    The new app joins your existing access-review campaigns automatically.
  </Card>

  <Card title="NHI discovery" icon="robot">
    Service accounts and tokens the connector surfaces become visible in NHI discovery.
  </Card>

  <Card title="Copilot queries" icon="magnifying-glass">
    Query across the new app the same way you query the rest of your estate.
  </Card>
</CardGroup>

## Get started

<CardGroup cols={2}>
  <Card title="Integrations overview" icon="plug" href="/integrations/overview">
    See how integrations fit into the Oleria identity and access graph.
  </Card>

  <Card title="SCIM-Based Integration" icon="link" href="/integrations/scim">
    Connecting an app that doesn't have a documented API? Use the SCIM-based connector instead.
  </Card>
</CardGroup>

## Contact us

For questions about Integration Studio, contact us at [support@oleria.com](mailto:support@oleria.com).