API Data Retention & Deletion Policy
Effective date: July 27, 2026
This policy explains which customer-specific operational records SignedOff keeps to meter, support, secure, and deliver the API, and when those records become eligible for deletion.
Detailed API usage logs and discovery search criteria are retained for 90 days. Canonical API events and terminal webhook delivery records, including their payloads, are retained for 30 days. Scheduled cleanup runs daily, so deletion from the active application database may occur up to 24 hours after a record becomes eligible.
1. Retention schedule
| Record | Active-database window | Deletion rule |
|---|---|---|
| Detailed API usage log | 90 days from creation | All detailed rows older than 90 days are deleted by daily cleanup. |
| Discovery search criteria | 90 days from creation | Ad hoc search criteria are stored only on the corresponding usage row and are deleted with that row. |
| Saved monitored query and match identities | While the saved query exists | Deleting the saved query cascades to its criteria, evaluation state, and retained jurisdiction-plus-permit first-seen identities. |
| Platform new-permit observation identity | While the general discovery monitor operates | SignedOff retains the minimal jurisdiction-plus-permit identity and first/last observation times needed to suppress duplicate general events. It is not tied to an API key, customer, saved query, or search criteria. |
| Jurisdiction expansion vote | While both the request and API key exist | Deleting either the jurisdiction request or API key cascades to the normalized vote. Public responses and prioritization views use aggregate counts rather than customer identity. |
| Canonical API event | 30 days from creation | Events age out of the tenant event feed and active database after 30 days. |
| Webhook delivery record and payload | 30 days from creation once terminal | Delivered and dead rows older than 30 days are deleted. Pending work is never deleted by retention cleanup; if it becomes terminal after day 30, it is eligible at the next daily cleanup. |
2. What detailed API usage logs contain
A metered API call may record the owning API-key identifier, fixed endpoint path, HTTP method and status, response time, creation time, credit weight and billing bucket, transport, cache outcome, a bounded permit-lookup outcome classification, overage state, result count, jurisdiction, permit number, batch grouping, and an internal credit-ledger link.
These rows do not contain the raw API key or webhook signing secret, request or response bodies, a full request URL, or arbitrary request headers. API keys are stored separately as one-way hashes. Aggregated, tenant-neutral operational or financial records that cannot reconstruct an individual request may be retained longer.
Permit lookup outcomes are limited to cache hit, live success, stale fallback, confirmed not found, upstream failure, ambiguous jurisdiction, or unsupported jurisdiction. Jurisdiction scorecards aggregate those retained rows and never expose an API-key identifier, permit number, or customer identity.
3. Discovery search criteria
For a successful permit-discovery request, SignedOff stores only the active supported filters: normalized city or county scope; up to 25 normalized parcel APNs/AINs; ZIP code; latitude, longitude, and radius; permit type; date range; valuation range; status; jurisdiction scope; and result limit. When a pagination cursor is supplied, the log stores cursor: true, not the opaque cursor token.
The usage row records the number of results, not the search-result records or response payload. Criteria are used for metering, support, abuse prevention, product analysis, and pricing evaluation and are deleted with the detailed usage row after 90 days.
Saved monitored queries are different from ad hoc usage rows. SignedOff retains the query name, active filters, state, evaluation timestamps, bounded error text, and the minimal jurisdiction-plus-permit identities needed to avoid duplicate first-seen events while that saved query exists. Scheduled evaluations do not create detailed usage rows or store complete search-result pages. Deleting a saved query removes its definition and match identities from the active application database; already-created canonical events and webhook deliveries follow their separate 30-day windows.
The general new-permit monitor retains a separate tenant-neutral jurisdiction-plus-permit identity with first and last observation timestamps. It stores no customer identifier, saved-query definition, or search criteria. The thin public-record snapshot sent with a permit_created event lives only in that tenant’s canonical event and delivery payload under the 30-day windows above.
4. Jurisdiction expansion votes
An authenticated jurisdiction request stores internal jurisdiction-request and API-key identifiers, the key’s plan and live-or-sandbox kind at the time of the vote, and a timestamp. It never stores the raw API key or account email. A key contributes at most one vote to each request bucket. Public API responses expose only aggregate counts; the internal expansion ranking also uses only aggregate demand and current active-key plan signals.
5. Events and webhook payloads
Canonical API events contain the tenant-scoped event type, affected permit identity, event data, and creation time exposed through the 30-day events feed. For a criteria_match event, event data also contains the saved-query identity, name, active criteria, thin match snapshot, and match time. For permit_created, it contains the SignedOff observation time, discovery-monitor source label, and a thin public-record snapshot. A webhook delivery row contains the exact JSON payload sent for that delivery, its event lineage, destination subscription, attempt state, response status, bounded error text, and retry timestamps.
Automatic retries reuse a delivery record. A manual replay creates a new delivery identity and starts its own retention period. Deleting a terminal delivery removes its stored payload and attempt history; deleting a canonical event does not cancel an already-pending delivery.
The webhook endpoint simulator does not persist its test payload as a delivery record. Customer webhook configuration, including the destination URL and separately protected signing secret, is account configuration rather than delivery history and follows the account lifecycle.
6. Access, deletion, and exceptions
- Customer-facing call history offers recent operational views; it does not extend the windows above.
- Access to retained records is limited to the customer account and authorized SignedOff personnel or service providers who need it for operations, support, security, billing, or legal compliance.
- Daily deletion removes eligible rows from the active application database. Copies may remain temporarily in restricted disaster-recovery backups until those backups expire or are overwritten under the ordinary backup lifecycle.
- SignedOff may preserve a narrowly scoped record longer when required by law, a valid legal hold, fraud or security investigation, payment dispute, or enforcement of the API Terms.
- Account closure does not shorten a stated operational window or require SignedOff to retain a record longer than that window. Requests concerning account data may be sent to support@signedoff.io.
7. Scope and related policies
This policy covers SignedOff’s application-level API usage, event, and delivery records. It does not change a customer’s rights or deletion duties for API Output under the API Terms, or the treatment of account and website data under the Privacy Policy. A signed Enterprise order form may specify different retention for the services it covers.