Report profile
INFO
A report profile is a saved, reusable filter/condition for Zammad's reporting module. It isn't an automation and doesn't do anything by itself. It's a named condition that shows up as a selectable view when generating reports with Zammad's reporting feature, scoped to whichever roles (role_ids) can see it.
Compare to core workflows, which uses a similarly-shaped condition object but does not validate referenced fields.
List
Required permission: admin.report_profile
GET-Request sent: /api/v1/report_profiles
Details
json
// HTTP-Code 200 OK
[
{
"id": 1,
"name": "-all-",
"condition": {},
"active": true,
"updated_by_id": 1,
"created_by_id": 1,
"created_at": "2026-09-30T07:55:54.147Z",
"updated_at": "2026-09-30T07:55:54.147Z",
"role_ids": []
},
{
"id": 2,
"name": "Open tickets (new or open)",
"condition": {
"ticket.state_id": {
"operator": "is",
"value": [
"1",
"2"
]
}
},
"active": true,
"updated_by_id": 3,
"created_by_id": 3,
"created_at": "2026-09-24T12:32:01.918Z",
"updated_at": "2026-09-24T12:32:01.905Z",
"role_ids": [
2,
1
]
}
]INFO
The list returns the full record for each profile, same field set as the Show response below. Entry 1 (-all-) is Zammad's built-in default profile.
Show
Required permission: admin.report_profile
GET-Request sent: /api/v1/report_profiles/{id}
Details
json
// HTTP-Code 200 OK
{
"id": 2,
"name": "Open tickets (new or open)",
"condition": {
"ticket.state_id": {
"operator": "is",
"value": [
"1",
"2"
]
}
},
"active": true,
"updated_by_id": 3,
"created_by_id": 3,
"created_at": "2026-09-24T12:32:01.918Z",
"updated_at": "2026-09-24T12:32:01.905Z",
"role_ids": [
2,
1
]
}Create
Required permission: admin.report_profile
POST-Request sent: /api/v1/report_profiles
Details
json
{
"name": "Open tickets (new or open)",
"condition": {
"ticket.state_id": {
"operator": "is",
"value": [
"1",
"2"
]
}
},
"active": true,
"role_ids": [
1,
2
]
}INFO
Role ids aren't guaranteed to be the same across instances. Look up the ids of the roles you need via the roles API first instead of hard-coding them.
INFO
Unlike core workflows, a report profile's condition does validate that referenced fields are real, fully-migrated ticket fields. Referencing a custom field that exists but hasn't finished its schema migration yet (to_create/to_migrate still true on that field) fails with:
Details
json
// HTTP-Code 422 Unprocessable Entity
{
"error": "Invalid object selector conditions",
"error_human": "Invalid object selector conditions",
"invalid_attribute": {
"condition": "Invalid object selector conditions"
}
}Update
Required permission: admin.report_profile
PUT-Request sent: /api/v1/report_profiles/{id}
Payload shape is identical to Create. The response is the updated record, same shape as Create's response.
INFO
Sending the full Create payload to an existing profile's id updates that record in place. It doesn't create a duplicate.
Details
json
{
"name": "Open tickets (new or open)",
"condition": {
"ticket.state_id": {
"operator": "is",
"value": [
"1",
"2"
]
}
},
"active": true,
"role_ids": [
1,
2
],
"id": 2
}Delete
Required permission: admin.report_profile
DANGER
This is a permanent removal
Please note that removing report profiles cannot be undone.
DELETE-Request sent: /api/v1/report_profiles/{id}
Details
json
// HTTP-Code 200 OK
{}