Version History API
This guide explains the Version History API which provides version tracking for various Waldur objects using django-reversion.
Overview
The Version History API enables auditing and debugging by maintaining a complete change history for key Waldur entities. Every modification to tracked fields creates a timestamped snapshot that can be queried via the API.
Use cases:
- Audit trail for compliance requirements
- Debugging configuration issues
- Tracking changes over time
- Investigating state transitions
- Point-in-time recovery analysis
Supported Models
The following models have version history endpoints:
| Model | Endpoint | Description |
|---|---|---|
| Customer | /api/customers/{uuid}/history/ |
Organization accounts |
| User | /api/users/{uuid}/history/ |
User accounts |
| SSH Key | /api/keys/{uuid}/history/ |
SSH public keys |
| Offering | /api/marketplace-provider-offerings/{uuid}/history/ |
Service offerings |
| Plan | /api/marketplace-provider-plans/{uuid}/history/ |
Pricing plans |
| Resource | /api/marketplace-resources/{uuid}/history/ |
Marketplace resources |
| Invoice | /api/invoices/{uuid}/history/ |
Billing invoices |
Architecture
graph TD
A[Object Change] --> B[django-reversion]
B --> C[Version Record]
C --> D[PostgreSQL]
E[History API] --> D
E --> F[Paginated Response]
The system uses django-reversion to capture object snapshots on save operations. Each version stores:
- Serialized field data
- Timestamp of the change
- User who made the change (if authenticated)
- Revision comment describing the change
API Endpoints
All models with version history support two endpoints:
List Version History
Returns paginated version history for an object, ordered by most recent first.
1 | |
Query Parameters:
| Parameter | Type | Description |
|---|---|---|
created_before |
ISO 8601 timestamp | Filter versions created before this time |
created_after |
ISO 8601 timestamp | Filter versions created after this time |
Example Request:
1 2 | |
Example Response:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | |
Get Object State at Timestamp
Returns the object state as it existed at a specific point in time.
1 | |
Query Parameters:
| Parameter | Type | Required | Description |
|---|---|---|---|
timestamp |
ISO 8601 timestamp | Yes | Point in time to query |
Example Request:
1 2 | |
Example Response (200 OK):
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | |
Error Responses:
| Status | Condition |
|---|---|
| 400 | Missing or invalid timestamp parameter |
| 404 | No version exists before the specified timestamp |
Response Format
The VersionHistorySerializer returns these fields:
| Field | Type | Description |
|---|---|---|
id |
integer | Version record ID |
revision_date |
datetime | When the change was recorded |
revision_user |
object/null | User who made the change |
revision_comment |
string | Description of the change |
serialized_data |
object | Snapshot of object fields |
The revision_user object contains:
| Field | Type | Description |
|---|---|---|
uuid |
UUID | User identifier |
username |
string | Login username |
full_name |
string | Display name |
Permissions
Access to history endpoints is restricted to:
- Staff users - Global administrators
- Support users - Global support personnel
Regular users (owners, admins, managers, members) cannot access version history.
Filtering Examples
Get changes in a date range
1 2 3 | |
Get state before an incident
1 2 3 | |
Compare customer state over time
1 2 3 4 5 6 7 8 | |
Model-Specific Details
Resources
Resources have additional tracked fields specific to marketplace operations. See Resource History API for details on:
- Tracked resource fields (limits, attributes, cost, etc.)
- Actions that create history entries
- Django admin integration
Customers
Tracked fields include:
name,native_name,abbreviationcontact_details,emailregistration_code,agreement_numbercountry,vat_code
Users
Tracked fields include:
username,emailfirst_name,last_name,native_nameorganization,job_titleis_active,is_staff,is_support
Offerings
Tracked fields include:
name,descriptionterms_of_service,terms_of_service_linkprivacy_policy_linkstate,paused_reason
Plans
Tracked fields include:
name,descriptionunit_price,unitmax_amount,archived
Invoices
Tracked fields include:
state,year,monthtax_percentcustomerreference
Implementation Notes
The version history functionality is implemented via HistoryViewSetMixin in
waldur_core.core.views. This mixin can be added to any ViewSet whose model
is registered with django-reversion.
To add history endpoints to a new ViewSet:
- Register the model with django-reversion:
1 2 | |
- Add the mixin to the ViewSet:
1 2 3 4 | |
- Optionally customize the serializer:
1 2 | |
Related Documentation
- Resource History API - Resource-specific history details
- Waldur Permissions - Permission system details