Extending Watch My Domains SED - REST API or Direct Access
Watch My Domains SED supports two distinct approaches for developers who want to build tools, integrations, or automation on top of the application. They serve different purposes and suit different use cases - choosing the right one depends on where your tool runs, who will use it, and how much access it needs.
REST API
The REST API gives programmatic access to WMD SED's full functionality through a single endpoint - api.php. All requests are session-based and operate within WMD's own user and permission model. The API is the standard integration path for most developer use cases.
Best suited for
- Browser-based tools and dashboards built with HTML, JavaScript, or any frontend framework
- External applications on a different server or domain integrating with WMD data
- Tools that should respect WMD's user roles, column-level permissions, and category access controls
- Integrations that do not require shell access to the server
- Any scenario where you want WMD's session and authentication model to handle access control automatically
How it works
All API calls go to api.php using standard HTTP requests. Responses are JSON. Authentication uses WMD's PHP session - browser-based tools inherit the active session automatically, while server-side scripts authenticate explicitly and manage a session ID. The full API covers domain data, lookups, categories, users, reports, DNS monitoring, and more.
Read the REST API Developer Guide →
Native Development with Direct Access
Native development means writing server-side PHP scripts that load WMD's own bootstrap and internal classes, then access the database directly. This approach bypasses the REST API entirely and operates at the same level as the application itself.
Best suited for
- Development teams that manage their own WMD SED installation and have full server access
- Cron jobs and scheduled tasks that need to run from the CLI without a browser session
- Bulk data enrichment - calling third-party APIs and writing results back to the domain table
- Internal operational tools where WMD's user permission model is not relevant
- Tasks that require access to WMD's internal utility classes for output, logging, email, or configuration
How it works
A single require statement loads WMD's bootstrap, which initialises the framework, sets up class autoloading, and connects to the database. From there, the full WMD class library is available - database access via Auth and the database helper, email via the Mailer class, logging via CPLogger, and output via UTIL::print(). Tools can run in both CLI and browser modes from the same file.
Security note: Native direct-access tools operate below WMD's permission model. They bypass user roles, column-level access controls, and category restrictions entirely. They should only be built and deployed by administrators with full server access, and only for internal use. If exposed in a browser without proper session and admin checks, they become unrestricted database endpoints. See the full security guidance in the developer guide before building.
Read the Native Development Guide →
Choosing the Right Approach
| REST API | Native Development | |
|---|---|---|
| Runs in | Browser or any server with HTTP access | Server only (CLI or browser on same server) |
| Authentication | WMD session - handled automatically | No auth layer - direct DB access |
| Respects WMD permissions | Yes - roles, columns, categories enforced | No - all data accessible regardless of role |
| Server access required | No | Yes |
| Language / stack | Any - PHP, Python, JS, Node, etc. | PHP only |
| Suitable for cron / CLI | Yes, via session ID pattern | Yes - primary use case |
| Access to WMD internals | No - API surface only | Yes - full class library available |
| Security risk if misconfigured | Low - session model provides protection | High - unrestricted DB access if exposed |
