A credential is a set of login details for one kind of sensor: an SNMP community, a database login, an API token. You hold it once, high enough in the tree to cover everything that needs it, and every sensor beneath uses it. Credentials are sealed when saved and are never shown again, to you or anyone else.

Where to hold one

The Credentials panel appears on every object: the top of your estate, sites, groups, devices and sensors. A sensor looks for a credential of its own type on itself first, then on its device, then up through the groups and site to the top, and uses the first it finds.

• Hold it as high as it is true. One SNMP community for every switch in a site goes on the site. A device with a different one gets its own on the device, which overrides the site's for that device alone.
• The whole credential comes from one place. Fields are never mixed from different levels, so a credential on a device with only a username does not borrow the password from the site above.
• The name does not choose. If one object holds two credentials of the same type, the one saved first is used and the other is ignored. Keep one per type on each object.
• Check which one a sensor is using on the sensor's own Credentials panel: This sensor resolves SNMP / core from London, 2 levels up.

What each type holds

Ping, TCP, SMTP, IMAP4, DNS, SIP, RDP and email sensors take no credential.

SNMP v3 is not supported yet. The form accepts a v3 credential, but a sensor that resolves one is never sent to the probes and so never reports. Use v2c, or v1 for older kit.

Tokens: putting a credential into a request

An HTTP(S) request carries nothing from its credential unless you say where it goes. Write a token in the path, a header or the request body, and it is replaced when the probe collects its configuration:

• Tokens also work in the target override, and in other types' own fields: a SQL query, an SNMP OID, a DNS name, an FTP path, a TCP conversation. There, {{basicuser}} and {{basicpassword}} are that sensor type's own login.
• A token is not escaped or encoded for you. A value with characters that mean something in a URL needs to be safe to put there.
• A token that is not recognised is sent exactly as written, so a misspelt {{baerer}} reaches the server as it stands. If a request is refused, check the spelling first.

Substitution variables and the clock

A Substitution credential is a variable of your own. Save one named tenantid with the value 4471 on a site, and {{tenantid}} becomes 4471 in any sensor below it. Unlike other credentials, every variable up the tree is available at once; where two levels hold the same name, the nearer one wins. Names are lower case letters, digits and underscores, up to 40 characters, and cannot reuse a built-in token.

The built-in clock tokens, in UK time: {{isodate}} (2026-09-19), {{isodatetime}}, {{utcdatetime}}, {{ukdate}} (19/09/2026), {{yesterday}}, {{time}}, {{day}}, {{month}}, {{year}}, {{dow}} (Sat), {{hour}}, {{minute}} and {{unixtime}}. They are filled in when the probe collects its configuration, not at every poll, so treat them as today's date rather than the exact time of a reading.

Saving and changing

• Nothing can be read back. To change a credential, save it again with the same type and name, and it replaces the old one.
• A blank secret field keeps the old secret, so you can change a username without typing the password again.
• A blank ordinary field is cleared. Fill in the username, port and the like every time you save.
• Names keep letters, digits, dot, dash and underscore only; anything else is dropped. A blank name is saved as default.
• Values are plain text. Characters outside plain ASCII, such as £ or accented letters, are removed, and spaces at either end are lost. A password containing them will not work: change the password on the device.
• Changes reach the probes when they next collect their configuration, not instantly.
• Deleting a credential moves everything that used it on to whatever sits above, or to nothing.

When it goes wrong