A Python script receives HTTP 401 from an IOS XE device even though an engineer can log in through SSH. The two access paths may use different service settings or authorization rules. Start with the HTTP exchange rather than replacing every credential or granting broader privileges.
Lab status: This is a proposed exercise, not a completed device test or client case study. Code examples require validation against your image and dependency versions. My documented background is NOC/data center operations, multi-vendor Netmiko workflows and Python/Flask integration.
Offline example checks: October 20, 2026: the added helper/demo block executed with local fixtures, and related negative cases were checked offline. No live device, controller, fabric or service behavior was validated.
What does RESTCONF 401 Unauthorized establish?
It indicates an authentication-related HTTP failure, but the response body and platform configuration are needed to understand why. Confirm that you reached the intended device rather than a proxy or another web service. A 403 typically points toward an access restriction; implementations and error details still need inspection.
Inspect the status, content type and endpoint before parsing YANG data. HTML may identify a login page or reverse proxy rather than a RESTCONF error. Do not follow a redirect automatically with API credentials. A TCP or TLS error occurs before an HTTP 401 can be received and needs a separate report category.
Why does successful SSH login not prove HTTP authorization?
Use a matrix with wrong password, account permitted for SSH only, and account authorized for the specific API read. HTTP authentication, AAA authorization and resource access can differ by IOS XE release. Check show version and the approved running configuration for AAA/HTTPS/RESTCONF settings with the owner; do not copy a universal AAA replacement from this article.
Proposed IOS XE lab: establish a RESTCONF access baseline
On a supported image, agree one read-only hostname resource and a certificate-valid HTTPS hostname. Compare one valid read and one deliberately invalid credential attempt. Record exact status and sanitized error fields. An unsupported classic IOS image is not converted into a RESTCONF platform by running it in EVE-NG.
Python requests: inspect an authenticated RESTCONF GET
The response inspector below uses a caller-created authenticated requests.Session. Set session.auth from a prompt or secret manager and session.verify to your CA bundle; do not print either. Its result is a transport/schema triage outcome, not confirmation that the requested data is correct. The existing standalone request remains the connection example.
import os
from getpass import getpass
import requests
url = ('https://' + os.environ['LAB_HOST'] +
'/restconf/data/Cisco-IOS-XE-native:native/hostname')
r = requests.get(
url, auth=(os.environ['LAB_USER'], getpass('API password: ')),
headers={'Accept': 'application/yang-data+json'},
verify=os.environ['LAB_CA_BUNDLE'], timeout=(5, 20),
allow_redirects=False,
)
print('Status:', r.status_code)
print('Content type:', r.headers.get('Content-Type'))
if r.status_code == 401:
raise RuntimeError('Inspect authentication and endpoint details')
r.raise_for_status()
if r.status_code != 200:
raise RuntimeError('Unexpected response for this GET')
print('JSON response type:', type(r.json()).__name__)
Worked Python example and input contract
def inspect_restconf(session, origin, path):
# origin must come from approved inventory; Session.verify holds the CA policy.
if not origin.startswith('https://') or not path.startswith('/restconf/'):
raise ValueError('approved_https_restconf_target_required')
response = session.get(origin.rstrip('/') + path,
headers={'Accept': 'application/yang-data+json'},
timeout=(5, 20), allow_redirects=False)
status = response.status_code
if 300 <= status < 400:
return {'status': 'redirect_rejected', 'http_status': status}
media = response.headers.get('Content-Type', '').split(';')[0].strip().lower()
data = None
if media in ('application/yang-data+json', 'application/json'):
try:
data = response.json()
except ValueError:
return {'status': 'invalid_json', 'http_status': status}
if status == 401:
category = 'authentication_required_or_rejected'
elif status == 403:
category = 'access_denied'
elif status == 404:
category = 'restconf_resource_missing' if data is not None else 'endpoint_or_service_mismatch'
elif status >= 400:
category = 'http_error'
elif data is None or not isinstance(data, dict):
category = 'unexpected_response'
else:
category = 'json_received_schema_unverified'
return {'status': category, 'http_status': status, 'json_object': isinstance(data, dict)}
# Call only with an approved authenticated Session and trusted CA policy:
# result = inspect_restconf(session, origin, '/restconf/data/Cisco-IOS-XE-native:native/hostname')
# The function does not create credentials or initiate a request until called.
When should you use CLI collection instead of RESTCONF?
If CLI access already satisfies a small read-only requirement, it can remain the collector while the API access policy is reviewed. That is a design tradeoff, not a workaround for unauthorized access. Document which source and privilege policy each dashboard field uses.
What should RESTCONF access verification and handover include?
A successful acceptance run must return the expected hostname from the intended device, not merely HTTP 200. Retest with the restricted service account and production-like CA policy in the lab. Retain the permission decision and unresolved versions in the handover.
Related troubleshooting and implementation
Explore the network automation troubleshooting collection to connect this issue to adjacent workflows. The Netmiko, NETCONF and RESTCONF comparison helps when you are choosing an interface rather than fixing an existing implementation.