Changelog

All notable, integrator-facing changes to the Defentry Gateway API are documented here. For a focused before/after migration walkthrough, see Legacy & Migration.

---

2026-06-12 — Standardized response format

Breaking — standardized clients only

These changes affect requests that send X-API-Version: 2026-06-12. See Response & Error Conventions for the full rules.

Datetimes are RFC 3339 / ISO-8601 in UTC

• Before: "created_at": "2024-06-15 10:00:00" (space-separated, no timezone)
• After: "created_at": "2024-06-15T10:00:00Z"
• Pure date fields (e.g. activation_date) remain date-only ("2024-06-15").

Booleans are real JSON booleans

• Before: could be 1/0, "1"/"0", or "true"/"false".
• After: fields prefixed is_, has_, can_, show_, enable_, skip_ return JSON true/false.

Single, standardized error envelope

{
  "error": {
    "code": "VALIDATION_ERROR",
    "message": "Human-readable, localized message",
    "details": [{ "field": "email", "issue": "The email field is required." }]
  }
}

• Replaces the multiple legacy shapes ({ "errors": [...] }, { "errors": { "field": ["msg"] } }, { "error": "..." }, { "message": "..." }).
• code is stable and non-localized — branch on it.
• Error Content-Type is now application/json (some legacy errors used application/vnd.api+json).
• Extra/non-standard top-level keys (e.g. corr_id) are no longer returned.

Rate-limit responses use HTTP 429

• Before: throttling returned HTTP 409 Conflict.
• After: HTTP 429 Too Many Requests with code: RATE_LIMITED.

Fixed — all clients

• Plan endpoint updated_at was malformed. PlanResource produced an invalid date (Y-md format). It now returns a valid date string (or ISO-8601 for standardized clients).
• CRM user boolean validation now enforced. is_service_account and is_set_password on the CRM user create/update endpoints used an invalid rule (bool) that skipped validation; they now use boolean. Requests sending non-boolean values for these fields may now be rejected.

Documentation corrections

The published docs now match the real responses for GET /api/v1/delete-my-data/scan/status:

• Documented sites[].can_send_deletion_request.
• Documented removal_requests[].manual_instructions (present only when manual user action is required).
• Corrected the scan status enum to SCAN_NOT_STARTED, SCAN_INITIATED, SCAN_FAILED, SCAN_COMPLETED.
• Corrected the removal request status enum to POA_SENT_TO_SITE, USER_MANUAL_INSTRUCTIONS_SENT, DATA_REMOVED_VERIFIED, DATA_REAPPEARED_DETECTED.
• Corrected the removal_requests[] shape (status, created_at, updated_at, and conditionally manual_instructions); the previously documented id, site_id, site_name, completed_at do not exist.
• Fixed the OpenAPI schema for the scan status response.

Known differences not yet standardized

• Field-name casing: some upstream fields remain PascalCase (e.g. EventTime).
• Sweetpay subscription created_at is date-only (YYYY-MM-DD).
• Statistics endpoints return period labels (e.g. "Jun-2024").