What we do · Platforms
Managed Request Tracker with partner bridges
Request Tracker is the open ticketing system that serious support desks have trusted for decades. We run it for you on your own server, and when your customers, suppliers or partners work in their own portal, we build a two way bridge so their tickets arrive in your queue and your replies arrive back in their portal. Nobody retypes anything, and nothing falls between two systems.
What it is
A managed Request Tracker instance, dedicated to your organisation: queues, mail intake, permissions, scrips and history, run and kept current by our engineers. It is the same platform our own support desk runs on, every customer queue in one system.
On top of it, partner bridges. A bridge connects one of your queues to someone else's ticketing portal so the two behave like one desk. Their customer opens a ticket in their portal; it lands in your queue. Your engineer replies in Request Tracker; the reply appears in their portal under the right ticket, attachments and links included. Internal comments stay internal.
How we build it
The platform runs on Oracle Linux with SELinux enforcing, behind our own firewalls, with mail passing through our mail security layer before it reaches a queue. Security releases are applied together with operating system patching in one planned window.
Each bridge is built in two directions, each with its own protection:
- Inbound uses Request Tracker's REST interface with a token scoped to exactly one queue. The same token is refused on every other queue, so a partner can never read or write anything outside the work you share.
- Outbound is a signed webhook. Every delivery carries a signature the partner verifies, so their portal accepts replies from your desk and from nobody else.
- Loops are prevented by design and tested. A reply that came from the partner is never sent back to the partner.
- Privacy follows Request Tracker's own model. Replies cross the bridge, comments never do, so your engineers can discuss a ticket freely inside the queue.
- Attachments travel both ways, and we verify them by checksum end to end, not by eye.
- Oversized content is handled on arrival. A huge inline image pasted into a partner ticket is trimmed at the door, with the original kept on disk, so one heavy ticket cannot slow the desk for everyone.
- Nothing is dropped silently. Deliveries retry with backoff, anything undeliverable is parked and swept again on a schedule, and every delivery is logged.
Notifications can go straight into your team chat. New tickets and replies post into the channel your engineers already watch, through a worker that never holds up the ticketing interface while it delivers.
What it protects you from
- Two ticketing systems and a human copying text between them, with the mistakes that come with it.
- A reply your customer never receives because an integration failed without telling anyone.
- A partner integration that can see more of your desk than the work you share.
- Internal discussion leaking into a customer facing portal.
- One oversized ticket making the whole desk slow.
- A ticketing system nobody has patched, holding years of customer correspondence.
In practice
For a managed services partner we designed a bridge between their customer portal and our Request Tracker, then built it and took it live in a single evening with both teams in the room. The acceptance test was a screenshot sent from their portal into our queue and back out again, arriving with an identical checksum at both ends.
The bridge kept growing with the partnership. It now also opens tickets in the partner's portal when work starts on our side, carries the real name of the engineer who answered, and preserves links inside replies so a customer can click straight through. Each addition shipped switched off, was proven on a live ticket, and only then was turned on.
Why EuroVPS
- Request Tracker is not a side product for us. It runs our own support desk.
- Bridges are engineered: scoped tokens, signed deliveries, tested loop prevention, checksum verified attachments.
- Every delivery is logged and retried, so silence means nothing was sent, not that something was lost.
- Hosted in our own datacenters in Athens, Amsterdam or Toronto, under a pull only backup design.
FAQ
Can you bridge to a portal that is not Request Tracker? Yes. The bridge only needs the other side to accept a signed webhook and call a REST interface. We work with the partner's developers on the contract and test it with them.
Can our partner see our other queues? No. Their token works on the one queue you share and is refused everywhere else.
Can you take over our existing Request Tracker? Yes. We bring across queues, users, history and attachments, then keep it patched and monitored.
What happens if the partner's portal is down? Your replies wait and retry automatically, and anything that cannot be delivered is held and sent again later. Nothing is thrown away.
Can tickets notify our team chat? Yes, into the channels you choose, including on a Mattermost instance we run for you.
One desk, many systems, no copy and paste. Talk to an engineer.
Your next infrastructure partner
Let’s look at
your setup.
Tell us what you run today and what needs to improve. An engineer will review your brief and help you plan the next step.
+357 222 32280
who will look after your infrastructure.
Let’s start with your setup.
A little context helps us start the right conversation.