---
title: "Redmine Integration"
description: "Connect AI agents to your Redmine instance. Agents file and update issues, log time entries, and read projects, trackers, statuses, and users through the REST API using your instance URL and API key."
url: https://flowrunner.ai/integrations/redmine
date_modified: 2026-08-01T02:40:32-07:00
---

# Redmine

[Project Management](https://flowrunner.ai/integrations/category/project-management-productivity)

Connect AI agents to your Redmine instance. Agents file and update issues, log time entries, and read projects, trackers, statuses, and users through the REST API using your instance URL and API key.

[Verified](https://flowrunner.ai/integrations/verified "What does verified mean?") · 12 actions · API key · available

[Redmine website](https://redmine.org/) · [Platform Documentation](https://www.redmine.org/projects/redmine/wiki/Rest_api) · Capability data verified 2026-07-28

1.  A monitoring alert or support form submission reports a failure
2.  List Issues sweeps the project for an open issue matching the signature so duplicates never fork the history
3.  List Trackers and List Issue Statuses resolve the tracker and opening status this instance actually uses
4.  Create Issue files the report with description, priority, and project, returning the new issue ID
5.  The issue is scored against the severity rubric using the alert payload
6.  The project lead confirms severity and assignment on anything scored critical before engineers get paged
7.  Update Issue records the triage decision as a note and sets the assignee
8.  The team channel gets the issue ID, severity, and owner

## What This Integration Enables

Redmine endures where flashier trackers churn because teams that run on it treat the issue as the unit of record: every bug, feature, and support request numbered, historied, and reportable, often across a decade of projects. The weakness was never the model, it was the manual labor of feeding it. FlowRunner agents do the feeding: filing issues from the systems where problems first appear, syncing status from the systems where work actually happens, and logging time from the workflows that watched it get done, all against your instance with its own trackers and statuses respected.

-   File issues automatically from forms, support tickets, and monitoring alerts, deduplicated first
-   Keep status, assignee, priority, and done ratio in sync with external systems and approvals
-   Log billable and internal time against issues and projects, with review before billing
-   Report on open issues, projects, and logged hours in spreadsheets and chat
-   Resolve project, tracker, and status IDs so workflows fit the instance instead of assuming it

### Without FlowRunner

**Bugs arrive by hallway**: Reports live in chat threads, inboxes, and memory, and half of them never become tracked work

**Status syncs by nagging**: Work completed in other systems reaches Redmine when someone remembers to update the ticket

**Timesheets reconstructed on Friday**: Hours get guessed at week's end, and the guesses become the invoices

### With FlowRunner

**Every report becomes an issue**: Deduplicated, filed under the right tracker, and triaged the same day it arrives

**Status flows both ways**: External completion events update the issue with status, done ratio, and an explanatory note

**Time logged as work happens**: Entries are proposed by the workflows that saw the work, and confirmed before they touch a billable project

## Use Case Scenarios

### The bug report that files itself correctly

A new response arrives in [Typeform](https://flowrunner.ai/integrations/typeform) from the customer-facing bug form. The agent checks List Issues for an existing open match, resolves the Bug tracker via List Trackers, and calls Create Issue in the right project with the form's answers structured into the description. [Slack](https://flowrunner.ai/integrations/slack) posts the new issue ID to the engineering channel. Reporters get a reference number, engineers get a clean queue, and nothing evaporates in a DM.

### One timekeeping truth from two systems

Half the team logs hours in Redmine, half in [Harvest](https://flowrunner.ai/integrations/harvest). Weekly, the agent pulls List Time Entries filtered by project alongside Harvest's log, consolidates both into [Google Sheets](https://flowrunner.ai/integrations/google-sheets) keyed by person and project, and flags the gaps: days with no entries, issues with estimates but no logged time. The operations lead reviews one report instead of two systems, and the invoice draft starts from reconciled hours.

### The ticket that closes itself when the work ships

A deploy pipeline finishes the fix. The workflow calls Update Issue to set the resolved status, push the done ratio to 100, and append a note with the release version, then posts the resolution to the stakeholder channel. The customer-visible answer to "is it fixed" lives on the issue, in the record that will still be searchable three years from now.

## Human-in-Loop Highlight

Create Time Entry looks harmless next to a delete button, but on a client-billable project its output becomes an invoice line, and an invoice that reaches a client cannot be quietly recalled. Automated timekeeping that logs wrong hours does not just corrupt a report, it manufactures a billing dispute with your best customer. So FlowRunner flows split the action by consequence: entries against internal projects log automatically, while entries bound for billable projects queue as proposals: "Workflow observed 6.5 hours on issue 4302 (Meridian retainer) this week across three sessions. Log to the project?" The delivery lead confirms or corrects, and only then does Create Time Entry write. The [human-in-the-loop](https://flowrunner.ai/concepts/human-in-the-loop) gate sits where hours become money.

Agent processes routinely

Detects exception requiring judgment

Clear match Continues automatically

Ambiguous Routes to human via preferred channel

Human decides

Agent resumes with decision

## Agent Capabilities

12 actions

### Issues

4

-   **List Issues** Retrieves issues filtered by project, status, assignee, or tracker, with Open, Closed, and All shortcuts and full pagination. The dedup check and the reporting feed.
-   **Get Issue** Retrieves one issue by ID with project, tracker, status, priority, assignee, and progress, optionally including journals, attachments, relations, children, and watchers. The full history behind any decision.
-   **Create Issue** Creates an issue with project and subject required, plus tracker, priority, assignee, dates, estimate, and parent as needed, returning the assigned ID. The intake step for every reporting source.
-   **Update Issue** Updates any subset of an issue's fields and appends notes to its history, optionally private. The synchronization write that keeps Redmine truthful about work done elsewhere.

### Projects

2

-   **List Projects** Retrieves the projects the authenticated user can access with identifiers, status, and timestamps. The scoping read for multi-project automation.
-   **Get Project** Retrieves one project by ID or slug, optionally including trackers, categories, and enabled modules. The configuration check before filing into unfamiliar territory.

### Time Tracking

2

-   **List Time Entries** Retrieves logged time filtered by issue, project, or user, each entry carrying hours, activity, date, and comments. The reporting feed for consolidated timekeeping.
-   **Create Time Entry** Logs hours against exactly one issue or project, with activity, comments, and date. The operation this page's human gate exists for on billable projects.

### Users

2

-   **List Users** Retrieves users filtered by status or name search, requiring administrator privileges. The roster behind assignment logic.
-   **Get Current User** Retrieves the API key's own account with ID, login, and admin flag. The credential check and self-ID resolution step.

### Instance Configuration

2

-   **List Issue Statuses** Retrieves the instance's configured statuses with their IDs and closed flags. The resolution step that keeps workflows portable across instances.
-   **List Trackers** Retrieves the instance's trackers, Bug, Feature, Support, and whatever else this instance defines, with IDs and default statuses. The other half of instance-aware filing.

## Frequently Asked Questions

### What can FlowRunner do with Redmine?

FlowRunner agents can run List Issues, Get Issue, and Create Issue in Redmine, plus 9 more actions.

### Does connecting Redmine to FlowRunner require OAuth?

No. Redmine connects to FlowRunner with an API key, no OAuth flow required.

### Can Redmine trigger a FlowRunner workflow automatically?

Redmine doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.

**Work at Redmine?** This integration exposes Redmine to AI agents on every FlowRunner plan, including through MCP, at no cost to you. [See what FlowRunner offers integration partners](https://flowrunner.ai/integrations/partners), including how to keep this page current.

---
Markdown version of https://flowrunner.ai/integrations/redmine. Site index: https://flowrunner.ai/llms.txt
