Universal credential vs Legacy SOAP/XML or basic

Hello Issac.

This is case specific. If you're referring to the Meraki PowerPack, the basic credential is the original one used, but as more features were added to the PowerPack, we needed to use a credential that had more fields for users to input values (such as tags) for discovery, so the Solutions group elected to use the SOAP/XML credential as there was not a a configurable credential type where new fields could be added. 

Now the SL1 platform has the "universal credential" which allows a developer to add any number of arbitrary fields, so new PowerPack releases have the ability to use that. The latest version of the Meraki PowerPack released this year has the option for all three credentials, but we advise against using the basic credential since you will not be able to use all features in the PowerPack (like selective discovery), and we suggest users use the universal credential and guided discovery workflow if possible. 

Similar cases exist across the PowerPack portfolio. The SOAP/XML credential was historically the most flexible one with the most fields. The universal credential now replaces that need.

Thanks,

Taylor 

Hello Issac,

I would like to back to what I think is your original question, as the why we have universal and legacy credentials, and which one to use. We recommend using the universal credentials, the back ground to this is....

Background and Motivation for the Universal Credential Framework

Historically, newer content types have introduced connection requirements that extend beyond the fields defined in legacy credential formats—such as SOAP XML, SSH, and PowerShell. To accommodate these evolving needs, we initially repurposed existing fields within the SOAP XML credential type to store additional parameters. For example, an AWS secret key might be stored in the password field—an approach that, while functional, lacked semantic alignment and introduced ambiguity.

This workaround created a disconnect between the data being stored and the credential container itself. It also required users to rely on documentation or tribal knowledge to understand which fields were being overloaded for which content types.

To address this, we developed the Universal Credential Framework. This framework enables the creation of content-specific credential types—such as an AWS Universal Credential—where fields are explicitly named and aligned with their intended use. Instead of placing an AWS secret key in a generic password field, users can now store it in a clearly defined aws_secret_key field. This improves clarity, reduces misconfiguration risk, and eliminates the need for field repurposing.