Skip to main content

Documentation Index

Fetch the complete documentation index at: https://nova.dweet.com/docs/llms.txt

Use this file to discover all available pages before exploring further.

Use deletion requests when a customer leaves, a tenant asks you to remove its data, or one application needs to be removed before automatic cleanup runs. Deletion runs asynchronously. Nova returns a deletionRequest.id immediately, then processes the request in the background.

​
Endpoints

ActionEndpointScope
Delete one applicationDELETE /v1/jobs/{jobId}/applications/{applicationId}Requires X-Tenant-Id
Delete one tenantDELETE /v1/tenants/{tenantExternalId}Uses the tenant external ID in the path
Poll statusGET /v1/deletion-requests/{deletionRequestId}Uses the deletion request ID

​
Flow

1

Submit the deletion request

Call the application or tenant deletion endpoint. Store the returned deletionRequest.id.
2

Poll the request

Call GET /v1/deletion-requests/{deletionRequestId} until the status is completed or failed.
3

Handle retries

Retrying the same active application or tenant deletion request returns the existing request where possible.

​
Status values

StatusMeaning
pendingNova accepted the request
processingBackground deletion is running
completedNova processed the request
failedThe request failed

​
Scope

Nova scopes every deletion by the authenticated API key and environment. Application deletion removes active data linked to the specified tenant, job, and application. Tenant deletion removes active tenant-scoped Embed data. Deletion status responses don’t expose internal cleanup counts, storage details, raw tenant IDs, job IDs, or application IDs. Keep the deletionRequest.id if you need to discuss a request with Nova support. See Data Retention for retention windows, backups, logs, and sub-processors.