LogoفارسیFA

Complete Guide to DirectAdmin API and Workflow Customization: Custom Items, Feature Sets, Widgets, Skins, and Building Specialized Packages

This article provides a comprehensive overview of the DirectAdmin API and the full range of customization tools available for modifying DirectAdmin’s workflow. It covers API usage, custom package and domain items, admin restricted restore behavior, per user widget control, skin customization, plugin access management, and combining these features to build specialized packages such as an “E Mail Only” plan. All examples, paths, and scripts are included for practical implementation.

DirectAdmin API, workflow customizationfeature sets, plugin controlemail-only package

~3 min read • Updated Mar 1, 2026

1. What Is the DirectAdmin API?


The DirectAdmin API allows your own scripts—local or remote—to communicate with DirectAdmin and perform various tasks. API calls behave like a web browser request, sending data in the same format, but CMD_API responses are structured and machine readable.


Important: Not all CMD_API commands are listed in api.html. You must search the version system for the full list.


---

2. Custom Domain and Package Items


Custom items allow you to add new options to User/Reseller packages or domains. These items can be any standard input type (text, checkbox, listbox, etc.).


Where values are stored:


  • user.conf and reseller.conf — for package items
  • domain.com.conf — for domain items

You can combine these with hook scripts such as user_create_post.sh, user_modify_post.sh, and domain_create_post.sh to automate actions based on selected custom values.


---

3. Limiting Custom Item Restore to Admin Level


In:


/usr/local/directadmin/data/admin/custom_domain_items.conf

You can append:


&admin_restore_only=yes

This ensures that during a restore:


  • If restore is done at Admin Level → the custom item is restored
  • If restore is done at User or Reseller Level → the item is ignored

---

4. Custom Per User or Per Reseller Widgets


DirectAdmin allows widget visibility control via user.conf and reseller.conf.


Available options:


  • widgets=ON — all widgets enabled (default)
  • widgets=OFF — all widgets disabled
  • widgets=ON:WGT_DB|WGT_PLUGINS_HELLO_WORLD — only these widgets enabled
  • widgets=OFF:WGT_DB — only this widget disabled

This is not yet exposed in the UI, but can be controlled through custom package items.


---

5. Skin Customization (Evolution and Enhanced)


5.1 Customizing Evolution via UI


Use:


Customize Evolution Skin

All changes are stored in:


/usr/local/directadmin/data/users/{username}/skin_customizations/evolution

5.2 Creating a custom skin.conf


To override default settings:


/usr/local/directadmin/data/users/CREATOR/skin_customizations/evolution/skin.conf

You only need to include the lines you want to override. Example:


user_widgets=WGT_DB|WGT_EMAIL

5.3 Creating a custom skin manually


cd /usr/local/directadmin/data/skins
cp -Rp enhanced yourskin

Skins support embedded scripting (PHP, Perl, etc.) and conditional logic.


---

6. Plugins


Plugins allow you to add new functionality to DirectAdmin. They run with the user’s permissions, making them safe by default.


Warning: Running plugins as root via chmod 4755 is dangerous unless you fully understand secure coding practices.


---

7. Plugin Permissions in Packages


7.1 File locations


User package:


/usr/local/directadmin/data/users/USERNAME/packages/PACKAGE_NAME

User configuration:


/usr/local/directadmin/data/users/USERNAME/user.conf

7.2 Allowing or denying plugins


Allow specific plugins:


plugins_allow=plug1:plug2

Deny specific plugins:


plugins_deny=plug3:plug4

7.3 Logic rules


  • If neither variable exists → all plugins allowed
  • If plugins_allow exists → only listed plugins allowed
  • If plugins_deny exists → listed plugins denied
  • If both exist → plugins_allow overrides everything

7.4 Clearing plugin lists


plugins_allow=[clear]
plugins_deny=[clear]

Note: plugins_allow= (empty) blocks all plugins.


---

8. Combining Features to Build an “E Mail Only” Package


This example shows how to combine custom package items, hook scripts, and command restrictions to create a specialized package.


8.1 Create a custom package item


File:


/usr/local/directadmin/data/admin/custom_package_items.conf

Content:


account_allow=type=listbox&item1txt=All Features&item1val=all&item2txt=E-Mail Only&item2val=email&string=Select Featureset&desc=Ability to select core features&default=all

8.2 Create user_create_post.sh hook


#!/bin/sh
CA=/usr/local/directadmin/data/users/$username/commands.allow
if [ "${account_allow}" = "email" ]; then
      cp -f /root/allows/email.list $CA
fi
if [ "${account_allow}" = "" ] || [ "${account_allow}" = "all" ]; then
       rm -f $CA
fi
exit 0;

Make executable:


chmod 755 /usr/local/directadmin/scripts/custom/user_create_post.sh

8.3 Create email.list


This file contains all email related commands:


CMD_EMAIL_POP
CMD_EMAIL_FORWARDER
CMD_EMAIL_LIST
CMD_EMAIL_AUTORESPONDER
CMD_EMAIL_VACATION
CMD_EMAIL_USAGE
CMD_WEBMAIL_LOGIN
CMD_PASSWD
CMD_LOGIN
CMD_LOGOUT
CMD_USER_STATS
CMD_USER_HISTORY
CMD_TICKET
CMD_TICKET_CREATE
CMD_WIDGET
...

8.4 Apply same logic to user_modify_post.sh


cd /usr/local/directadmin/scripts/custom
ln -s user_create_post.sh user_modify_post.sh

Now the “E Mail Only” package is fully functional.


Written & researched by Dr. Shahin Siami

Next Article