Juniper Mist Integration

Connect Juniper Mist to Atlas AVD and keep each customer's Mist access points, EX switches and SRX gateways documented in Atlas Vault.

Before you begin

  • A Atlas AVD plan. The Integrations hub is not available on Community
  • The Administrator role in Atlas to connect, configure or disconnect a connector. Integrations appears under Administration only for administrators
  • A tenant selected in the tenant picker. Credentials are stored encrypted per tenant, so each tenant you manage connects its own account
  • A Juniper Mist API token with read-only (Observer) access: an organization token, or a read-only user's token to cover several organizations
  • To sync into Vault: a Vault admin and at least one asset template (the Network Device template is a good fit)

What you can do

  • Document every Mist access point, EX or QFX switch and SRX or Session Smart Router gateway as an Atlas Vault asset, with no manual data entry.
  • Map each Mist site to the customer company it belongs to.
  • Keep the documentation current: every hour Atlas adds new devices, updates changed details and archives devices Mist no longer reports.
  • See what changed and when: firmware, management IP, MAC address, name, site and uplink changes, each with the previous value kept.
  • Ask Atlas Advisor about documented equipment, for example "list our Mist access points".

Step 1: Create a read-only API token

  • One organization: in the Mist portal, go to Organization → Settings → API Token and click Create Token. Give it the Observer role so it can only read, and copy the token when Mist shows it; it is shown only once.
  • Several organizations (recommended for MSPs): create a Mist user with read-only access to the organizations you manage, sign in as that user, and create a token under My Account → API Token. Atlas then sees every organization and site that user can see.
  • Note which Mist cloud you sign in to. The address in your browser tells you: manage.mist.com is Global 01, manage.eu.mist.com is EMEA 01, and so on. A token only works on its own cloud.

Step 2: Connect in Atlas

Once connected, the card shows Manage, which opens Atlas Vault → Assets, and Disconnect. The token is stored encrypted and is never shown again.

  1. Select the tenant in the tenant picker.
  2. Go to Administration → Integrations and click Connect on the Juniper Mist card.
  3. Choose your Mist cloud, for example Global 01 — manage.mist.com.
  4. Paste the API token.
  5. Click Connect. Atlas checks the token against your Mist cloud before saving anything; if it is rejected, nothing is stored.

Step 3: Map each site to a company

Add one sync per site. Each site can be mapped only once in a tenant, so its equipment never ends up under two companies. When your customers live in separate Atlas tenants, connect Juniper Mist in each tenant.

  1. Open Atlas Vault → Assets → RMM & PSA sync and click Add sync.
  2. Source: Juniper Mist.
  3. Device type: pick a site. Sites are listed as Organization — Site.
  4. Template: pick Network Device. Atlas fills in the field mappings for you: Name, Type, Manufacturer, Model, Serial Number, Management IP, MAC Address, Firmware Version and Location (the Mist site). You can change or add any mapping.
  5. Company: the customer this site belongs to.
  6. Leave Sync automatically every hour on, click Save Changes, then click Run now to document it straight away.

What gets documented

  • Identity: name, hostname, manufacturer (Juniper Networks), model, serial number, hardware revision and MAC address.
  • Type: Access Point, Switch or Gateway, and the product line (Mist AP, EX Series, QFX Series, SRX Series or Session Smart Router).
  • Network: management IP, the public IP the device reaches Mist from, and for an access point the switch and port it is plugged into.
  • Software: firmware version.
  • Operational: connection status as Mist reports it.
  • Placement: the Mist site, its address, and the organization.

Each device is matched by its Juniper serial number, so renaming it, changing its IP or moving it to another site updates the same asset instead of creating a new one. Connected clients such as laptops and phones, WLANs and switch port settings are not documented.

Your own documentation is kept

Atlas only fills the fields you map. Notes, attachments, custom fields and anything else you add in Vault are yours and are never touched. If you edit a mapped field by hand, Atlas keeps your value; if Mist later reports something different, the field is flagged under Drift to review so you can choose which to keep. A device Mist stops reporting is archived, not deleted, and comes back automatically if it returns. Atlas archives a device only after a complete read, so an outage or a rejected token never empties your documentation.

Change history

Open an asset's ⋯ menu and choose History to see what changed: when the device was first documented, a new name, model, management IP, MAC address, firmware, site, uplink switch or uplink port (each with the previous and new value), when it was no longer reported, and when it came back. Routine connected and disconnected changes are not recorded. The same entries appear on the Operations Timeline.

Ask Atlas Advisor

Atlas Advisor answers questions from the documented assets, read-only and limited to what you can see in Vault, with or without an AI provider. For example: "list our Mist access points", "Which Juniper switches are disconnected?", "What firmware are our Mist devices running?" or "Is Juniper Mist connected?".

What the integration does not do

  • It is read-only. It never changes configuration, claims or assigns a device, or upgrades firmware.
  • It does not document connected clients, WLANs or switch port settings.
  • It syncs every hour or when you click Run now; the interval cannot be changed.
  • It connects one Mist token per Atlas tenant. Credentials cannot be edited in place: disconnect and connect again with the new token.

GCC High tenants

On a tenant or deployment in Azure Government (GCC High), calls to Juniper Mist are blocked by default, because they can carry VM, host-pool and tenant names to a service outside the Government boundary. Connect fails with an Azure Government (GCC High) egress boundary message and nothing is stored, and pages that read from Juniper Mist stay empty. The operator who runs your Atlas deployment can approve Juniper Mist as a destination that is allowed to receive that data; once approved, the connector works normally. Running in Azure Government does not by itself make a third-party integration GCC High or CMMC compliant.

Disconnecting

Click Disconnect on the card and confirm. Atlas deletes its stored copy of the API token and pauses every Atlas Vault sync from Mist. The documented assets and their history stay in Vault; turn the syncs back on after you reconnect. Nothing changes in Mist. Revoke the token there too if you no longer need it.

Troubleshooting

  • The connection test fails with 401: the token is wrong or revoked, or it belongs to a different Mist cloud. Check the address you sign in to and pick the matching cloud.
  • A site is missing from the Device type list: the token cannot see it. Give the token (or its user) access to that site's organization.
  • Mist is temporarily rate limiting requests: Mist allows 5,000 requests an hour per token. Scheduled syncs wait and retry on their own; try again in a few minutes.
  • A sync fails for one site: Mist could not return that site's devices, for example because the token lost access to it. The documentation is kept until the next successful sync.
  • A sync reports the integration is not configured: Juniper Mist was disconnected. Connect it again, then turn the sync back on.

Next steps