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, documentation, and dataset-release use case to connect the client to a specific workflow.