Skip to main content
When a call isn’t behaving, the SDK’s logs show you each step of the trust loop — resolving the platform, minting a token, retrying on expiry. Turning them on is the fastest way to see where something breaks.

​
Turn on logging

The SDK logs through Python’s standard logging. Set its level to DEBUG: 
import logging
logging.getLogger("mudraid").setLevel(logging.DEBUG)
That enables everything under the mudraid namespace. Wire it to a handler if you don’t already have logging configured: 
logging.basicConfig(level=logging.INFO)        # your app
logging.getLogger("mudraid").setLevel(logging.DEBUG)   # verbose just for the SDK

​
The loggers, and what each tells you

Each part of the SDK logs under its own name, so you can zoom in on one stage.
LoggerWhat it showsUseful when
mudraid.agentRequest lifecycle, 401 retriesA call behaves unexpectedly
mudraid.token_managerToken cache hits, mints, refreshesYou suspect a token/expiry issue
mudraid.platform_resolverBootstrap, host → platform resolutionPlatformNotRegistered errors
mudraid.httpOutbound requests to MudraIDMudraID connectivity problems
mudraid.env.env loadingCredentials “not found”
Narrow to a single stage when the rest is noise: 
logging.getLogger("mudraid.token_manager").setLevel(logging.DEBUG)

​
Reading the output

A healthy first call typically shows: env loaded → platform resolved → token minted → request sent → 200. If it stops early, the last line points at the stage that failed — for example, a platform_resolver line with no following token_manager mint usually means the host isn’t a registered platform.

​
Logs never contain secrets

No SDK log line emits a secret or a token, at any level. This is enforced by tests that scan the entire DEBUG output for credential strings on every build — so you can leave DEBUG on and ship the logs to an aggregator without leaking credentials.