Zenduty

Proofroom reads Zenduty’s REST API with an account API key and files four kinds of evidence. Add it on Integrations → Catalogue → Zenduty → Connect.

What each collector shows

Collector Kind Default cadence What it shows Suggested controls
On-call schedule snapshot quarterly Each team’s escalation policies, schedules and who is on call now PCI DSS 12.10.3; SOC 2 CC7.3
Incident timelines window monthly Incidents created in the period, with acknowledge and resolve times and their alerts PCI DSS 12.10.5; SOC 2 CC7.4, CC7.5
Post-incident reviews window monthly Postmortems completed in the period, and those still in progress PCI DSS 12.10.6; SOC 2 CC7.5
Response plan changes window quarterly Changes to escalation policies and schedules since the last run (the first run records a baseline) PCI DSS 12.10.2; SOC 2 CC7.3

Setting it up

  1. In Zenduty, open your account page from the top right and go to API Keys. Click Create a new API key and copy it. Use the key of an account that can see the teams you want collected.
  2. In Proofroom, enter the key, and the team IDs to collect (one per line; leave empty for every team the key can see). Test connection lists the teams and names any configured team the key cannot see.

Proofroom only reads. The key is stored encrypted and never shown again.

How incidents are read

Incidents come from POST /api/incidents/filter/ with the period as from_date and to_date (ISO 8601) and status 0 (all), the filter Zenduty documents. Each next page is read with the same request. Every page is read; the run fails rather than file part of a period. With team IDs, incidents whose service names no team are left out and counted.

Limits

  • The on-call schedule shows who is on call when the run happens, not cover across the whole quarter.
  • Zenduty reports delays and shift lengths as plain numbers; the evidence reads them as seconds and says so.
  • “Completed” postmortems are read from their status text, which Zenduty does not document.

Unverified

  • That from_date/to_date read an ISO 8601 time with Z as UTC, and that a next page takes the same POST body (Zenduty’s OpenAPI documents the fields but not these details).
  • Whether the API answers to the Xurrent name in future; the address is www.zenduty.com.