Connect Syteca to any ticketing system — not just the supported few
Syteca integrates directly with SysAid and ServiceNow. But every organization has its own ticketing reality — Jira Service Management, Freshservice, BMC Remedy, Cherwell, a homegrown system built ten years ago that nobody wants to replace. Waiting for a vendor to add support for your specific system isn’t an option when audit deadlines are real. The API Bridge removes that dependency. It’s a small REST service that you run, implementing a fixed three-endpoint interface Syteca calls. Build the adapter once in any language — Python, Go, .NET, Node, your existing internal stack — and Syteca can validate tickets against any platform you choose. New version of your ticketing system tomorrow? You update the Bridge, not Syteca.Use the API Bridge when you need to:
- Integrate Syteca with a ticketing system that isn’t natively supported (Jira, Freshservice, custom, in-house).
- Maintain ticketing integration independently of Syteca release cycles.
- Build a thin adapter once and have it work for every privileged session going forward.
What is the API Bridge?
Syteca’s ticketing system integration can require users to enter a ticket number before they log in to a Client computer. Supporting many ticketing systems directly inside the product is difficult: each system has a different API, each new system needs a new adapter, and any change to a system’s interface can require shipping a new version of Syteca. The API Bridge solves this by inverting the relationship. Instead of Syteca implementing each ticketing system’s API, Syteca defines one interface it expects, and you implement a service that satisfies that interface and talks to your ticketing system. The benefits:- Add support for any ticketing system — including custom ones — without a Syteca update.
- Build the service in any language; only the interface matters.
- Update your Bridge whenever your ticketing system changes, independently of Syteca.

The API Bridge sits between Syteca and your ticketing system, implementing a single fixed interface.
The REST interface
Your API Bridge must implement the three endpoints below. Each one expands to show its parameters, request body, response schema, and example request and response in several languages.These endpoints document the interface your Bridge implements — there is no Syteca-hosted server to call, so they are shown for reference only and have no live request panel. Your Bridge runs at your own address and port.
POST /connect — Request a session ID
Establish a session with the ticketing system and receive a session ID for subsequent calls.
GET /ticket-status — Get the ticket status
Validate that a ticket exists and is not closed. Returns status 0 (not found), 1 (active), or 2 (closed).
POST /add-ticket-comment — Add a comment to a ticket
Add a comment to the ticket, typically a link to the session in the monitoring results.
How to read the interface
Each path is an endpoint your service must expose. For example,/connect means that if your service runs at http://127.0.0.1:8080/, it must accept POST requests at http://127.0.0.1:8080/connect. Within /connect, the request body is optional.
The full machine-readable specification is available below for developers who want to generate a client or server stub.
View the full OpenAPI specification
View the full OpenAPI specification
api-bridge-openapi.yaml

The communication flow between the API Bridge and the Syteca Application Server service.
The source diagrams reference the legacy
EkranServer service name. Confirm the current service name during review and update the diagram accordingly.How to use the API Bridge
You can implement the service yourself in any language that suits your infrastructure. Two shortcuts are available:- Generate a stub from the OpenAPI spec. A free tool such as Swagger can generate a basic service from the specification above, in the language of your choice.
- Start from the sample service. Syteca provides an example service written in ASP.NET Core. You can compile it from source or run the prebuilt executable.
Run the sample service
The sample includes a JSON file with a basic set of ticket numbers so you can quickly test the Bridge. The JSON file is included in the archive alongside the sample code.1
Unpack the package
Unpack the
APIBridgePackage archive.2
Move the JSON file into place
Move the JSON file into the
wwwroot folder.3
Edit the JSON file
Open the JSON file in any text editor and define:
- In the Sessions section: the user credentials of your ticketing system.
- In the Tickets section: the name of the ticket the user must enter when logging in to the Client computer.
By default there are three ticket statuses:
0 — ticket not found; 1 — ticket active; 2 — ticket closed.4
Run the executable
In the
APIBridgeSampleBinaries folder, run IO.Swagger.5
Specify the port
In the console window, enter the port to use for the connection between Syteca and the ticketing system, then press Enter.
This is the same port you enter in the Management Tool when configuring the ticketing system integration.
6
Note the URL
The ticketing system URL is shown in the console window. You’ll use this when configuring the integration.
The screenshots and sample binaries referenced here date from an earlier release. Confirm the archive name, folder names (
wwwroot, APIBridgeSampleBinaries), and the IO.Swagger executable name still match the current sample package during review.Set up the Bridge in the Management Tool
Once your Bridge service is running, configure Syteca to use it. In the Management Tool, set the Ticketing System to API Bridge and enter the URL, port, login, and password. For the full steps, see Ticketing System Integration.Related
Ticketing system integration
Enable and configure ticketing integration in the Management Tool.
SDK overview
Other developer integration options for Syteca.