Connect an AI model

Who this is for: admins who want workflows to classify, summarise or pull data out of text with their company’s own AI model.

Before you start: you need the Manage connections permission in Liitora (Admin and Editor), and an account with the AI provider that lets you create API keys.

Liitora never uses an AI model of its own for your workflow data. A workflow step calls your model, with your API key, through an AI connection. You choose the provider, and with it where your data is processed. Every step that sends data to a model is marked as an AI step in the run log, and every call is logged.

Pick a provider

In Connections, select Add a connection and pick one of these under Start from:

Template	Address	Where data is processed
OpenAI	`https://eu.api.openai.com/v1` (EU, the default) or `https://api.openai.com/v1` (Global)	With EU, in the European Economic Area and Switzerland, once OpenAI approves your project for EU data residency. Output schemas may still be processed outside the region. With Global, OpenAI does not promise where.
Azure OpenAI	`https://<your resource>.openai.azure.com/openai/v1`	Depends on your deployment type. A Data Zone Standard deployment in the EU data zone keeps processing in the EU data zone, which may include EFTA countries such as Norway and Switzerland. A Global deployment may process requests in any region.
Anthropic	`https://api.anthropic.com/v1`	Anthropic has no EU region. Requests are processed globally, which can include the United States.
Mistral	`https://api.eu.mistral.ai/v1`	Mistral’s EU endpoint runs the models in data centers in EU and EFTA countries. Account, key and usage data may still be handled outside the EU, and some models are not offered in the EU region.
OpenAI-compatible server	the address you enter	Wherever that server runs. Check its terms before you send personal data.

The form shows the same text under Where data is processed, so you can check it before you save.

If your data must stay in the EU, use Mistral, Azure OpenAI with an EU Data Zone deployment, or OpenAI with the EU region. Send a model only the data the task needs, and check your own privacy policy and your agreement with the provider.

Add the connection

Create an API key with your provider. Give it its own project or workspace for Liitora if the provider allows it, so you can see its usage and set a spending limit.
In Liitora, add a secret that holds the API key.
Open Connections and select Add a connection.
Under Start from, pick the provider.
Type the Name, for example company-ai. Workflows use this name.
Pick the Environment: Test or Production.
Fill in what the template asks for:
- OpenAI: the Region. Keep EU if OpenAI has approved your project for EU data residency. Otherwise pick Global.
- Azure OpenAI: the Resource name, the first part of your endpoint https://<name>.openai.azure.com. Only letters, digits and hyphens are allowed.
- OpenAI-compatible server: the Base URL, for example https://models.example.com/v1. It must start with https:// and be reachable on the public internet. Liitora can’t reach a private address or localhost.
Under API key, pick the secret from step 2.
Select Save, then Test connection.

The template fixes the address, the sign-in and the other hosts, so the connection can only ever reach that provider. To change the region or the resource later, add a new connection from the template.

On Azure OpenAI, Test connection only checks that your resource answers. A wrong deployment name shows up when a step runs.

Use the model in a workflow

A workflow asks the model with the built-in action platform/ai.generate. You describe the answer you want as a JSON Schema, and Liitora checks every answer against it.

  - id: triage
    name: Label the support ticket
    uses: platform/ai.generate@v1
    connections:
      model: company-ai
    with:
      model: mistral-small-latest
      prompt: Label the ticket as bug, question or billing.
      prompt_version: ticket-triage-1
      input:
        subject: ${{ trigger.body.subject }}
        text: ${{ trigger.body.text }}
      max_output_tokens: 100
      output_schema:
        type: object
        properties:
          label: { type: string, enum: [bug, question, billing] }
        required: [label]
        additionalProperties: false

Later steps read the answer as ${{ steps.triage.outputs.output.label }}.

The step fails, and the answer is not used, when the model:

refuses to answer;
runs out of tokens before the answer is complete;
answers with something that isn’t JSON or doesn’t match the schema;
has its answer removed by the provider’s content filter.

So a later step never sees a half answer or a made-up field. See Error codes for what each failure means.

When the provider is busy or limits your rate, the step tries again up to 3 times in all, and waits as long as the provider asks, up to 60 seconds.

What Liitora sends and keeps

Sent: your prompt, your input as JSON and the output_schema. Liitora never sends who the end user is.
Logged with each call: the provider, the model, your prompt_version, the names of the input’s fields (not their values), the answer, the tokens used, why the model stopped, how long it took and the provider’s request ID. Secret values are masked, and the log is kept as long as your plan keeps run logs.
Not logged: the prompt and the input values. The HTTP log of an AI step keeps no request or response bodies.
Your API key stays in Liitora’s secret store and never appears in logs, results or errors.

Each run may use at most 100,000 AI tokens unless your plan says otherwise. Before each call Liitora checks that the call fits in what is left, and after it counts the tokens the provider reports. A call that would go over fails the step with ai_token_limit. See Limits per plan.

A step that calls a known AI provider’s address through platform/http.request or a script is marked as an AI step too.

Test it without calling the model

Workflow tests never call a real model. Give the answer in the test case under given.models, and the step reads it as if the model had answered. See Model mocks.

In a dry run, the call is not sent. The step’s output is empty and not_sent is true.

Sources

Written from the providers’ own documentation: