If you already run an endpoint management service, evaluate Otukan on two points: which devices it takes over, and how your existing tools see and act on them. Otukan manages Android and Apple phones and tablets, and it runs beside your current service rather than inside it. Every device belongs to exactly one service, split by purpose, ownership, platform or site. Your service desk, reporting and automation reach Otukan’s part of the fleet through a documented, authenticated API, with each integration scoped and logged. Laptops, desktops and any groups you keep stay where they are.
Fleet scope
Coexistence works when every device has one clear home. Otukan helps you pick the line that keeps each side coherent.
| Split by | Typical Otukan side | Typical side kept with your current service |
|---|---|---|
| Purpose | Dedicated scanners, kiosks and field devices | General staff phones already running well |
| Ownership | Devices you supply to your own customers | Devices your organisation issues internally |
| Data control | Groups whose management data must stay where you choose | Groups without that requirement |
| Site or programme | A new site, contract or rollout | Established sites |
Each side still follows its platform’s rules. Android devices are managed through Android Enterprise and Apple devices through Apple’s device management framework, and a device joins Otukan by enrolment, with the provisioning channel its platform allows. Moving a group across later is a planned re-enrolment, set out on MDM migration.
What stays outside
Otukan does not take over endpoints it does not manage. Computers, printers and devices outside the agreed groups remain with your existing service, and the written split lists them so nothing falls between the two.
Operating model
A mixed estate needs one answer to a simple question for every record: which system is right when two disagree?
| Record | Authoritative system | Others |
|---|---|---|
| Users and groups | Your directory | Read only |
| Asset ownership | Your asset register or service desk | Read only |
| Policy and apps for Otukan groups | Otukan | Read through the API |
| Policy and apps for other groups | Your current service | Not touched by Otukan |
| Incidents and requests | Your service desk | Otukan posts events into it |
API rights and credentials
Each integration gets its own credential, never a shared administrator account. Rights are granted per area, such as inventory or action requests, and per device group, so a reporting job cannot wipe a device and a regional automation cannot see another region. A lock or wipe requested through the API passes through the same approvals as one started in the console, and every request lands in the audit log with the integration’s name on it. Where your data must live is covered on MDM data sovereignty.
Owned and partner functions
Otukan builds and operates the API and the event feed. The connectors on your side, such as a service desk workflow or a reporting job, are built by your team or an integration partner you choose, using Otukan’s documentation and pilot tenant.
Lifecycle
An integration has a lifecycle of its own, and Otukan plans it like a device’s.
| Stage | What happens |
|---|---|
| Provisioning | A credential is issued with named scopes; reads, requests and events are tested on the pilot tenant |
| Change | API changes are announced in advance with release notes, and scopes are adjusted when a group moves |
| Recovery | Credentials can be rotated or revoked at any time; events missed during your outage can be read again from the history |
| Offboarding | Credentials are revoked, the event feed stops and the audit log keeps the integration’s history |
Acceptance checks for an integration
Before an integration touches production, your team and Otukan confirm four behaviours on the pilot tenant. A read returns only the device groups in scope. A request outside the credential’s rights is refused and logged. A wipe requested by the integration waits for the same approver a console wipe would need. And an event from a real device change arrives in your service desk with enough context to act on without opening another console. When all four hold, the integration moves to production with its scopes unchanged.
Hosting and operating choices are covered on MDM deployment options. The rest of this collection is on deployment and integrations.