Purpose
Document the Mosyle API component layer without confusing it for the full district reconciliation workflow that uses it.
Current state
The registry now shows that the stronger production evidence is the wrapper workflow syncing Mosyle and Snipe-IT every 30 minutes. This page therefore describes the underlying API tool, not the whole operational process.
Next step
Keep this page focused on component behavior and document live production reconciliation, host ownership, and write-enabled scope on the separate workflow page.
Interfaces
Inputs- Mosyle API credentials
- CSV inputs for bulk updates
- device identifiers
Outputs- device export CSVs
- Mosyle attribute updates
Reality to Action trace
Reality IngestionNot in scope.
Canonical StorageNot in scope.
Automation EnginesNot in scope.
Human InterfacesContributes in this stage.
Operational AdoptionContributes in this stage.
Core workflow
TBD. Document the 5-10 steps that define the core workflow.
Data integrity and contracts
Source of truth rules
- Mosyle remains canonical for MDM-side device state.
- This CLI is an operational interface to Mosyle and should not be treated as the system of record itself.
Safe handling
- Restrict Mosyle credentials and exported CSVs.
- Limit bulk-update usage to approved operators.
- Document wrapper-level write scope before broadening production use.
Operational notes
Reliability posture
The API component is useful and active, but the production question now sits at the wrapper-workflow level: which hosts run it, with what write scope, and against which asset classes.
Observability
- CLI stdout/stderr
- API response details
- CSV artifacts created by wrapper workflows
Security and privacy
Mosyle credentials, assignment context, and CSV artifacts should remain internal and restricted to device operations staff.
Dependencies
Upstream- Mosyle API access
- device inventory identifiers
- wrapper workflow decisions
Downstream- Mosyle to/from Snipe-IT Asset and Tag Sync
Ownership
OwnersTechnology Services, Josh Barton
UsersTechnology Services, device operations maintainers
MDM Integration Automation (Mosyle)
Operational Notes
- This page intentionally stays at the component layer. The registry now makes clear that the stronger production evidence sits above it in the scheduled Mosyle to/from Snipe-IT Asset and Tag Sync workflow.
- The component still matters because it defines the Mosyle API boundary used by wrapper scripts and other automation. What Atlas should avoid is treating a reusable CLI as if it were the whole district workflow.
- When documenting live operations, capture host ownership, write-enabled scope, and asset-class boundaries on the workflow page rather than here.
Registry Alignment
- Related registry entry:
INT-071. - Registry clarified: the strongest production evidence points to wrapper scripts such as
snipeit_sync_mosyle.sh and snipeit_sync_mosyle_asset_tags.sh, not to this component alone. - Validation gaps: workflow-level host ownership, write-enabled scope, and asset classes in scope still need documentation.