Reset household data — wipe the household's financial data and start over (admin only)
const url = 'https://api.tovarifinancial.com/org/reset';const options = { method: 'POST', headers: {Authorization: 'Bearer <token>', 'Content-Type': 'application/json'}, body: '{"confirm":"RESET","surface":"data-privacy","platform":"web"}'};
try { const response = await fetch(url, options); const data = await response.json(); console.log(data);} catch (error) { console.error(error);}curl --request POST \ --url https://api.tovarifinancial.com/org/reset \ --header 'Authorization: Bearer <token>' \ --header 'Content-Type: application/json' \ --data '{ "confirm": "RESET", "surface": "data-privacy", "platform": "web" }'Returns the caller’s household to a brand-new sign-up’s state while keeping who it is and what it pays for. IRREVERSIBLE — there is no undo; export the household’s data first (POST /org/export). The target household is ALWAYS the caller’s own, from the authenticated session; no id is accepted in the body.
WIPED: every account and everything under it (transactions, bills, imports, linked-bank sync state), budgets and budget amounts, categories and sections, payees, recurring/transfer/duplicate suggestions, review state, register view preferences, the notification feed and CSV mapping profiles. The household then holds exactly a fresh sign-up’s categories (categoriesSeeded); payees are not re-seeded. KEPT: the household itself, every member’s sign-in, role and onboarding state, linked sign-in identities, subscription and billing, policy acceptances, two-factor settings, notification preferences and registered devices, invites, data exports and the audit trail.
Linked banks are disconnected at the bank data provider FIRST. If any cannot be disconnected the request answers 503 HOUSEHOLD_RESET_PLAID_UNAVAILABLE and NOTHING is deleted — retry with the same key.
ADMIN ONLY (the stored household role, never a token claim). X-Idempotency-Key is REQUIRED: a missing or blank key is refused with 400 VALIDATION_ERROR before any work is done. Retrying the same key with the same body after a success replays the recorded 200 and does nothing new; the same key with a different body is 409 IDEMPOTENCY_CONFLICT. Every other non-2xx leaves the key unused, so the same key may be retried. confirm must be exactly RESET (case-sensitive, not trimmed); surface and platform are reporting context only. Like POST /org/deletion this route is policy-gate and subscription exempt, so it never answers POLICY_ACCEPTANCE_REQUIRED or SUBSCRIPTION_REQUIRED; email verification still applies.
A 409 carries HOUSEHOLD_DELETION_IN_PROGRESS (a deletion of the household is in flight), HOUSEHOLD_RESET_IN_PROGRESS (the household is busy — another reset is running), HOUSEHOLD_RESET_EXPORT_PENDING (the caller’s own data export is still being prepared) or IDEMPOTENCY_CONFLICT; nothing is deleted on any of them. A 503 means nothing was deleted.
Authorizations
Section titled “Authorizations”Parameters
Section titled “Parameters”Header Parameters
Section titled “Header Parameters”Optional idempotency key for safe write retries. Every operation that declares this header reads it. Three cases, told apart per operation: (1) where the operation also documents a 409 whose codes include IDEMPOTENCY_CONFLICT, replaying this key with a different payload returns 409 IDEMPOTENCY_CONFLICT and replaying it with the same payload returns the original response; (2) where it documents no 409, a replay is reconciled optimistically against a unique key column and answers the original 200; (3) where it documents a 409 whose codes do NOT include IDEMPOTENCY_CONFLICT, a conflict on this key is impossible — a replay answers a 200, and that 409 is a resource-state conflict described by the operation’s own 409 schema.
Request Bodyrequired
Section titled “Request Bodyrequired”object
Exactly RESET.
Where the reset was started from. Reporting only.
The client platform. Reporting only.
Responses
Section titled “Responses”Household data reset (or the recorded replay of a completed key)
object
object
Linked bank connections disconnected by this request.
Categories the household holds after the reset — a fresh sign-up’s set.
Example
{ "data": { "status": "reset" }}Validation failed — see errorCode / fieldErrors
object
Machine-readable error code (AUTH_ERROR_CODES).
Optional field-level validation errors, keyed by field name.
object
Example
{ "errorCode": "INVALID_EMAIL_FORMAT"}Missing, invalid, or expired bearer token
object
Machine-readable error code (AUTH_ERROR_CODES).
Optional field-level validation errors, keyed by field name.
object
Example
{ "errorCode": "INVALID_EMAIL_FORMAT"}Authenticated, but the tenant gate refuses the request until the caller resolves a precondition. errorCode is one of EMAIL_NOT_VERIFIED, POLICY_ACCEPTANCE_REQUIRED, or SUBSCRIPTION_REQUIRED, evaluated in exactly that order (contract term CCR-1: email verification first, then policy acceptance, then subscription — so a subscriber who has merely not re-accepted the current policies always sees POLICY_ACCEPTANCE_REQUIRED). A POLICY_ACCEPTANCE_REQUIRED body additionally carries details.outstanding (the policy versions still to accept) and details.firstAcceptance. The SUBSCRIPTION_REQUIRED arm is INERT unless the server-side BILLING_ENABLED flag is exactly the string true; while it is off, only the first two codes are reachable. Not retryable as sent — resolve the named condition, then resend. This operation can ALSO answer 403 with errorCode FORBIDDEN, which is a refusal by the caller’s HOUSEHOLD ROLE rather than by the tenant gate: only a household admin may perform it, and a member is refused before anything is read or written. That arm carries no details and is not cleared by resolving anything on the account — it needs an admin. It is INDEPENDENT of BILLING_ENABLED, so the reachable set here is three codes today (the two gate codes above plus FORBIDDEN) and four once billing is on. The errorCode enum on this operation’s response schema is the complete, machine-readable list.
object
Which condition refused the request. The first three are the tenant gate, evaluated in that order (CCR-1), and SUBSCRIPTION_REQUIRED is unreachable while BILLING_ENABLED is not exactly true. FORBIDDEN is a refusal by the target resource itself (or, on POST /invites, by the caller’s household role) and carries no details.
object
Active policy versions the user has not yet accepted.
object
True when the user has accepted no policy before — the client renders the new-signup screen rather than the re-acceptance one.
Example
{ "errorCode": "EMAIL_NOT_VERIFIED"}Conflict. errorCode is IDEMPOTENCY_CONFLICT when an X-Idempotency-Key was replayed with a different request payload; where the operation instead detects a resource-state conflict it carries that endpoint’s own errorCode (a duplicate name, an import that is no longer committable, an account already linked to a bank connection).
object
Machine-readable error code (AUTH_ERROR_CODES).
Optional field-level validation errors, keyed by field name.
object
Example
{ "errorCode": "INVALID_EMAIL_FORMAT"}Internal error (no internal detail leaked)
object
Machine-readable error code (AUTH_ERROR_CODES).
Optional field-level validation errors, keyed by field name.
object
Example
{ "errorCode": "INVALID_EMAIL_FORMAT"}Service temporarily unavailable — errorCode is SERVICE_UNAVAILABLE. A TRANSIENT, RETRYABLE condition rather than a defect in the request: a query that exceeded its time budget, a lost or refused database connection, a saturated connection pool, or an outage at an upstream provider the request depends on (the authentication provider, or the bank data provider on a bank-connection operation). The identical request may succeed on retry — back off briefly and, on a write, resend the same X-Idempotency-Key where the operation accepts one.
object
Machine-readable error code (AUTH_ERROR_CODES).
Optional field-level validation errors, keyed by field name.
object
Example
{ "errorCode": "INVALID_EMAIL_FORMAT"}