Budgeting apps with an API: automating your finances with your own scripts

Why an API matters for a budgeting app

An API lets your own code read and change your budget data. That opens jobs the app does not do: importing from an unsupported bank or a payroll export, pushing a weekly summary to your own dashboard, reconciling against a ledger, or backing up data on a schedule. It also reduces lock-in, because you can pull your data out on your terms.

This guide cites only official developer documentation read on 29 October 2026. We have not built or run integrations against these APIs.

The APIs side by side

YNAB API: mature, careful, mostly read

YNAB's API exchanges JSON over HTTPS. The docs call v1 mostly read-only, but the changelog adds writes: create and update transactions, create and update categories and category groups, create accounts, create payees and rename them, and create, update and delete scheduled transactions. Endpoints now refer to budgets as plans. Version 1.88.0, dated 28 October 2026, deprecated the import transactions endpoint, which triggered imports on linked accounts; requests are still accepted but no import is performed. A custom importer for an unsupported bank should create transactions directly.

Two features make reporting scripts efficient. Delta requests: responses include a server_knowledge value, and passing it back as last_knowledge_of_server returns only what changed. The limit of 200 requests per hour per token, on a rolling window, is tight enough that delta requests are effectively required for anything that polls. Exceeding it returns HTTP 429.

The terms matter if you share a tool: new OAuth apps are limited to 25 access tokens for other users until YNAB reviews them, typically in two to four weeks; apps must not handle users' bank credentials, must publish a privacy policy and must not imply YNAB endorsement.

Lunch Money API: broad write access, fast limit

Lunch Money's v2 API uses Bearer tokens created in the app's Developers settings; the help center says you give each token a label and a reason. Responses follow consistent rules: 201 for creates, 204 for deletes, errors always as 4xx, and requests validated strictly so unexpected fields return 400. Operations are atomic: if one transaction in a bulk insert fails validation, none are inserted, which removes a whole class of partial-duplicate bugs in import scripts.

The v2 changelog lists endpoints for transactions, including split, unsplit, group and file attachments, categories, tags, budgets, recurring items, a summary endpoint, manual and synced crypto, and balance history. The rate limit is 100 requests per minute per IP address, shared by all requests from that IP; responses carry RateLimit headers and a Retry-After header on 429. Note the shared-IP rule if you run scripts behind a proxy or on shared hosting.

The help center describes the developer API as in open beta. A static mock server at mock.lunchmoney.dev accepts any Bearer token of 11 or more characters, so you can build and test without touching real data.

PocketSmith and Monarch

PocketSmith's developer documentation shows a developer key sent in an X-Developer-Key header, managed under Settings, Security in the app, with OAuth 2 for apps used by other people. The docs say the API is available for anyone to use, include guides on OAuth, budgeting, pagination, errors and an MCP server, and generate the API reference from OpenAPI 3 documentation you can use to build a client in your own language. Developers building an app for other users email PocketSmith to register and receive OAuth credentials.

Monarch's help center describes an MCP connector at api.monarch.com/mcp for AI tools such as Claude, ChatGPT, Cursor and Gemini CLI. Connections are read-only by default, write access is opt-in, and access can be revoked from Settings. It is available on Core and Plus, with more usage on Plus, and data provided by Finicity is not currently available through it. We did not find a documented general-purpose REST API on the Monarch pages we read.

Five automations worth building

• Custom importer: parse a CSV from a bank, brokerage or payroll system the app cannot connect to, normalise dates and signs, and create transactions. Use a stable external ID or memo so reruns do not duplicate.
• Weekly digest: fetch last week's transactions and category balances and email yourself the five largest variances. With YNAB, store server_knowledge between runs.
• Subscription audit: pull a year of transactions, group by payee, and flag payees that charge on a regular cadence.
• Scheduled backup: export everything to JSON once a week and keep dated copies outside the app.
• Net worth snapshot: on the last day of each month, record balances into your own sheet or database so history survives an app switch.

Security rules for your scripts

• Store tokens in environment variables or a secrets manager, never in code or a shared repository.
• Use the narrowest access available: YNAB's read-only scope or Monarch's default read-only MCP access for reporting tools.
• Create one token per script with a clear label, so you can revoke one without breaking the rest.
• Back off on HTTP 429 using the Retry-After header rather than retrying immediately.
• Test against Lunch Money's mock server or a throwaway budget before writing to real data.