Skip to content
Integrations
California DROP
Operations & Audit

Operations & audit

The DROP operations surface provides an append-only audit log, an incremental suppression feed, and controls for replaying and troubleshooting suppression cycles.

Audit log

Every DROP action is recorded in an append-only audit log — rows can never be updated or deleted, which is enforced at the database level. Each event captures the resource, event type, actor (user or system for scheduled runs), timestamp, and a structured payload with the relevant details (trigger, cycle ID, error, row counts by status, and so on).

Recorded events include:

  • Connector created / updated
  • Cycle scheduled, started, failed, replayed
  • Backfill triggered, completed, failed
  • Retro sweep results (hashes scanned, matched, erasure requests minted)
  • Suppression ledger manual overrides

Browse the log from the Audit log tab on the integration page — a table of time, event, cycle, and actor, filterable by date range, event type, and resource type, with the structured payload expandable per event. The same data is available via the API with the drop_audit:read scope:

GET /api/v1/plus/drop/audit?resource_type=drop_cycle&resource_id=<cycle_id>

The endpoint is cursor-paginated and filterable by resource type, resource ID, event type, and time range.

Suppression feed API

Downstream systems that need to keep processed DROP identifiers suppressed — for example, to prevent deleted data from being re-ingested from suppliers — can pull the suppression ledger incrementally through a read-only feed. The feed contains DROP erasure-suppression outcomes and returns hashes only, never raw identifiers or consumer keys. It requires the drop_suppression:read scope:

GET /api/v1/plus/drop/processed-subjects?since=2026-07-01T00:00:00Z
{
  "rows": [
    {
      "drop_hash": "<Base64 SHA-256 hash, exactly as DROP delivered it>",
      "work_item_id": "<DROP work item ID>",
      "list_type": "Email",
      "status": 3,
      "processed_at": "2026-07-27T10:15:00Z"
    }
  ],
  "next_cursor": "<opaque cursor>",
  "has_more": false
}
  • Filters: since (ISO 8601, must include a UTC offset or Z — naive timestamps are rejected), list_type, and status (repeatable, e.g. status=3&status=4).
  • Pagination: keyset-based, ascending by processed time. page_size defaults to 1,000 (max 10,000). Pass next_cursor to fetch the next page; has_more indicates whether another page exists right now. Cursors encode the filters they were minted with — resuming a cursor with different filters returns a 400 rather than silently skipping rows — and expire after 30 days, after which the client should restart with since.
  • Eventual consistency: rows become visible in the feed only after a short grace period (about 10 seconds) past their processed_at time, guaranteeing that pagination never skips rows from concurrent writers. Poll with an overlapping since window rather than expecting instant visibility.
  • Rate limiting: when the deployment has API rate limiting enabled, bursts receive 429 with a Retry-After header.

Concurrency and locks

DROP work is single-flight per integration: cycles take a 30-minute lock and backfills/retro sweeps take a separate long-running lock, so overlapping runs cannot double-process or double-report. A manually triggered cycle that finds the lock held waits and retries for up to about two hours before failing. Lock contention resolves itself; there is nothing to clean up manually.

Retro-match sweep

The retro sweep runs automatically after each successful backfill. It re-probes work items previously reported as 5 Not found against the refreshed match index and mints erasure privacy requests for new matches. Two deliberate limitations:

  • No ledger rewrite — the original status-5 ledger entry stands until DROP redelivers the work item, at which point the next cycle reports the corrected status.
  • No retroactive upload — Astralis never amends a past response from a retro sweep; correction flows through the normal cycle.

Troubleshooting

SymptomLikely causeWhat to do
Cycle skippedDROP had no data for the day, or a replay superseded the scheduled cycleNo action needed
Cycle failed right awayInvalid API key or secretsRe-enter the API key on the integration and use Test connection
Cycle deferred / re-queuedRun collided with the DROP maintenance window (01:00–03:00 PT)No action needed; it re-runs after the window
Scheduled cycles never runInitial backfill has not completedComplete the Mapping configuration and run a backfill; check the backfill status card
Backfill fails validationGather query violates the contractRun Validate mapping and fix the reported violation — see the gather query contract
File upload shows retries/failureTransient DROP API errors exhausted automatic retriesInspect the file's upload status in the cycle detail; Replay the cycle to re-submit as an amend
Cycle stuck in awaiting_completionMinted erasure privacy requests have not finishedCheck the linked erasure requests in Request manager; the cycle finalizes as they complete
SLA countdown near zero with pending erasuresDownstream erasures are slow or erroredAstralis alerts once and keeps polling; reprocess the errored erasure requests

Investigating a specific work item

  1. Open the cycle in the DROP cycles tab and download the input and response CSVs to locate the work item and its reported status.
  2. For a 3 Deleted row, follow the minted erasure request (external ID drop:{consumer_key}) in the Request manager; its detail view shows a badge linking back to the DROP cycle.
  3. Check the audit log for the cycle to see the full event history, including replays and their reasons.

File name suffixes

DROP occasionally publishes work-item files with an extra suffix token (for example 20260312_4821_Email_retry01.csv). Astralis parses suffixed and unsuffixed file names interchangeably; no configuration is needed.

Create Erasures via APIDataset Annotation Reference