Receipt Uploads — Proposed Guide

Planned API — Reference Only

Receipt Uploads: An upload-intent design would separate file authorization from recording receipt metadata. The sample describes an intended resource but…

Overview

An upload-intent design would separate file authorization from recording receipt metadata. The sample describes an intended resource but does not issue a signed URL or accept a file.

Key concepts

Validate allowable content types and size before any future transfer. Bind the intent to an authorized organization and expense context.

Implementation considerations

Completion must be confirmed by server-side validation, not a client assertion. No storage provider or malware-scanning control is claimed here.

Proposed API behavior

POST /v1/receipts/upload-intents 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.

Illustrative request fields
Name	Type	Description
expense_id	string	Stable fictional expense reference; not a secret and not evidence that a resource exists.
filename	string	Synthetic file label; do not trust it as a content-type or authorization check.
content_type	string	Illustrative media type that would need validation before any future file transfer.
size_bytes	integer	Illustrative file size in bytes; no upload limit is committed.

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/receipts/upload-intents' \
  -H 'Authorization: Bearer YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  --data '{
  "expense_id": "exp_example_123",
  "filename": "example-receipt.pdf",
  "content_type": "application/pdf",
  "size_bytes": 2048
}'

Fictional response example

201 (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",
    "filename": "example-receipt.pdf",
    "content_type": "application/pdf",
    "size_bytes": 2048,
    "id": "receipts_example_123",
    "organization_id": "org_example_123"
  },
  "meta": {
    "request_id": "req_example_123",
    "reference_only": true
  }
}

Illustrative error case

Review this failure case in context: Completion must be confirmed by server-side validation, not a client assertion. No storage provider or malware-scanning control is claimed here.

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 receipt uploads 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.
filename	string	Synthetic file label; do not trust it as a content-type or authorization check.
content_type	string	Illustrative media type that would need validation before any future file transfer.
size_bytes	integer	Illustrative file size in bytes; no upload limit is committed.

Expense Receipts

Expense Management

Receipt OCR