HTTP API

Read entries

curl 'https://staging.glidzr.com/api/transactions?status=confirmed&direction=expense&limit=50' \
  -H "Authorization: Bearer $TOKEN"

• status: confirmed (default), pending or rejected.
• direction: expense or income. Omit it to read both.
• from and to: optional date filters in YYYY-MM-DD form.
• limit: optional integer from 1 to 200; defaults to 50 when omitted. Invalid values return 400. Newest entries first.

A successful GET returns 200 with ok, status, direction, count and transactions. Each row includes its date, description, category, project, amounts and review status. Reading also brings due entries from existing recurring rules into the ledger.

Propose an entry

The required fields are description, amountand currency. Send a positive amount as a string in major units, exactly as stated. Direction defaults to expense; send income for money received. The example below is illustrative and is not run here.

curl -X POST 'https://staging.glidzr.com/api/transactions' \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"direction":"income","description":"Invoice 118","amount":"4500","currency":"AED","occurredAt":"2026-09-19"}'

Optional context includes occurredAt (defaults to today), merchantName, categorySlug, taxAmount, taxRate, supplierTaxId, referenceand notes. Use a category from the matching expense or income vocabulary. Send printed tax amounts only; a tax rate is a decimal string such as "0.05". A human assigns projects.

A successful bearer-token POST returns 201 with ok: true, transactionId, direction, status: "pending"and a review message. Repeating a POST can create another proposal; this endpoint does not deduplicate identical requests.

Add income or an expense directly

Pass confirm: true on the same POST to record complete structured data immediately. The response has status: "confirmed"and the entry counts in totals. This also works when explicitly confirming the data supplied to a proposal call. It creates a new entry; it does not confirm a previously saved transaction by ID.

{
  "direction": "expense",
  "description": "Train ticket",
  "amount": "45.00",
  "currency": "AED",
  "occurredAt": "2026-10-02",
  "confirm": true
}

Set direction: income for money received. Confirmed entries require a real occurredAt date in yyyy-mm-dd form, description, positive decimal string amount and currency. Confirmed money/rate fields use digits and an optional decimal point, without grouping or currency symbols. Foreign currency also requires the supplied fxRate to the ledger base currency. Invalid tax, category/client references or line items are rejected; unknown fields, project assignment and caller-supplied confidence are not accepted. Never invent missing values. Omitting confirm or passingfalse keeps a proposal pending. Strings such as "true" are invalid. Repeated POSTs create separate entries.

Read money with its exponent

Response amounts use integer minor units, a currency exponent and a formatted value. Do not assume two decimals: JPY uses 0, AED 2 and KWD 3. Amounts are positive; direction says whether money moved in or out.

{
  "amount": {
    "minorUnits": 450000,
    "currency": "AED",
    "exponent": 2,
    "formatted": "AED 4,500.00"
  }
}

This illustrative envelope is produced by the same money formatter used by the ledger. Pending and rejected entries do not count in totals.

Authentication and errors

• 400: invalid JSON, invalid fields or an entry that cannot be recorded.
• 401: missing or invalid authentication. Follow the WWW-Authenticate metadata URL.
• 403: a cookie-authenticated write supplied a mismatched Origin.
• 413: request body exceeds 64 KiB.
• 429 or 503: rate limit or temporary service restriction. Respect the returned error and Retry-After when present. Ingress limits can reject requests before authentication.

A signed-in human session uses a separate validated write path and creates confirmed entries. Bearer tokens default to pending proposals and can explicitly record complete structured entries using confirm: true. Chat, receipt and email extraction still require review.

OAuth discovery · Protected resource metadata