Short answer: The Aamu Reports API returns project-scoped user activity totals, day/week/month time series, and cursor-paginated event timelines. Active days include all matching activity types rather than comments alone.
Activity reporting sounds simple until “active” needs a precise meaning. Counting comments alone misses commits, task changes, documents, meetings, files, support work, and database edits. Counting only current records loses the sequence of actions that produced the current state.
Aamu.app addresses this with project-scoped user report endpoints backed by normalized activity events. You can request compact totals and time series for dashboards, or retrieve the underlying safe event metadata grouped by the user’s local calendar day. He there … hello…
The reporting API is designed for questions such as:
How many days was each project member active during a period?
How many actions, comments, commits, branches, and pull request changes did they make?
Which items did a user work with on a particular day?
How does activity change by day, week, or month?
Can an integration build its own project dashboard without scraping the Aamu UI?
An active day is not a comment-specific metric. It is a calendar day on which the user generated at least one matching activity event. That event may come from Tasks, Docs, Git, Helpdesk, meetings, files, databases, comments, or another supported project feature.
Create a Team API key with Reports read access for the project. Report requests use the same project headers as the other Aamu REST APIs:
x-api-key: YOUR_API_KEY
x-project-id: YOUR_PROJECT_IDA Reports key does not need write access. The underlying activity-event collection is server-owned; integrations read the reporting representation instead of writing reporting events themselves.
from is inclusive and to is exclusive. Both accept ISO 8601 values. When omitted, the API returns the latest 30 days up to the current time. One request can cover at most 366 days.
timezone is an IANA timezone such as Europe/Helsinki. It determines where calendar days begin and how interval boundaries are calculated. interval can be day, week, or month.
from=2026-07-01
to=2026-08-01
timezone=Europe/Helsinki
interval=weekThis distinction matters around midnight and daylight-saving changes. The timestamps identify the range; the timezone defines the calendar used to group it.
curl "https://YOUR_AAMU_HOST/api/v1/reports/users/?from=2026-07-01&to=2026-08-01&timezone=Europe/Helsinki&interval=week" \
-H "x-api-key: YOUR_API_KEY" \
-H "x-project-id: YOUR_PROJECT_ID"The response contains project totals, one value map per user, and continuous intervals. Empty intervals are included with zero values, which makes the result convenient for charts without a separate gap-filling step.
{
"report": {
"project": { "id": "YOUR_PROJECT_ID" },
"range": {
"from": "2026-07-01T00:00:00.000+03:00",
"to": "2026-08-01T00:00:00.000+03:00",
"timezone": "Europe/Helsinki",
"interval": "week"
},
"metrics": [
"activity.events",
"activity.active_days",
"comments.created",
"git.commits"
],
"totals": {
"activity.events": 184,
"activity.active_days": 22,
"comments.created": 41,
"git.commits": 36
},
"users": [
{
"user": {
"id": "USER_ID",
"username": "ada",
"name": "Ada Lovelace",
"email": "ada@example.com"
},
"values": {
"activity.events": 67,
"activity.active_days": 14,
"comments.created": 18,
"git.commits": 21
}
}
],
"intervals": [
{
"from": "2026-07-01T00:00:00.000+03:00",
"to": "2026-07-06T00:00:00.000+03:00",
"totals": {
"activity.events": 29,
"activity.active_days": 5,
"comments.created": 7,
"git.commits": 8
},
"users": [
{
"user_id": "USER_ID",
"values": {
"activity.events": 12,
"activity.active_days": 4,
"comments.created": 3,
"git.commits": 4
}
}
]
}
],
"data_coverage": {
"activity_events_available_from": "2026-06-15T09:00:00.000+03:00",
"historical_backfill_complete": false
}
}
}Because the requested range starts in the middle of a calendar week, the first returned interval is clipped: it begins at 2026-07-01 and ends at the next Monday boundary. Clients should use the interval boundaries returned by the API.
Use users with comma-separated user ids or usernames to limit the project report. Use metrics to request only the values the client needs:
curl "https://YOUR_AAMU_HOST/api/v1/reports/users/?users=ada,grace&metrics=activity.events,activity.active_days,comments.created,git.commits&from=2026-07-01&to=2026-08-01&timezone=Europe/Helsinki&interval=day" \
-H "x-api-key: YOUR_API_KEY" \
-H "x-project-id: YOUR_PROJECT_ID"The first reporting version supports these metrics:
activity.events — all matching activity events.
activity.active_days — distinct local calendar days with activity.
activity.distinct_items — distinct item type and item id pairs touched.
comments.created — comments created across supported item types.
git.commits and git.branches_created.
git.pull_requests_created, git.pull_requests_merged, git.pull_requests_closed, and git.pull_requests_reopened.
Project totals are calculated as project-wide distinct values where appropriate. For example, project active days are not produced by adding every user’s active-day count, because several people can be active on the same date.
Use a username or user id in the path:
curl "https://YOUR_AAMU_HOST/api/v1/reports/users/ada?from=2026-07-01&to=2026-08-01&timezone=Europe/Helsinki&interval=month" \
-H "x-api-key: YOUR_API_KEY" \
-H "x-project-id: YOUR_PROJECT_ID"The one-user endpoint returns the same range and metric definitions, but exposes one user, one values object, and interval values without repeating a project user list.
Totals are useful for dashboards, but they do not explain the work behind a number. The activity endpoint returns safe event metadata grouped by the user’s local calendar date:
curl "https://YOUR_AAMU_HOST/api/v1/reports/users/ada/activity?from=2026-07-01&to=2026-08-01&timezone=Europe/Helsinki&limit=100" \
-H "x-api-key: YOUR_API_KEY" \
-H "x-project-id: YOUR_PROJECT_ID"{
"activity": {
"user": {
"id": "USER_ID",
"username": "ada",
"name": "Ada Lovelace",
"email": "ada@example.com"
},
"project": { "id": "YOUR_PROJECT_ID" },
"range": {
"from": "2026-07-01T00:00:00.000+03:00",
"to": "2026-08-01T00:00:00.000+03:00",
"timezone": "Europe/Helsinki",
"interval": "day"
},
"summary": {
"active_days": 14,
"event_count": 67
},
"days": [
{
"date": "2026-07-31",
"events": [
{
"id": "ACTIVITY_EVENT_ID",
"type": "git.commit.created",
"category": "git",
"action": "commit_created",
"actor_id": "USER_ID",
"occurred_at": "2026-07-31T12:42:10.000Z",
"item": {
"type": "git_commit",
"id": "COMMIT_SHA",
"title": "Improve report export"
},
"source": "gitea",
"context": {
"commit": {
"sha": "17a41d2",
"message": "Add report export"
}
}
}
]
}
],
"pagination": {
"limit": 100,
"next_cursor": "OPAQUE_CURSOR"
}
}
}The API deliberately returns event metadata rather than private comment bodies or database cell values. A comment event can identify the comment and its parent item without copying the comment text into the reporting store.
categories filters broad groups such as git, comments, tasks, docs, helpdesk, meetings, and databases. types filters exact event names such as task.comment.created or git.pull_request.merged.
curl "https://YOUR_AAMU_HOST/api/v1/reports/users/ada/activity?categories=git,comments&types=git.commit.created,task.comment.created&from=2026-07-01&to=2026-08-01&timezone=Europe/Helsinki" \
-H "x-api-key: YOUR_API_KEY" \
-H "x-project-id: YOUR_PROJECT_ID"The summary respects the same range and filters. It describes the complete matching result, not only the current page.
Activity is ordered from newest to oldest. A page contains at most 100 events by default, and limit can be between 1 and 500. When next_cursor is not null, pass it unchanged in the next request:
GET /api/v1/reports/users/ada/activity?from=2026-07-01&to=2026-08-01&cursor=OPAQUE_CURSORTreat the cursor as opaque. It represents the last event position and avoids the duplicate-or-missing-event problems that page numbers can create while new events are arriving.
Activity events are collected when actions happen. They are not reconstructed from the current state of a task, ticket, document, or repository. This preserves who did what and when, but it also means the first version does not invent complete history from records that existed before activity-event collection was enabled.
Check data_coverage.activity_events_available_from before comparing old periods. While historical_backfill_complete is false, a zero before the available-from timestamp means “not collected,” not necessarily “no activity.”
The API provides facts and timelines, not a universal productivity score. A commit, a customer reply, a planning comment, and a document edit are different kinds of work. Their value depends on the project and cannot be inferred reliably by adding them together.
A useful report therefore combines several views: active days for continuity, event categories for the shape of work, item-level activity for context, and the underlying project outcomes. The Aamu reporting API supplies the activity layer while leaving the interpretation visible to the team building the dashboard.
For authentication, user lookup, and the rest of the API surface, see Building with the Aamu API: From Tasks to Docs and GraphQL.
An active day is a local calendar day on which the user generated at least one matching activity event, including supported task, comment, Git, document, meeting, file, Helpdesk, or database activity.
The timezone query parameter accepts an IANA timezone and controls calendar-day and interval boundaries. It defaults to UTC.
No. Reporting events contain safe metadata such as event type, item identity, timestamps, and limited context; private comment bodies and database cell values are not copied into the reporting store.
Not necessarily. The data_coverage object reports the first available event timestamp and whether historical backfill is complete.