Deactivate User — Proposed Guide

Planned API — Reference Only

Deactivate User: Deactivation would remove future application access while retaining historical records for authorized business use. It is different from…

Overview

Deactivation would remove future application access while retaining historical records for authorized business use. It is different from deleting a profile or cancelling all pending expenses.

Key concepts

Record the effective date and reason. Reassign open responsibilities through a separate approved workflow.

Implementation considerations

Define what happens to pending approvals and service-owned jobs before deactivation. Do not redirect reimbursement ownership automatically.

Proposed API behavior

POST /v1/users/{user_id}/deactivate is an illustrative design for this topic. Path and field names may change before implementation. Access would require an authorized organization context and operation-specific permission; no public API or authorization grant is available here.

Proposed path parameters
Name	Type	Description
user_idrequired	string	Stable fictional user reference; not a secret and not evidence that a resource exists.

Illustrative request fields
Name	Type	Description
effective_on	string (date)	Synthetic calendar date in YYYY-MM-DD form; period inclusivity must be defined by the future contract.
reason	string	Synthetic structured justification, not a real reviewer note.
version	integer	Illustrative resource revision for detecting stale updates; no live concurrency contract is published.

Static example requests

Proposed, non-executing request examples

# Proposed request text only; this reserved host is not a live API.
curl -X POST 'https://api.remizen.example/v1/users/usr_example_123/deactivate' \
  -H 'Authorization: Bearer YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  --data '{
  "effective_on": "2026-01-15",
  "reason": "Example review explanation",
  "version": 1
}'

Fictional response example

200 (proposed example)Static response fixture

Fictional documentation data only. No request was sent, record created, review performed, payment initiated or provider connection activated.

JSON

{
  "data": {
    "effective_on": "2026-01-15",
    "reason": "Example review explanation",
    "version": 1,
    "id": "usr_example_123",
    "organization_id": "org_example_123",
    "display_name": "Taylor Example",
    "email": "taylor@example.com",
    "status": "inactive"
  },
  "meta": {
    "request_id": "req_example_123",
    "reference_only": true
  }
}

Illustrative error case

Review this failure case in context: Define what happens to pending approvals and service-owned jobs before deactivation. Do not redirect reimbursement ownership automatically.

422 (illustrative; final error contracts are undecided)Proposed error fixture

Synthetic diagnostic example. Human-readable messages must not be used as stable programmatic contracts.

JSON

{
  "error": {
    "code": "validation_error",
    "message": "The proposed deactivate user operation requires review of its input or authorization.",
    "request_id": "req_example_123"
  }
}

Proposed data types

Illustrative field dictionary
Name	Type	Description
user_id	string	Stable fictional user reference; not a secret and not evidence that a resource exists.
effective_on	string (date)	Synthetic calendar date in YYYY-MM-DD form; period inclusivity must be defined by the future contract.
reason	string	Synthetic structured justification, not a real reviewer note.
version	integer	Illustrative resource revision for detecting stale updates; no live concurrency contract is published.

Update User

Users & Organizations

User Roles