RFC-144: Workspace Events API for Jira and Confluence audit logs

General Request for Comments (RFC)
, , , , , ,
1

RFC-144: Workspace Events API for Jira and Confluence audit logs

RFCs are a way for Atlassian to share what we’re working on with our valued developer community.

It’s a document for building shared understanding of a topic. It expresses a technical solution, but can also communicate how it should be built or even document standards. The most important aspect of an RFC is that a written specification facilitates feedback and drives consensus. It is not a tool for approving or committing to ideas, but more so a collaborative practice to shape an idea and to find serious flaws early.

Please respect our community guidelines: keep it welcoming and safe by commenting on the idea not the people (especially the author); keep it tidy by keeping on topic; empower the community by keeping constructive. Thanks!

Project Summary

Atlassian is proposing a unified Workspace Events API to provide a consistent method for retrieving Jira and Confluence audit events through a single endpoint.

  • Publish: 3 September 2026

  • Discuss: 17 September 2026

  • Resolve: 1 October 2026

Problem

Jira and Confluence currently expose product-specific audit log APIs that differ in paths, filters, pagination, and response structures. Apps supporting both products must handle these differences, which increases development overhead and maintenance complexity. Additionally, audit workloads range from small, bounded requests to broad searches that cannot reliably complete within standard synchronous execution budgets, leading to timeouts or incomplete data retrieval for large-scale security and compliance use cases.

By solving this, we aim to provide a reliable, scalable, and unified interface for security, compliance, and reporting apps. This proposal is not a deprecation announcement; existing product-specific APIs remain unchanged, and any future lifecycle changes would follow Atlassian’s standard API policies.

Proposed Solution

We are exploring a solution that provides a common Jira and Confluence audit event model with explicit workspace scoping. The proposed base URL is https://api.atlassian.com/admin/audit-log/v1.

For a detailed technical breakdown, please refer to the RFC-144: Workspace Events API OpenAPI Spec.

User Experience

The solution provides a cacheable event-action catalog. This allows for more consistent user interfaces in administrative tools that need to display published event-action IDs and metadata across different Atlassian products.

Developer Experience

The proposal introduces a unified query flow using Cloud Admin Vocabulary to identify workspaces.

Proposed Endpoints:

  • GET /event-actions: Return published event-action IDs and display metadata.

  • GET /workspaces/{workspaceId}/events: Retrieve events synchronously.

  • POST /workspaces/{workspaceId}/event-queries: Create a background event query.

  • GET /workspaces/{workspaceId}/event-queries: List the caller’s background queries.

  • GET /workspaces/{workspaceId}/event-queries/{queryId}: Retrieve query state and details.

  • GET /workspaces/{workspaceId}/event-queries/{queryId}/results: Retrieve completed results.

  • POST /workspaces/{workspaceId}/event-queries/{queryId}/cancel: Request query cancellation.

The API would support cursor-based pagination and typed filters including from, to, action, actor.id, and q for text-based matching across context attributes.

Trust Experience

Workspace event operations would require specific authentication scopes and permissions to administer the requested workspace.

  • Jira OAuth 2.0: manage:jira-configuration, or read:audit-log:jira plus read:user:jira.

  • Jira Connect: READ scope for migration compatibility.

  • Confluence OAuth 2.0: read:audit-log:confluence.

  • Confluence Connect: Not currently proposed.

Ecosystem Impact

The API is intended to provide a common migration target. While not a drop-in replacement, it simplifies the logic for apps that consume audit logs from multiple products. We are considering an execution model where requests exceeding the synchronous budget return a 422 ASYNC_QUERY_REQUIRED response, directing the client to the background-query collection.

Asks

While we would appreciate any reactions you have to this RFC (even if it’s simply giving it a supportive “Agree, no serious flaws”), we’re especially interested in learning more about:

  1. Execution model: Can your client handle a 422 fallback to create a background query? Would you prefer to submit larger searches asynchronously from the start?

  2. Filters: Which filters (e.g., IP, actor, action) are essential for your initial integration?

  3. Text Search: How do you intend to use the q parameter for free-text matching? Are there specific attributes you expect it to cover?

  4. Pagination: Are there blockers in migrating from offsets to opaque cursors and links.next?

  5. Migration: Which current Jira or Confluence fields or behaviors would block your adoption of this new API?

  6. Impact: Are there other ways this unified API may impact your workflow that we haven’t anticipated?

If you are interested in participating in the Early Access Program (EAP), please provide your details via our Public EAP Interest Form.