Identify the integration operations, source address, lifetime and required access level. Read the current API or vendor integration requirements. Keep the owner credential private and decide where the generated secret will be stored.

1. Open Login Keys for the intended DirectAdmin account and create a uniquely named key.
2. Set an expiry and usage policy suited to the task. For long-running automation, document its rotation and monitoring rather than leaving an unexplained permanent credential.
3. Allow only the required commands and restrict source IPs where practical. Review command groups carefully, because a broad group may include more operations than expected.
4. Avoid permission to create or manage other login keys unless the integration truly requires it. Enable browser HTML access only when the approved task needs the panel interface.
5. Save the key in approved secret storage, configure the integration and test one required operation plus a denied operation. Never put the secret in a public URL, repository or screenshot.

Confirm the intended account and scope are used, the source-IP restriction works and the integration does not need the owner password. Record key purpose, owner, expiry and last review.

If access fails, compare the exact command, current source IP and key lifetime before broadening permissions. A client behind a changing egress address may need a stable controlled endpoint. Revoke a lost key promptly and inspect its recent use. Panel two-factor authentication and login keys have different authentication paths, so review keys even when MFA is enabled.

• Setting up DirectAdmin two-step authentication
• Planning a DirectAdmin multi-server DNS setup
• Investigating a DirectAdmin brute-force block
• Diagnosing Dovecot login errors on DirectAdmin

• DirectAdmin: Securing Da Panel
• DirectAdmin: What Makes Da Unique