Addigy
Overview
Addigy is an Apple-only (macOS, iOS, iPadOS, tvOS) MDM and RMM platform built for MSPs. It combines device management, policy-based configuration, patch management, monitoring and alerting, and compliance benchmarking, with a parent/child organization model for managing client tenants.
The Bumblebee integration wraps the reporting subset of the Addigy API v2 — the endpoints that answer "what's in the fleet, what's on it, what's outstanding, and what alerted." It is read-only: Bumblebee queries Addigy and never changes device state, policies, or configuration.
Prerequisites & Setup
You need:
- An Addigy account with access to Account → Integrations
- An API key generated from that page
Generate an API Key
- Sign in to app.addigy.com
- Go to Account → Integrations
- Create a new API key and give it a recognisable name (e.g. Bumblebee)
- Copy the key
If you manage client tenants as child organizations, generate the key in the parent organization. Bumblebee can then list the child organizations and scope reports to each one.
Permissions
Addigy enforces permissions per endpoint, so a key that authenticates successfully can still be refused on individual reports. The reporting tools here need at minimum View Devices.
The get_api_key_info tool returns the organization the key belongs to along
with the permissions it actually holds — the fastest way to explain a report
that comes back empty.
Configure in Bumblebee
- Go to the Integrations page in Bumblebee
- Select Addigy
- Paste your API Key
- Save the configuration
- Run a test request from the validation card
How Addigy reporting works
Two things about Addigy shape how you ask for reports.
Device attributes are "facts"
Addigy models every queryable device attribute — OS version, model, serial number, free disk space, FileVault state — as a fact. Which facts exist is specific to your organization, because it includes any custom facts you have defined.
Bumblebee handles this in two steps: it lists the available facts for your organization, then asks for the specific ones your question needs. You don't need to know fact names to ask a question — ask for "the macOS version on every device" and the agent resolves the right fact itself.
Client tenants are child organizations (and policies)
Addigy has two grouping concepts that both matter for MSP reporting:
- Child organizations — separate tenants under your parent organization, each with its own device count. Bumblebee lists these and can scope a report to one.
- Policies — how devices are grouped within an organization. MSPs commonly map one policy per client site or device class.
Addigy documents an option to query a parent organization and all of its descendants in a single call, but does not declare it in its endpoint specification, so Bumblebee cannot yet rely on it. Cross-tenant reports are therefore assembled per child organization. If a result looks like it covers only the parent organization, ask Bumblebee to break the report down by client instead.
API Limits
Addigy does not publish rate limits, and its specification documents no 429
or throttling behaviour. Bumblebee still backs off and retries if a rate-limit
response appears.
Most list endpoints paginate with page / per_page and cap page size at 100,
so large fleet reports are assembled across several pages.
Available Tools
All tools are read-only.
Discovery
| Tool | Description |
|---|---|
get_api_key_info | The calling key's organization and its permission list. Use to validate credentials and diagnose a permission error |
list_child_organizations | The managed client tenants under an organization — id, company name, device count, enabled state, trial end |
Device inventory
| Tool | Description |
|---|---|
list_facts | The device attributes available in an organization, built-in and custom. Used to resolve which facts a question needs |
search_devices | Search devices and return chosen facts for each — inventory, OS version, model, serial, policy membership, last seen. Filterable by policy, free text, or a single fact comparison |
list_policies | Policies — Addigy's per-client/site device grouping, with deployment metadata |
Reporting depth
| Tool | Description |
|---|---|
query_installed_applications | Installed application inventory for specific devices, as seen by the Addigy agent. macOS only |
query_available_system_updates | OS updates available but not yet installed — the outstanding patch report |
query_installed_system_updates | OS updates already applied within a date window — patch completion evidence for a QBR |
query_device_compliance_status | Per-device compliant / not-compliant status |
query_received_alerts | Monitoring alerts, filterable by device, status, category, remediation state, and date range |
The device-scoped tools (installed applications, both system-update tools, and compliance) report on specific devices rather than a whole fleet at once, so Bumblebee finds the relevant devices first and then queries them.
Use-case filtering — devices behind on patches, apps due for removal, alerts in a billing period — is done by the agent over these responses; the tools are named after the API surface, not the use case.
Not covered
| Surface | Why |
|---|---|
| MDM commands, profile deployment, device actions | Mutating — out of scope for read-only reporting |
| Addigy's scheduled report engine and bulk data exports | Job-based or very large payloads; a poor fit for conversational reporting. Candidates for a later batch |
| SentinelOne, Malwarebytes, and Microsoft Conditional Access data inside Addigy | Vendor-in-vendor passthroughs — integrate those vendors directly instead |