# Using the Truthlocks Python SDK: configuration and error handling

> A practical integration guide to the Python client, keeping credentials on the server, checking API compatibility, and handling failed verification safely.

By Developer Relations
Published: 2026-02-05
Updated: 2026-10-03T05:03:34.843219Z
Canonical page: https://www.truthlocks.com/blog/python-sdk-312-support

The Truthlocks Python client provides resource methods around issuing identities, keys, attestations, verification, and receipts. Treat the installed package version and current documentation as the contract for your integration. A blog example should not override a method signature or endpoint requirement.

## Configure an approved environment

Keep the API credential in server-side configuration or your deployment’s secret store. Avoid embedding it in notebooks that will be shared, browser code, screenshots, or committed examples. Set the API base URL explicitly when switching environments so a test script cannot silently target the wrong service.

The client implementation includes configurable timeouts and retry settings. Choose limits that match the surrounding workflow and present a recoverable error when the service does not answer. Do not keep an interactive user waiting indefinitely for a background retry loop.

## Use the resource appropriate to the task

- Issuer and key resources provide context for the source responsible for a record.
- Attestation methods work with supported signed-record operations and payload formats.
- Verification methods return results your application must interpret, rather than a substitute for business review.
- Receipt methods connect recorded events to the identities and references your application supplies.

Confirm synchronous versus asynchronous support in the version you install. An async registration helper does not mean that every resource method is asynchronous. Check the runtime requirements and the actual client interface before introducing it into an event loop.

## Handle failures deliberately

Distinguish authentication failures, invalid input, missing records, rate limits, and service errors. A missing record is not an approval. A network timeout is not evidence that a write failed before reaching the server. Review the endpoint’s retry and idempotency behavior before repeating an issuing operation.

Log business references and safe error categories instead of credentials or complete sensitive payloads. Retain enough context for a reviewer to find the original request without turning logs into an uncontrolled copy of customer records.

## Test the recipient experience

Before expanding the integration, test a valid record, changed content, a revoked record, an unknown issuer, and an unavailable service. Then review how each result appears to an actual user. Explore the [developer overview](https://www.truthlocks.com/developers), [documentation](https://docs.truthlocks.com/), and [dataset-release use case](https://www.truthlocks.com/industries/research#dataset-releases) to connect the client to a specific workflow.