Redmine webhooks integration

Redmine sends an outgoing HTTP request to the endpoint you register when a subscribed event occurs, so the receiver carries most of the reliability work. Plan for three conditions: deliveries can repeat, they can arrive out of order, and they can arrive long after the change they describe. Each event therefore needs an identifier or timestamp that the receiver uses to recognize a duplicate and to decide which version of an issue is newest. Make every handler idempotent. A chat notification that posts twice is a nuisance, but a CI job that starts twice or a time entry that is created twice creates cleanup work. Store the identifiers of processed events for long enough to cover replays, and compare timestamps before overwriting state. Before you build, confirm in the Redmine 7.0 documentation which identifying fields the request body carries.

Webhooks are not the only way to move Redmine data into another tool. The REST API returns data when your application asks for it, and the Redmine REST API documentation marks core resources, including issues, projects, users and time entries, as stable. Polling is simpler to reason about because your application controls the timing, and it gives you a reconciliation path when a push is missed. The cost is latency and request volume, which grow with the number of projects and the polling interval. Webhooks suit alerts and chat messages where minutes matter, while polling suits periodic reports and backfills. Many teams run both: webhooks for immediate reactions, plus a scheduled query for issues updated since the last successful run. Confirm the stability status of webhook payloads and of wiki, news and version data in the 7.0 documentation before relying on them, since the stable resources named in the REST API documentation do not include those.

Verify the signature before the receiver trusts anything in the body. The check depends on the exact algorithm, the secret, and the bytes that are signed, so confirm all three in the Redmine 7.0 documentation and test them against captured samples. Reject any request whose signature does not match, and verify the raw body before parsing it, because a parser that normalizes whitespace or key order can change the bytes you check. Keep the signing secret in your secrets manager and out of visible workflow fields. Plan rotation as well: decide how the receiver accepts the old and new secret during a change window. Finally, decide where the endpoint lives. It must be reachable from the Redmine server over the network path your security team has approved, and it should be served over TLS on infrastructure you control.

Test with a sample event from each subscribed type before you connect production projects. In a staging Redmine instance, make one actual change per type, record the full request body and headers, and check that the body contains the fields your handler needs. Verify the signature with your implementation using the documented method, and confirm that a tampered body fails verification. Replay the same sample twice to confirm that your deduplication holds. Send two updates to one issue in reverse order to confirm that your handler keeps the newer state. Then have the receiver return an error on purpose and observe what Redmine does next. Do not assume a retry schedule or a retry count. Record what the 7.0 documentation states or what your own tests show, and design the reconciliation query to cover any gap that remains. Keep the captured samples as regression fixtures for future upgrades.

Redmine 7.0 webhooks send event data to an address you define, so something must receive, verify and act on each request. You can point them at an automation platform that runs workflows for you, or at an endpoint your team writes and operates. Neither option depends on a Redmine connector, and this page does not assume one exists. Before you commit, check each platform's catalog for a Redmine trigger, and treat any listed node as unverified until a test event from your own Redmine instance passes through it. Decide early, because the choice sets your license exposure, your plan costs and who patches the receiver.

For an automation platform such as n8n, the license comes first. n8n is fair-code under the Sustainable Use License, which permits use or modification only for your own internal business purposes or for non-commercial or personal use. Distribution is allowed only free of charge and for non-commercial purposes. Files with .ee in their name or directory are outside that license and need a valid n8n Enterprise License. If the receiver will serve customers, partners or other organizations, have counsel test that use against the license text before the design is fixed. Confirm which files your chosen version contains, because the answer determines whether an Enterprise License is needed.

Plan tier also changes what you can run. According to n8n's pricing page, SSO and LDAP, environments with Git, and log streaming are included only in the Business and Enterprise plans. Business is listed at 667 euros per month billed annually and is currently self-hosted only, while Enterprise uses custom pricing. Queue mode, which spreads webhook handling and executions across workers, requires the main instance's encryption key to be shared with every worker and webhook processor, so key distribution becomes part of your security design. Multi-main high availability is limited to Enterprise self-hosted deployments. Ask how bursts of events from busy projects are counted, since n8n counts each whole workflow run as one execution.

A custom endpoint suits teams that need tight control over what leaves Redmine and how each request is checked. Your code can verify the request signature before parsing the body, drop fields that chat or CI systems should never receive, write its own audit log and run inside the same network controls as Redmine. The trade-off is ownership. Your team or a partner builds the handler, tests it against each Redmine event type, keeps its dependencies patched, and handles retries and failed deliveries. Illustrative example: a handler that forwards only issue status changes to a CI system still needs its own tests and an alert when deliveries fail.

Before committing to either option, confirm current pricing and license terms with the vendor in writing. Ask how the license applies to your intended use, whether the features you need sit in your target plan, and which terms apply to the version you will deploy. Record the date you received them. Then test in a staging Redmine project with a real event for each type you plan to send, plus a deliberately failed delivery, so the decision rests on observed behavior and a written scope.