Api Request Tracking Documentation 2026 01 14

API Request Tracking Documentation Update

Date: January 14, 2026

Type: Documentation Update

Status: Completed

---

User Question

"Are there any methods for Tracking API requests? How can I see it and what are the limitations?"

---

Summary

Added comprehensive documentation about API request tracking functionality to the REST API documentation. This feature already existed in the codebase but was not documented, leading to user confusion about whether the capability was available.

---

Research Findings

Feature Existence

API request tracking does exist in Tadabase. The investigation revealed:

• Database Model: ApiLog model (appifany2\app\Models\ApiLog.php)
• Database Table: api_logs table with app-specific variants (app_{appId}_api_logs)
• Tracking Method: ApiLog::trackLog() automatically logs all API requests
• UI Access: Available in Builder under Settings > Logs > API Logs

Tracked Information

Each API request logs the following data:

• HTTP method (GET, POST, PUT, DELETE)
• Full URL including query parameters
• IP address of client
• Request headers (serialized)
• Request body/parameters (JSON)
• Response content
• Request duration in seconds
• Timestamp
• User agent details (platform, browser, device type, device name)

Permissions Required

API request logging requires two levels of permission:

1. App-Level: The allow_api_logs flag must be enabled on the client_apps table
2. API Key Level: The API key must have allow_log permission set to "Yes" in its metadata
3. Plan-Level: The subscription plan must allow allow_log_in_api

Viewing Logs

• Builder UI: Settings > Logs > Select "api-logs" type
• Filtering: Logs can be filtered by date range (from/to dates)
• Implementation: Handled by TLogController::load() with case 'api-logs'

Limitations Identified

• No public API endpoint for retrieving API logs (logs are viewed only in Builder)
• Plan restrictions may apply
• No automatic log rotation or cleanup
• Logs stored indefinitely in app database (storage considerations)
• Performance overhead for high-volume APIs
• Sensitive data is captured in request/response (security consideration)

---

Changes Made

Documentation Updates

File Updated: docs/exported-articles/Developers/(No Section)/1779-updated-rest-api.html

New Section Added: "4. API Request Tracking"

Added a comprehensive new section covering:

1. Overview: Explanation of what API request tracking is and its purpose
2. Enabling Tracking:
   • App-level configuration
   • API key permission setup
   • Step-by-step instructions
3. Information Tracked: Complete table of all tracked fields and their descriptions
4. Viewing API Request Logs:
   • How to access logs in the Builder
   • Filtering options (date ranges)
5. Limitations and Considerations:
   • Plan restrictions
   • Performance impact
   • Data retention policies
   • Sensitive data warnings
6. Common Use Cases:
   • Debugging API integrations
   • Monitoring and analytics
   • Audit trail maintenance
7. Best Practices: Six recommendations for effective use of API logging

Table of Contents Update

Updated the document's table of contents to include the new section and renumbered all subsequent sections (4-18).

Section Renumbering

All sections after "Rate Limiting" were renumbered:

• Former section 4 "Data Operations" is now section 5
• Former section 5 "User Authentication" is now section 6
• And so on through section 18 "Best Practices"
• Updated all divider-X IDs to maintain consistency

---

Code Changes

No code changes were required. The API request tracking functionality was fully implemented and functional. Only documentation was needed.

---

Why These Changes Were Made

Problem Statement

A user asked about tracking API requests, indicating:

• The feature's existence was not clear to users
• How to enable/access it was undocumented
• Limitations were unknown

Solution Rationale

1. Discoverability: Added a dedicated section in the REST API documentation so users can easily find information about this feature
2. Completeness: Documented all aspects including setup, usage, and limitations to prevent future questions
3. Security Awareness: Included prominent warnings about sensitive data logging to help users make informed decisions
4. Best Practices: Provided guidance on effective use to help users maximize value while minimizing storage/performance concerns
5. Placement: Positioned after "Rate Limiting" and before "Data Operations" as it's a foundational API feature that users should understand early

Benefits

• Users can now find clear information about API request tracking
• Reduces support burden by answering common questions proactively
• Empowers users to debug their integrations more effectively
• Raises awareness of security and storage considerations
• Improves overall user experience with the API

---

Future Considerations

Potential Enhancements

Based on this research, future improvements could include:

• Adding a public API endpoint to retrieve API logs programmatically
• Implementing automatic log rotation/cleanup options
• Adding UI tooltips in the API Key settings to explain the "Allow Logs" permission
• Creating a dashboard widget showing API request statistics
• Adding ability to export/archive logs
• Implementing log filtering by endpoint, method, or status code

Documentation Maintenance

This documentation should be updated if:

• New filtering options are added to the log viewer
• A public API endpoint for log retrieval is implemented
• Plan restrictions change
• Automatic log retention policies are implemented

---

Related Documentation

Articles that were reviewed but not updated:

• REST API (Legacy) - Older API documentation, not updated as users should reference the newer comprehensive guide

---

Verification

To verify this feature works as documented:

1. Enable allow_api_logs on an app
2. Create/edit an API key with allow_log permission
3. Make API requests using that key
4. Navigate to Settings > Logs > API Logs in Builder
5. Confirm requests appear with all documented fields
6. Test date range filtering

---

Conclusion

This documentation update addresses the user's question comprehensively by documenting an existing but undocumented feature. No code changes were necessary, demonstrating that the gap was purely in documentation. The update ensures that future users asking similar questions will find clear, complete answers in the official REST API documentation.