Users API Overview — Proposed Guide

Users API Overview: The proposed user resource represents a person in an organization, with separate employment context and application-access state. It…

Overview

The proposed user resource represents a person in an organization, with separate employment context and application-access state. It is not a payroll record or a bank beneficiary.

Key concepts

Use a stable user id for relationships and treat email as a mutable contact attribute. Organization membership should be explicit.

Implementation considerations

Define which system owns employment attributes before synchronizing them. Deactivating access must not erase historical expense attribution.

Proposed API behavior

GET /v1/users 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.

Static example requests

# Proposed request text only; this reserved host is not a live API.
curl -X GET 'https://api.remizen.example/v1/users?status=active&limit=25' \
  -H 'Authorization: Bearer YOUR_API_KEY'

Fictional response example

{
  "data": [
    {
      "organization_id": "org_example_123",
      "id": "usr_example_123",
      "display_name": "Taylor Example",
      "email": "taylor@example.com",
      "status": "active"
    }
  ],
  "pagination": {
    "has_more": false,
    "next_cursor": null
  },
  "meta": {
    "request_id": "req_example_123",
    "reference_only": true
  }
}

Illustrative error case

Review this failure case in context: Define which system owns employment attributes before synchronizing them. Deactivating access must not erase historical expense attribution.

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

Proposed data types

Related documentation