canonical: https://jentic.com/apis/otobo.org/otobo

# OTOBO GenericInterface REST API

OTOBO (Open Ticket Based on OTRS) is an open-source ticketing and service management system. The GenericInterface REST API provides programmatic access to ticket operations, session management, and ticket lifecycle management. OTOBO is a fork of OTRS focused on open-source development and supports IT service management, customer support, and internal helpdesk workflows. The API enables integration with external systems for automated ticket creation, updates, and querying.

## For AI agents

Manage OTOBO tickets via REST API: create, read, update tickets, manage sessions, and integrate ticketing workflows with external systems.

## Scope

Does not manage OTOBO system configuration, user accounts, or queue setup - use only for ticket operations and session management via GenericInterface.

## Capabilities

- Create and authenticate API sessions for ticket operations
- Create new tickets with customizable fields including title, queue, priority, and customer info
- Retrieve ticket details including history, articles, and attachments
- Update existing tickets with new articles, status changes, and field modifications
- Search and query tickets by various criteria including queue, status, and customer
- Manage ticket lifecycle including assignment, escalation, and closure

## Use cases

### Automated Ticket Creation from External Systems

Integrate external applications, monitoring systems, or customer-facing forms with OTOBO ticketing. POST /Session creates an authenticated session, then POST /Ticket creates tickets with full metadata including queue, priority, customer info, and initial article. This enables automated ticket creation from monitoring alerts, web forms, email parsers, or chat systems without manual entry.

Example prompt: POST /Session with credentials to authenticate, then POST /Ticket with ticket data including title, queue, priority, customer info, and article content.

### Customer Portal Ticket Lookup

Build custom customer portals that retrieve ticket status and history from OTOBO. GET `/Ticket/{TicketID}` returns full ticket details including articles, attachments, and state. Customers can check ticket progress, view responses, and track resolution without accessing the OTOBO web interface directly.

Example prompt: POST /Session to authenticate, then GET `/Ticket/{TicketID}` to retrieve ticket details for display in the custom portal.

### Bi-Directional CRM and Ticketing Sync

Synchronize OTOBO tickets with CRM systems like Salesforce or HubSpot. PATCH `/Ticket/{TicketID}` updates tickets with new information from CRM, and GET /Ticket queries OTOBO for ticket status to update CRM records. Agents can work in either system while maintaining consistent ticket state across platforms.

Example prompt: GET /Ticket with search filters to retrieve updated tickets, then sync changes to CRM. When CRM records update, PATCH `/Ticket/{TicketID}` to reflect changes in OTOBO.

### AI Agent for Support Ticket Management

Let an AI agent handle routine ticketing tasks for a support team - creating tickets from customer inquiries, updating tickets with status changes, and retrieving ticket information for customer service reps. Through Jentic, the agent loads only the required operations and OTOBO credentials are injected at execution time.

Example prompt: Use the Jentic search query 'create otobo ticket' to find POST /Ticket, load its schema, and execute with ticket details from the customer inquiry.

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| POST | `/Session` | Create an authenticated API session |
| POST | `/Ticket` | Create a new ticket with full metadata and initial article |
| GET | `/Ticket/{TicketID}` | Retrieve ticket details including history and articles |
| PATCH | `/Ticket/{TicketID}` | Update an existing ticket with new articles or field changes |
| GET | `/Ticket` | Search and query tickets by various criteria |

## Key resources

- **Session** — Authentication sessions required for API operations
- **Tickets** — Support tickets with metadata including queue, priority, status, and customer info
- **Articles** — Ticket messages and communications including notes, responses, and customer replies
- **Queues** — Organizational units for categorizing and routing tickets
- **Ticket History** — Audit trail of ticket changes, assignments, and state transitions

## Why Jentic

- **Setup:** Wiring the OTOBO GenericInterface by hand means creating a session first, threading the SessionID through each ticket call, and pointing requests at your own hostname and webservice name in the endpoint path. Through Jentic you install once, import the OTOBO GenericInterface REST API from the API Directory, store the login credentials once, and your agent calls it.
- **Permission scoping:** OTOBO puts the ticket id in the URL path (`/Ticket/{TicketID}`), so a rule can pin your agent to reading one ticket. You choose the operations it may call, so ticket updates or creating a session are not included unless you add them, and a read-only agent can view tickets without changing them.
- **Credential handling:** Your OTOBO login credentials are stored once, encrypted, by your own Jentic One instance and injected at execution time. They never enter the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'create a support ticket' or 'read the details of a ticket', and Jentic returns the matching OTOBO operation with its input schema so the agent calls the right endpoint without browsing the reference docs.

## Related APIs

- **Zendesk API** — Cloud-based ticketing and customer support platform as an alternative to self-hosted OTOBO.
- **Freshdesk API** — Cloud helpdesk alternative to OTOBO with similar ticketing capabilities.

## FAQ

### What authentication does the OTOBO API use?

The OTOBO GenericInterface uses session-based authentication. First call POST /Session with username and password to create a session, then use the returned SessionID in subsequent requests. Through Jentic, credentials are stored encrypted and sessions are managed automatically.

### What is the relationship between OTOBO and OTRS?

OTOBO is an open-source fork of OTRS created after OTRS moved to a closed-source model. OTOBO maintains compatibility with OTRS while continuing open-source development. The API structure is similar to OTRS GenericInterface.

### How do I customize the base URL for my OTOBO installation?

The base URL includes your OTOBO hostname and web service name: https://{hostname}/otobo/nph-genericinterface.pl/Webservice/{webserviceName}. Replace {hostname} with your server and {webserviceName} with your configured GenericInterface web service name.

### Can I attach files to tickets via the API?

Yes, the POST /Ticket and PATCH `/Ticket/{TicketID}` endpoints support attachments in the Article section. Attachments are base64-encoded in the request payload.

### Is the OTOBO API compatible with OTRS integrations?

OTOBO maintains API compatibility with OTRS GenericInterface for most common operations, so many OTRS integrations work with OTOBO with minimal changes. However, specific features may differ between versions.

### Can I limit what my agent is allowed to do with the OTOBO API?

Yes. Because Jentic One is self-hosted and runs under your own rules, you decide which OTOBO operations the agent may call, so you can grant read-only access to GET `/Ticket/{TicketID}` and GET /Ticket while withholding POST /Ticket, PATCH `/Ticket/{TicketID}`, and even POST /Session. Since OTOBO carries the ticket id in the URL path, a rule can pin the agent to a single ticket rather than the whole queue. Your OTOBO login credentials stay with your instance and are supplied only at execution time, never in the agent's prompt or logs.