API Request Logs
Reference notes for API Request Logs, including request shape, response expectations, permissions, and operational context.
API Request Logs explains how this part of PanelConfig should be used in a production hosting operation. It focuses on practical decisions, audit visibility, and safe execution rather than marketing language. API usage should use scoped tokens, short useful expiry windows, request logging, and replay-safe automation design.
Usage
Use this guide when you are configuring, reviewing, or troubleshooting api request logs for a hosting provider, agency, reseller, or customer account. It is useful during initial setup, operational handover, incident review, and routine maintenance.
Workflow
- Open the related PanelConfig page: PCAdmin > API Tokens, API Request Logs, Integrations-related module settings.
- Confirm the account, domain, user, or server context before changing anything. In provider environments, many records have similar names.
- Review current status, ownership, package limits, and any pending jobs before making a change.
- Make the smallest safe change first. For destructive or customer-visible operations, keep a ticket or internal note with the reason.
- Re-check the page, job queue, audit log, and any affected service status after the operation completes.
Checklist
| Check | Why it matters |
|---|---|
| Ownership | Prevents changes on the wrong customer, reseller, or hosting account. |
| Current status | Avoids repeating an action that is already pending, suspended, queued, failed, or completed. |
| Limits and dependencies | Shows whether package limits, DNS state, storage, service health, or credentials affect the result. |
| Audit trail | Gives support and operations teams a reliable record of who changed what and why. |
Related
PCAdmin: PCAdmin > API Tokens, API Request Logs, Integrations-related module settings
PCUser: Customer-facing integrations should use scoped tokens and least-privilege access.
Related PCCLI: php cli/pc api:tokens
Records
Typical records involved: api_tokens, api_token_scopes, api_requests, api_request_logs, jobs, command_runs, audit_logs, settings. Some actions only read these records, while write actions may update status fields, create queue records, write audit entries, or refresh timestamps. For integration-ready areas, do not assume an external provider action has completed until the local job and provider-side evidence agree.
Notes
Security and audit notes: use least-privilege access, avoid sharing raw credentials, keep customer-impacting changes tied to a reason, and review Audit Logs or Login History when an action affects authentication, access, DNS, mail flow, backups, SSL, firewall, WAF, or account status.
Troubleshooting
- If the page is empty, confirm the related database table exists and that the user role has permission to view the module.
- If a change appears stuck, check Jobs, Job Logs, and Services before repeating the operation.
- If an external dependency is involved, verify it independently: DNS propagation, ACME challenge visibility, remote backup storage, mail DNS records, or provider API state.
- If the result is sensitive or customer-visible, capture the exact timestamp, account id, domain, and operator before escalating.
Example
php cli/pc api:tokensAccuracy
PanelConfig includes API-token, request-log, and module endpoint foundations. Treat external DNS, backup, billing, and security-provider integrations as integration-ready or conceptual unless the installed release includes a specific provider connector and the provider-side action can be verified.