Skip to main content

​
Overview

The ITSM Write Endpoints feature allows you to programmatically create and update tickets in your connected IT Service Management (ITSM) systems directly through the Leen API. This enables powerful automation and workflow integration, allowing you to manage your ITSM resources without leaving your development environment. By using the ticket write endpoints, you can build integrations that:
  • Automatically create bug reports from CI/CD pipeline failures.
  • Generate tasks based on security alerts from other tools.
  • Keep ticket statuses synchronized with your internal systems.
  • Bulk-create tickets synchronously and get per-ticket results immediately.
A sample application demonstrating the create use case is available at the itsm-demo-app GitHub repository.

​
Supported Integrations and Operations

The availability of write operations depends on the specific ITSM connector.

​
Creating Tickets

When creating a ticket via POST /itsm/tickets, you can identify the target project, issue type, assignee, and parent ticket using either Leen UUIDs (from a prior sync) or vendor IDs (directly from the vendor system). The two forms are mutually exclusive per field. Using vendor IDs skips extra database lookups, which is useful when you have vendor data on hand and want to avoid a round-trip sync.

​
ServiceNow

ServiceNow organises tickets by table rather than by project. When creating a ServiceNow ticket:
  • project_id / project_vendor_id are not required. The target table (incident or problem) is derived automatically from type.
  • type must be "Incident" or "Problem".
  • Use the assigned_user_vendor_id field with the user’s sys_id (returned by List Assignable Users (Passthrough)).
The following optional fields are ServiceNow-specific and are ignored for other vendors:

​
Bulk Create Tickets (Sync)

POST /itsm/tickets/bulk/sync creates tickets synchronously using the vendor’s bulk create API and returns per-ticket results immediately — no job polling required. The response includes a summary and a results array in request order:
When vendor ID fields are used (project_vendor_id, assigned_user_vendor_id, etc.), local DB persistence is skipped and ticket_id will be null in the response. The created tickets will appear after the next connector sync. Batch size is capped at the same limit as async bulk create.

​
Passthrough Endpoints

Passthrough endpoints proxy requests directly to the vendor API, bypassing Leen’s normalized data store. They are useful for populating dropdowns and search UIs when configuring ticket creation — for example, to let users pick a project, issue type, or assignee without waiting for a full sync. All passthrough endpoints require a connection_id scoped to a supported vendor (Jira or ServiceNow ITSM). Vendor IDs returned by passthrough endpoints can be used directly in the _vendor_id fields of ticket create requests.

​
List Projects

Returns projects accessible via the connected vendor account. Supports offset pagination (limit, offset). Each project includes a vendor_id, name, project_type, and optionally an embedded list of issue_types.
  • Jira: vendor_id is the project key (e.g. PROJ).
  • ServiceNow: always returns two items — vendor_id: "incident" and vendor_id: "problem" — representing the available ticket tables.

​
List Issue Types

Returns issue types for the given project. project_key is the vendor project identifier — use vendor_id from the List Projects response. Each result includes a vendor_id that can be passed as type_vendor_id when creating a ticket.
  • Jira: vendor_id is the Jira issue type ID (e.g. 10034).
  • ServiceNow: this endpoint returns 404. ServiceNow does not use issue types — pass type = "Incident" or type = "Problem" directly when creating a ticket.

​
List Assignable Users

Returns users who can be assigned to issues in the given project. Accepts an optional query parameter to filter by name or email. Each result includes a vendor_id that can be passed as assigned_user_vendor_id when creating a ticket. Total count may be null depending on the vendor.
  • Jira: vendor_id is the Jira accountId. query filters by display name or email.
  • ServiceNow: vendor_id is the user sys_id. project_key is ignored — all active users are assignable to any table. query filters by display name or username (case-insensitive contains). Total count is always null.

​
Search Tickets

Search tickets using vendor-native query syntax.
  • Jira: use the jql query parameter with standard JQL syntax. Supports cursor-based pagination via cursor and limit (1–100, default 50). The next_cursor field in the response can be passed as cursor in the next request.
  • ServiceNow: use the table parameter (incident or problem, default incident) and the query parameter with ServiceNow encoded query syntax (sysparm_query). Supports offset pagination via limit and offset.

​
Passthrough vs. Synced Data