API Reference - Backup History
Link: https://support.brilliantdirectories.com/support/solutions/articles/12000109011
← Back to API Reference | Getting Started
Backup History
Backup History is the platform's table-agnostic backup, snapshot, and edit-history store. Each record captures a versioned snapshot of content belonging to some other table, identified by the tuple type + type_table + type_column + type_value. The admin panel's Load Revision feature reads from this same store, so versions written through the API appear in the admin revision dropdown (labeled API) and vice versa. These endpoints let external integrations list, fetch, create, update, delete, and load-decoded history records the same way they manage any other model.
bd_history — DB table: bd_history, stored in the site's separate _backups database (not the main directory database)401; keys without the grant return 403.The Backup History Object
| Field | Type | Description |
|---|---|---|
id | integer | Unique history record ID (primary key, read-only, immutable) |
content | longtext | The snapshot payload, up to 16 MB. Usually a JSON string (EG a widget's {"html":...,"style":...,"javascript":...}), but any scalar text is accepted required on create |
type | string | Snapshot type label (EG content, user_edit, search_results). Alphanumeric plus _ . -, max 255 characters required on create |
type_table | string | Name of the table the snapshot belongs to (EG data_widgets). Same character rules as type required on create |
type_column | string | Primary-key column of the source table (EG widget_id). Same character rules as type required on create |
type_value | string | Primary-key value of the source record (EG 2); max 255 characters required on create |
status | integer | Status flag; must be 0 or 1. Defaults to 0 on create |
login_session_id | string | Admin login session that produced the snapshot (nullable; set by platform-generated versions) |
website_notification_id | integer | Related website notification ID (nullable) |
created_by | integer | User ID that created the version; API-created versions default to 0 |
created_at | datetime | Creation timestamp (read-only, immutable) |
updated_at | datetime | Last modified timestamp (advances automatically on update) |
List Backup History Records
Returns a paginated list of history records. Supports the full standard filtering surface — property / property_value / property_operator (single or array form), property_logic ranges, limit, page, order_column, and order_type — against the indexed columns (type, type_column, type_value, created_by, created_at).
Example Requests
# All snapshots of one type curl -X GET "https://www.yourdomain.com/api/v2/bd_history/get?property=type&property_value=content&limit=5" \ -H "X-Api-Key: your-api-key-here" # Multi-field AND filter curl -X GET "https://www.yourdomain.com/api/v2/bd_history/get?property[]=type&property[]=type_table&property_value[]=content&property_value[]=data_widgets" \ -H "X-Api-Key: your-api-key-here" # Date range curl -X GET "https://www.yourdomain.com/api/v2/bd_history/get?property=created_at&property_value=2026-06-01,2026-06-30&property_logic=between" \ -H "X-Api-Key: your-api-key-here"
Retrieve a Backup History Record
Returns a single record by its id. The content field is returned exactly as stored (a raw string). A non-existent ID returns {"status":"error","message":"bd_history not found"}.
Example Request
curl -X GET "https://www.yourdomain.com/api/v2/bd_history/get/341" \ -H "X-Api-Key: your-api-key-here"
Count Backup History Records
Returns an aggregate count. Accepts the same filter parameters as the list endpoint.
Example Request
curl -X GET "https://www.yourdomain.com/api/v2/bd_history/count?property=type&property_value=content" \ -H "X-Api-Key: your-api-key-here"
Example Response
{
"status": "success",
"total": 30
}Create a Backup History Record
Creates a new version. content, type, type_table, type_column, and type_value are required; status and created_by default to 0. Validation errors return a 400 with the failing rules (EG content is required , type is required, type contains invalid characters, status must be 0 or 1, Unknown field: ...).
content is identical to the latest version for the same type + type_table + type_column + type_value tuple, the API refuses with content is identical to the latest version (id N) - no new version created. Pass force_new_version=1 to create a duplicate version. Send force_new_version=1 to create the duplicate anyway.Example Request
curl -X POST "https://www.yourdomain.com/api/v2/bd_history/create" \
-H "X-Api-Key: your-api-key-here" \
--data-urlencode 'content={"html":"<div>VERSION 1</div>","style":".a{}","javascript":"console.log(1)"}' \
--data-urlencode 'type=content' \
--data-urlencode 'type_table=data_widgets' \
--data-urlencode 'type_column=widget_id' \
--data-urlencode 'type_value=2'Example Response
{
"status": "success",
"message": {
"id": "341",
"content": "{\"html\":\"<div>VERSION 1</div>\",\"style\":\".a{}\",\"javascript\":\"console.log(1)\"}",
"type": "content",
"type_table": "data_widgets",
"type_column": "widget_id",
"type_value": "2",
"status": "0",
"login_session_id": null,
"website_notification_id": null,
"created_by": "0",
"created_at": null,
"updated_at": null
}
}Update a Backup History Record
Partial update by id. Only include the fields you want to change. id and created_at are immutable; updated_at advances automatically. Re-sending content identical to the current value is treated as a no-op for that field.
Example Request
curl -X PUT "https://www.yourdomain.com/api/v2/bd_history/update" \ -H "X-Api-Key: your-api-key-here" \ -d "id=341" \ -d "status=1"
Delete a Backup History Record
Hard delete — the table has no soft-delete column, so the version is permanently removed.
Example Request
curl -X DELETE "https://www.yourdomain.com/api/v2/bd_history/delete" \ -H "X-Api-Key: your-api-key-here" \ -d "id=341"
Example Response
{
"status": "success",
"message": "bd_history record was deleted"
}Load a Decoded Revision
Returns one revision with its content decoded into an object (content_decoded: true) so integrations can read fields like content.html directly instead of parsing the stored JSON string. If the stored content is not valid JSON, the raw string is returned unchanged with content_decoded: false. Loading is only supported for the registered revision types; other tables return an error naming the supported set (EG history load is not supported for type_table "users_data". Supported: data_widgets, data_categories, list_seo).
Call the bare GET /api/v2/bd_history/load (no ID) to discover the currently supported types:
Example Request
curl -X GET "https://www.yourdomain.com/api/v2/bd_history/load" \ -H "X-Api-Key: your-api-key-here"
Example Response
{
"status": "success",
"message": {
"supported_types": {
"data_widgets": ["content"],
"data_categories": ["search_results", "profile_page", "detail_page"],
"list_seo": ["content"]
}
}
}Automatic Version History
For the supported types above, the API creates versions automatically: a create or content-changing update through /api/v2/data_widgets/*, /api/v2/data_categories/*, or /api/v2/list_seo/* snapshots the content into bd_history and reports the new version IDs in a bd_history_ids array on the response. Identical-content updates are deduplicated (no bd_history_ids in the response). These automatic versions use created_by = 0, appear in the admin Load Revision dropdown labeled API, and are normalized identically to admin-created versions so deduplication works across both authors.
GET /api/v2/bd_history/load/{id}, then write the decoded content.html back with PUT /api/v2/data_widgets/update.