Skip to main content
Last updated: 15 November 2025

​
Overview

This page describes how Boomerang handles security incidents related to the Developer API, and what is expected from integrators when a security event is suspected or confirmed. It should be read together with: Those documents govern acceptable use, logging, and legal responsibilities. This page focuses on incident handling.

​
When and how to report incidents

All suspected or actual security incidents relating to the Developer API must be reported to:
If you suspect a security incident: treat any of the following as a security incident and notify [email protected] without delay:
  • Suspected or confirmed API token compromise
  • Unauthorised access to a server, dashboard, or integration
  • Unexpected API activity you cannot explain (for example, unusual request patterns, locations, or times)
  • Discovery of a technical vulnerability affecting Boomerang or the Developer API
When reporting an incident, include:
  • A short description of what you observed.
  • Approximate time range and affected servers.
  • Relevant identifiers (for example, server IDs, X-Request-Id, and trace_id values).
  • High-level context on any recent changes (for example, new deployments, key rotations).
Do not include raw tokens or passwords in incident reports.

​
Boomerang’s handling of incidents

When Boomerang receives a security report or detects an issue internally, it will:
  1. Triage and assess impact
    • Determine scope, likelihood, and potential impact on Boomerang, affected servers, and users.
    • Assess and prioritise based on impact, likelihood, and breadth of exposure.
  2. Contain and mitigate
    • Disable or restrict obviously compromised tokens or access paths.
    • Apply temporary safeguards or throttling where appropriate.
    • Increase monitoring on relevant systems and traffic patterns.
  3. Investigate and remediate
    • Review relevant logs and configuration, consistent with the Audit and Logging Behaviour page.
    • Identify root causes and contributing factors where possible.
    • Implement targeted fixes or configuration changes.
  4. Document and improve
    • Record outcomes and lessons learned.
    • Update controls, documentation, or guidelines where appropriate (for example, in Security Measures or release notes).
These steps reflect typical practice. Exact actions and timelines may vary depending on the nature and severity of the incident.

​
Notification and communication

Boilerplate communication approach:
  • Community announcements
    Significant incidents or security-impacting changes may be communicated via Boomerang’s community server (for example, Discord), particularly where operational behaviour or required user action is involved.
  • Status page updates
    Platform-wide or availability-impacting incidents may be reflected on https://status.bmrg.app, including current status and high-level remediation notes.
  • Changelog and release notes
    Minor security or hardening changes that do not require immediate user action may only appear in the changelog or release notes.
Where legally required or appropriate, Boomerang will also consider more direct communication with affected parties, in line with applicable law and the Boomerang Privacy Policy. Boilerplate:
  • Boomerang aims to communicate as promptly as reasonably practical, but does not provide specific response-time or notification SLAs.
  • Nothing in this page creates any guarantee of compensation, liability, or service credits; those matters are governed solely by the Terms of Service and related agreements.

​
Responsibilities for integrators

Integrators play a critical role in containing and mitigating security incidents involving their systems. When you suspect or confirm an issue affecting your environment, you are expected to:
  • Act immediately on your side
    • Revoke or rotate any affected API tokens as described in Authentication.
    • Disable or restrict access to compromised systems or accounts.
    • Apply emergency configuration changes (for example, tightening IP allowlists, disabling specific automated jobs).
  • Preserve evidence
    • Preserve relevant logs and configuration snapshots rather than deleting or overwriting them.
    • Retain details of deployments or configuration changes made shortly before the incident.
  • Share information safely
    • Provide Boomerang with X-Request-Id, trace_id, server IDs, and other non-secret identifiers when requested.
    • Avoid sending raw tokens, passwords, or other secrets by email; redact or truncate where identifiers are required for correlation.
  • Review your controls
    • Assess whether your own practices align with the expectations in Security Measures, particularly around key handling and environment design.
    • Remediate any identified weaknesses in your infrastructure, processes, or application code.
Failure to act promptly on your side may increase risk to your users and systems, and remains your responsibility.

​
Compliance posture and law enforcement

Depending on the incident, Boomerang may:
  • Take steps necessary to comply with applicable laws and regulatory obligations, including any mandatory breach notification requirements that apply to Boomerang.
  • Cooperate with law enforcement or regulatory bodies where legally required or where Boomerang considers it appropriate to protect users, platforms, or the service.
The Legal Statement and Boomerang Privacy Policy govern:
  • How personal information is handled during and after an incident.
  • Any notification obligations and Boomerang’s approach to regulatory compliance.
  • Limitations of liability and the extent of Boomerang’s responsibilities.
Nothing in this page changes or extends those obligations or limitations.

​
Relationship to other documents

In the event of a security incident, this page should be read alongside: Where there is any inconsistency, the Terms of Service and Privacy Policy prevail over this page.