mcp:reporting:read scope, not REST API keys. The MCP server exposes read-only tools for quizzes, surveys, tracks, activities, workspace members, member status, and account usage.
Base URL
All API requests should be made to:Available Endpoints
Quizzes
The Quiz API allows you to retrieve quiz data and detailed analytics reports:
Questions, participant responses, and question analytics are typed. Each has a
type, multiple_choice or free_text, and one object named after that type holding its specific fields:
free_text.accepted_answers instead. In a report, a response carries multiple_choice.selected_options or free_text.text, and question analytics carry the answer key with the counts: multiple_choice.options says how often each option was picked and whether it is correct, and free_text.accepted_answers lists the answers that count as correct. Every response also has a grading object: method is ai when a model judged a free-text answer, with match saying how closely it matched and matched_answer naming the accepted answer it was counted as, and owner when a quiz admin set the result by hand. status is pending while that answer waits to be scored.
Tracks
The Track API lets you read track definitions and progress and enroll users. Each step has aday, counted in the Track’s working days from enrollment (0 is the enrollment day), and a time such as 09:00; null uses 9:00 AM.
catch_up controls steps missed because a run starts late or a blocked step becomes eligible late. true makes them eligible in order during catch-up hours. false shifts the anchor to the next working day. Processing delays send already-due steps late without shifting the schedule. Expired preboarding steps retain their separate skip rules.
working_hours contains days_of_week, start_time, end_time, and an IANA time_zone. Per-person runs evaluate working days and catch-up hours in the enrolled person’s time zone, including both time boundaries. time_zone is the fallback when that person has no time zone. A Track value of null inherits the workspace policy. A legacy Track that omits working_hours keeps run_days as its working-day list while inheriting workspace/default hours and time zone. An enrollment request can override all four fields. Each enrollment snapshots the resolved policy, so later workspace or Track policy changes do not affect it.
For new runs, catch-up hours expand to include the earliest and latest step times across the track. A step without a time uses 09:00. This also applies to custom and enrollment overrides; it does not change run days. The expanded window is snapshotted when the run starts. Per-person runs use the enrolled person’s timezone; broadcast runs use the track or cohort timezone, independent of recipients.
For schedule triggers, frequency: "once" schedules one run at the configured start date and time. The read-only next_run_at field contains the next scheduled run time. It is null for draft or paused tracks and after Doozy finishes processing a one-off schedule. Updating other track fields does not schedule another run. To schedule another run, change the start date, time, or time zone.
Track reports return
instances and top-level total_instances.
reporting_unit is enrollee for per-person tracks and group_run for
broadcast and cohort-wide tracks.
Report rows can have a scheduled status when their start time is in the future.
Broadcast tracks use manual_group_trigger or schedule_group trigger types.
Their GroupTrackRun rows describe audience delivery, without an enrolled person.
Set include_step_results=true on a per-person Track report to include activity results. Task-step results include the total progress and each task item in its assigned order, with its Markdown details, completion status, and completion time. Group-run steps report delivery progress; use the child activity’s report for participant results.
step_analytics.completion_rate is the percentage of matching enrollees or group runs that reached the step and completed it. For group runs, completion means successful audience delivery. For a tasks step, task_completion_rate separately reports the percentage of assigned task items completed across those enrollees. task_breakdown lists each task item in order with its assigned count, completed count, and completion rate.
Every step in a Track response has a title and a display_title. title is the name an admin set on the step, and is null when none was set. display_title is read-only and is the name to show: the step’s title, or, for a survey, poll, or quiz step without one, the name of the survey or quiz it sends. It is null when neither exists. To rename a step, set title.
When an enrollment is canceled, the API returns untouched future steps with a canceled status. It derives these steps from the Track definition without creating step-progress records.
Surveys
For named surveys, the report and trend endpoints accept
audience_groups, a
JSON-encoded array that can combine department or group IDs, country codes,
states or regions, cities or towns, work-location IDs, and direct-manager user
IDs. Audience groups use OR logic, populated conditions inside a group use AND
logic, and values inside a condition use OR logic. Up to 10 groups and 50 values
per condition are accepted.
The existing group_ids, work_location_ids, and manager_ids parameters are
a one-group shorthand. audience_groups takes precedence when both forms are
provided. Anonymous surveys do not accept demographic filters.
Introductions
Account
The Account API manages two owner-only workspace settings found under Settings → Members & access: access rules (who gets Doozy access) and permissions (which roles can schedule each activity type; celebrations, one-off celebrations, and time off are fixed to owners and managers). The API calls access rulesprovisioning and the Admin role owner.
Access removal
auto_disable_users controls whether people lose access when they are removed or deactivated in Slack, in every provisioning_mode. In automatic mode it also controls whether non-owners lose access when they stop matching the configured group or HR-record conditions. Slack removal applies to owners too, except the last owner still in Slack, who keeps access. It does not apply to people who have never had a Slack account. Uninstalling the Doozy integration preserves workspace access, including owner access to reconnect Slack. After reconnection, the sync applies auto_disable_users to people removed or deactivated in Slack while the integration was uninstalled. HR termination removes access from non-owners independently of these settings.
Existing individually granted filter exceptions stay in place until an Admin reviews and confirms new access rules.
Assigning an active role does not bypass access rules. Explicitly disabling a person prevents automatic re-enablement. An automatically removed active member regains the member role when eligible in automatic mode; manual mode does not restore active-member access automatically. Preboarders follow their separate lifecycle and can regain only their preboarder role if they return to Slack.
Review access changes
Send the proposed configuration toPOST /v1/account/provisioning/preview. The response includes exact workspace totals in enable_count, disable_count, and unchanged_count. The to_enable and to_disable lists are paginated independently:
Use
next_enable_offset and next_disable_offset to fetch subsequent pages with the same configuration and search. A null offset means that list has no more results. enable_match_count and disable_match_count count search matches; searching does not change the workspace totals. Each request evaluates the current workspace, so a sync between requests can change the results.
Track access updates
Saving rules queues updates to existing members. The response’sapplication contains the latest run’s id, status, total_count, completed_count, and failed_count. These counts describe processed member records, including people whose access stays unchanged. application is null when there is no recorded run.
Poll GET /v1/account/provisioning while the status is pending or applying. completed means processing finished successfully. failed means processing did not finish successfully; some members may already have been updated.
updated_at records the latest progress update. When retry_allowed is true, send the saved configuration again with PATCH to start a new run. Failed runs can be retried immediately. Pending or applying runs can be retried after five minutes without progress. Submitting the same configuration during a healthy run keeps that run in place.
Pagination
Most list endpoints use cursor-based pagination with the parameters below. The access-change preview uses the offsets described above:Example
OpenAPI Specification
Download the full OpenAPI specification for use with API clients, code generators, or other tooling:Download OpenAPI Spec
OpenAPI 3.0 specification (JSON)
Next Steps
Authentication
Learn how to generate and manage API keys
Error Handling
Understand API error responses