> ## Documentation Index > Fetch the complete documentation index at: https://docs.go.aiinsurance.io/llms.txt > Use this file to discover all available pages before exploring further. # Delete All Financial Data > **Hard-deletes every financial RECORD the company holds**, returning the number of rows removed: invoices, payments, the journal and ledger, and per-entity account balances. Financial **configuration is kept** — transaction categories, line item types, the accounts minted from them, and approval configuration all survive, so the company's financial setup does not need to be re-authored. This is the **first rung of the breaking-config reset ladder**. A company with live books cannot have its entities bulk-wiped without orphaning every financial row's entity references, so the per-type entity wipe (`POST .../entities/{entityType}/deleteAll`) rejects with `409` while financials hold a live claim. The full reset order for re-importing a breaking configuration is: 1. `POST .../financials/deleteAll` (this endpoint) 2. `POST .../entities/{entityType}/deleteAll` per affected entity type 3. re-import the configuration **Delete-guarded.** The wipe also consults the company's delete guard — the same mechanic that gates the internal admin wipes. A company whose guard is `active` or `onboarding-active` (the default posture for a live company) is rejected with `409` (`DeleteGuardConflict`) and nothing is deleted; the wipe requires a non-active delete guard, set from the Control Plane. **Required permission:** `company.financial-data:deleteAll` — a privileged operational permission granted to SUPER_ADMIN keys only. A key lacking it receives `403`. ## OpenAPI ````yaml /openapi/generated-external-api.yaml post /api/v1/companies/{companyId}/financials/deleteAll openapi: 3.0.3 info: title: AI Insurance External API description: External API for AI Insurance platform version: 1.0.0 contact: email: support@aiinsurance.io servers: - url: https://go.aiinsurance.io description: Production security: - ApiKeyAuth: [] paths: /api/v1/companies/{companyId}/financials/deleteAll: post: tags: - Financials summary: Delete All Financial Data description: > **Hard-deletes every financial RECORD the company holds**, returning the number of rows removed: invoices, payments, the journal and ledger, and per-entity account balances. Financial **configuration is kept** — transaction categories, line item types, the accounts minted from them, and approval configuration all survive, so the company's financial setup does not need to be re-authored. This is the **first rung of the breaking-config reset ladder**. A company with live books cannot have its entities bulk-wiped without orphaning every financial row's entity references, so the per-type entity wipe (`POST .../entities/{entityType}/deleteAll`) rejects with `409` while financials hold a live claim. The full reset order for re-importing a breaking configuration is: 1. `POST .../financials/deleteAll` (this endpoint) 2. `POST .../entities/{entityType}/deleteAll` per affected entity type 3. re-import the configuration **Delete-guarded.** The wipe also consults the company's delete guard — the same mechanic that gates the internal admin wipes. A company whose guard is `active` or `onboarding-active` (the default posture for a live company) is rejected with `409` (`DeleteGuardConflict`) and nothing is deleted; the wipe requires a non-active delete guard, set from the Control Plane. **Required permission:** `company.financial-data:deleteAll` — a privileged operational permission granted to SUPER_ADMIN keys only. A key lacking it receives `403`. operationId: deleteAllFinancialData parameters: - $ref: '#/components/parameters/companyId' responses: '200': description: All financial records were deleted (configuration kept) content: application/json: schema: type: object properties: deletedRecords: type: integer description: >- Total number of rows removed across the financial-record tables (journal, ledger, invoices, payments, balances). examples: success: summary: Financial records deleted value: deletedRecords: 128 '401': $ref: '#/components/responses/Unauthorized' '403': $ref: '#/components/responses/Forbidden' '409': description: >- Conflict - the company's delete guard does not allow clearing financial data; nothing was deleted. The wipe requires a non-active delete guard, set from the Control Plane. content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' examples: deleteGuardConflict: summary: Delete guard forbids the wipe value: error: code: DeleteGuardConflict message: >- Company delete guard status "active" does not allow clearing financial data. Only companies with status "onboarding-allows-delete", "demo", "internal-dev", "inactive" are permitted. userMessages: - >- Company delete guard status "active" does not allow clearing financial data. Only companies with status "onboarding-allows-delete", "demo", "internal-dev", "inactive" are permitted. '500': $ref: '#/components/responses/InternalServerError' components: parameters: companyId: name: companyId in: path required: true schema: type: string format: uuid description: Company identifier responses: Unauthorized: description: Unauthorized - Invalid or missing API key content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' examples: missingApiKey: summary: Missing API key value: error: code: AuthenticationError message: API key authentication required userMessages: - API key authentication required invalidApiKey: summary: >- Invalid API key (e.g. unknown key, or a Bearer token used instead of an API key) value: error: code: AuthenticationError message: Invalid API key userMessages: - Invalid API key Forbidden: description: Forbidden - Insufficient permissions content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' examples: insufficientPermissions: summary: Insufficient permissions value: error: code: AuthorizationError message: User is not authorized to perform the requested action userMessages: - User is not authorized to perform the requested action companyMismatch: summary: A valid API key naming another company in the URL value: error: code: AuthorizationError message: API key is not scoped to the requested company userMessages: - API key is not scoped to the requested company InternalServerError: description: Internal Server Error - Unexpected error occurred content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' examples: internalError: summary: Unexpected server error value: error: code: UncaughtActionError message: Uncaught error occurred in userMessages: - An unexpected error occurred. Please try again later. schemas: ErrorResponse: type: object description: Standard error response for all external API endpoints required: - error properties: error: type: object required: - code - message properties: code: type: string description: Machine-readable error code example: VALIDATION_ERROR message: type: string description: Human-readable error message example: 'submissionId: Required field is missing' userMessages: type: array description: >- Clean, verbatim-displayable messages — one entry per failure, free of error-code tags, field paths, and internal noise. Suitable for showing to end users as-is. items: type: string example: - Exposures of type 'company' require an address details: type: array description: Additional details for validation errors (field-level errors) items: type: object properties: field: type: string description: The field that caused the error example: submissionId message: type: string description: Description of the field error example: Required field is missing securitySchemes: ApiKeyAuth: type: apiKey in: header name: Authorization description: >- API key authentication. Send your raw API key as the `Authorization` header value with NO scheme prefix — `Authorization: YOUR-API-KEY`. Do NOT prefix it with `Bearer ` or `ApiKey `, and do not use an `X-API-Key` header; those are not accepted. ````