Reject Expense — Proposed Guide

Planned API — Reference Only

Reject Expense: Rejection would record why the submitted expense cannot proceed under the current review. It is different from deletion and should…

Overview

Rejection would record why the submitted expense cannot proceed under the current review. It is different from deletion and should preserve supporting evidence.

Key concepts

Use a structured reason and optional review comment. Define whether the employee may edit and resubmit.

Implementation considerations

Do not expose a confidential reviewer note to every caller. Resubmission should create a traceable new review snapshot.

Proposed API behavior

POST /v1/expenses/{expense_id}/reject 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
expense_idrequired	string	Stable fictional expense reference; not a secret and not evidence that a resource exists.

Illustrative request fields
Name	Type	Description
approval_id	string	Stable fictional approval reference; not a secret and not evidence that a resource exists.
reason	string	Synthetic structured justification, not a real reviewer note.
comment	string	Optional review text subject to future access and retention rules.
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/expenses/exp_example_123/reject' \
  -H 'Authorization: Bearer YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  --data '{
  "approval_id": "apr_example_123",
  "reason": "Example review explanation",
  "comment": "Fictional review comment",
  "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": {
    "expense_id": "exp_example_123",
    "approval_id": "apr_example_123",
    "reason": "Example review explanation",
    "comment": "Fictional review comment",
    "version": 1,
    "id": "exp_example_123",
    "organization_id": "org_example_123",
    "merchant": "Example Office Supply",
    "amount_minor": 12550,
    "currency": "USD",
    "status": "rejected"
  },
  "meta": {
    "request_id": "req_example_123",
    "reference_only": true
  }
}

Illustrative error case

Review this failure case in context: Do not expose a confidential reviewer note to every caller. Resubmission should create a traceable new review snapshot.

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 reject expense operation requires review of its input or authorization.",
    "request_id": "req_example_123"
  }
}

Proposed data types

Illustrative field dictionary
Name	Type	Description
expense_id	string	Stable fictional expense reference; not a secret and not evidence that a resource exists.
approval_id	string	Stable fictional approval reference; not a secret and not evidence that a resource exists.
reason	string	Synthetic structured justification, not a real reviewer note.
comment	string	Optional review text subject to future access and retention rules.
version	integer	Illustrative resource revision for detecting stale updates; no live concurrency contract is published.

Approve Expense

Approval Workflows

Approve Expense Report