@lunch-money/developer-docs 2.11.0 → 2.11.1-docs.1

package/v2/docs/intro-to-v2.md

@@ -1,4 +1,4 @@
-# v2 API Overview
+# v2 API overview
 
 Welcome to the Lunch Money v2 API. This page covers the core concepts you need to work with the API effectively — authentication, response shapes, naming conventions, error handling, and more. If you're migrating from v1, see the [Migration Guide](./migration-guide.md).
 
@@ -10,7 +10,7 @@ All API requests require a Bearer token in the `Authorization` header:
 Authorization: Bearer YOUR_ACCESS_TOKEN
 ```
 
-Get your access token from the <a href="https://my.lunchmoney.app/developers" target="_blank" rel="noopener noreferrer">Lunch Money developers page</a>. See the [Getting Started guide](/v2/getting-started) for a step-by-step walkthrough including how to create a test budget.
+Get your access token from the <a href="https://my.lunchmoney.app/developers" target="_blank" rel="noopener noreferrer">Lunch Money Developers page</a>. See the [Getting started guide](/getting-started) for a step-by-step walkthrough including how to create a test budget.
 
 ## Base URL
 
@@ -18,7 +18,7 @@ Get your access token from the <a href="https://my.lunchmoney.app/developers" ta
 https://api.lunchmoney.dev/v2
 ```
 
-## Response Shapes
+## Response shapes
 
 The v2 API uses consistent HTTP status codes and response bodies across all endpoints.
 
@@ -39,7 +39,7 @@ All errors return an appropriate 4XX status code — the v2 API never returns an
 | `401` | Unauthorized — missing or invalid Bearer token |
 | `404` | Not Found — the requested object does not exist |
 | `422` | Unprocessable Content — request is valid but cannot be fulfilled (e.g., deleting a category with dependents) |
-| `429` | Too Many Requests — rate limit exceeded; response includes a `Retry-After` header. See the [Rate Limiting guide](/v2/rate-limits). |
+| `429` | Too Many Requests — rate limit exceeded; response includes a `Retry-After` header. See the [Rate limiting guide](/rate-limits). |
 
 All error responses share a consistent body format:
 
@@ -52,7 +52,7 @@ All error responses share a consistent body format:
 }
 ```
 
-> [!NOTE] Atomic Operations
+> [!NOTE] Atomic operations
 > When a request fails, no part of it is applied to your data. For example, if one transaction in a bulk insert has a validation error, none of the transactions in that request are inserted. Fix the errors and retry — you don't need to worry about partial duplicates.
 >
 > If a request has multiple validation errors, the response will attempt to list as many as possible, but it is not guaranteed to catch all errors in a single response.
@@ -61,7 +61,7 @@ All error responses share a consistent body format:
 
 The v2 API validates all requests strictly. A `400` is returned if the request includes unexpected parameters, missing required fields, fields with invalid values, or unexpected properties in the request body. This makes it easier to catch mistakes during development.
 
-## Naming Conventions
+## Naming conventions
 
 Object properties follow consistent rules across the entire API:
 
@@ -72,11 +72,11 @@ Object properties follow consistent rules across the entire API:
 - Child objects of the same type are always in a `children` property
 - All `id` fields are `integer` type (not `number`)
 
-## Amounts, Balances & Sign Convention
+## Amounts, balances & sign convention
 
-The v2 API uses a consistent set of properties — `amount`, `balance`, `currency`, and `to_base` — across all objects that deal with money. See the [Amounts & Balances guide](/v2/amounts-and-balances) for a full explanation of how these properties work, including the sign convention and multi-currency support.
+The v2 API uses a consistent set of properties — `amount`, `balance`, `currency`, and `to_base` — across all objects that deal with money. See the [Amounts & balances guide](/amounts-and-balances) for a full explanation of how these properties work, including the sign convention and multi-currency support.
 
-## Hydrated vs. Non-Hydrated Responses
+## Hydrated vs. non-hydrated responses
 
 In v1, some endpoints returned "hydrated" objects — related object details were embedded directly in the response alongside their IDs. For example, a transaction included `category_name`, `asset_name`, and an array of full tag objects.
 
@@ -93,17 +93,17 @@ In v2, responses are **non-hydrated**: related objects are returned as IDs only.
 
 This improves response times and keeps the API consistent. For apps that need related object details frequently, maintaining a local cache of categories, accounts, and tags is the recommended pattern.
 
-## Updating Objects (PUT)
+## Updating objects (PUT)
 
 Most objects in the v2 API are updatable via `PUT /endpoint/{id}`. The rules are consistent:
 
 - Request bodies may contain any mix of **user-definable** properties (will be updated) and **system-defined** properties like `id` or `created_at` (accepted but ignored).
 - Any unexpected property that is neither user-definable nor system-defined will fail validation and return `400`.
 
-> [!WARNING] Overwrite Behavior
+> [!WARNING] Overwrite behavior
 > Complex properties — objects and arrays — are **replaced entirely** by whatever is in the request body. To add a tag to a transaction without removing existing tags, first fetch the transaction, add the new tag ID to the existing `tag_ids` array, then PUT the full updated array.
 
-> [!TIP] Recommended Pattern
+> [!TIP] Recommended pattern
 > Because system-defined properties are tolerated in PUT requests, you can safely GET an object, modify the properties you want to change, and PUT the whole thing back without stripping system fields first.
 
 ## Versioning

package/v2/docs/migration-guide.md

@@ -99,7 +99,7 @@ One change worth noting: all `id` fields are now explicitly `integer` type (not
 
 #### New Properties
 
-- `debits_as_negative`: A user preference shown in the Lunch Money app. This no longer changes how transaction amounts are represented in the v2 API, but apps may use this setting to display amounts and balances in the way the user prefers. See the [Amounts & Balances guide](/v2/amounts-and-balances) for details.
+- `debits_as_negative`: A user preference shown in the Lunch Money app. This no longer changes how transaction amounts are represented in the v2 API, but apps may use this setting to display amounts and balances in the way the user prefers. See the [Amounts & balances guide](/amounts-and-balances) for details.
 
 <a href="./changelog-visual#user-object-row" target="_blank" rel="noopener noreferrer">View v1/v2 differences</a>
 
@@ -386,7 +386,7 @@ GET /v2/transactions
 > [!WARNING] Behavior Change
 > In the v1 API the optional `debit_as_negative` query parameter could change how transaction amounts were represented. In the v2 API, transaction amount signs are fixed: positive values are debits and negative values are credits. Existing applications that assume positive values are credits need to be updated.
 
-See the [Amounts & Balances guide](/v2/amounts-and-balances) for the full sign convention and how `to_base` works for multi-currency accounts.
+See the [Amounts & balances guide](/amounts-and-balances) for the full sign convention and how `to_base` works for multi-currency accounts.
 
 
 > [!TIP] Migration Tip

package/v2/docs/version-history.md

@@ -5,6 +5,14 @@ The Lunch Money API spec uses a modified version of SEMVER for its versioning me
 - The minor version represents the number of main endpoints the current version of the spec supports.  For example, a version of the API that supports the /me, /categories, and /transactions endpoints would have a minor version of 3.
 - The revision number represents the number of updates since the last endpoint was added.  For example, each time changes are made to one of the existing three APIs as described above, the revision number will be bumped.
 
+## v2.11.1 - Sep 28, 2026
+- Add `GET /me/account/settings` and `PUT /me/account/settings` for account-level settings
+- Add `GET /me/user/settings` and `PUT /me/user/settings` for user-level display and formatting preferences
+- Add `GET /me/user/account/settings` and `PUT /me/user/account/settings` for settings specific to a user and budget account
+- Add `include_pending_in_totals` to `GET /me/account/settings` and `PUT /me/account/settings`
+- Add `default_manual_account_id` to `GET /me/user/account/settings` and `PUT /me/user/account/settings`
+- Document `GET /budgets/settings` response schema publicly; change `budget_period_quantity` to integer
+
 ## v2.11.0 - Jul 31, 2026
 - Add `/balance_history` endpoints:
   - `GET /balance_history`