Skip to main content

Changelog

v2.10.0​

New Features​

  • Invoice filtering — GET /invoices now accepts optional query parameters to narrow down results:
    • invoiceNumber — filter by exact invoice number. Repeatable, up to 100 values per request.
    • invoiceStatus — filter by invoice status (e.g. OPEN, PAID). Repeatable. Filtering by OPEN also returns invoices undergoing a correction, which are themselves reported with invoiceStatus: OPEN.
    • source — filter by invoice source (see below). Repeatable.
    • categoryId — filter by category. Repeatable, up to 100 values per request.
    • contactName — filter by exact contact name (case insensitive).
  • Invoice source — invoices now include a source field that identifies how the invoice was created: synced from an ERP integration (e.g. LEXOFFICE, SEVDESK, DATEV), created manually (TIDELY), uploaded or imported (TIDELY_CSV, TIDELY_DATEV), or created through this API (OPEN_API). See the InvoiceSource schema for the full list of values.

v2.9.0​

New Features​

  • Down payment invoice reading — invoiceType now includes DOWN_PAYMENT_INVOICE. It's read-only: such invoices can be returned when reading invoices created through an ERP integration, but cannot be used as the invoiceType when creating an invoice via POST /invoices or POST /invoices/bulk — attempting to do so is rejected with 400 INVOICE_TYPE_NOT_CREATABLE (reported per-item in the errors array for bulk creation).

v2.8.0​

New Features​

  • Category filtering by name — GET /categories now accepts an optional name query parameter to filter results by exact name (case insensitive). Category names aren't unique (e.g. across different parents), so a name filter can still return more than one category.

Improvements​

  • Bank account & transaction error codes — documented the full set of error codes returned by the bank account and bank account transaction endpoints, and introduced several new ones for cases that were previously under-specified:
    • Creating or updating a bank account now returns 400 INVALID_COMPANY_ID (companyId doesn't belong to the account) or 403 COMPANY_NOT_ACCESSIBLE (companyId belongs to the account but is outside your permitted company structure) instead of the previous 404 COMPANY_NOT_FOUND.
    • Changing a bank account's accountCurrency on update is rejected with 400 BANK_ACCOUNT_CURRENCY_NOT_MODIFIABLE — the currency cannot be changed after creation.
    • 409 BANK_ACCOUNT_NOT_MODIFIABLE now covers any bank account or transaction managed by a different surface (public vs. partner API), not just partner-managed accounts.
    • Creating a transaction manually on an online (bank-synced) account is rejected with 400 TRANSACTION_CREATION_NOT_ALLOWED.
    • Assigning a parent category (instead of a subcategory) to a transaction is rejected with 400 CATEGORY_NOT_USABLE_FOR_TRANSACTIONS.
  • Bulk transaction creation resilience — clarified that per-transaction validation failures within a bulk create are reported in the response's errors/skipped arrays rather than failing the whole request.
  • bankName nullability — BankAccount.bankName is now explicitly documented as nullable; it may be null (rather than omitted) for accounts synced from an online banking provider.

v2.7.0​

New Features​

  • New invoice statuses — the invoiceStatus type was extended by the values OFFER, ORDER, PLANNED and RELEASED, covering pre-invoice stages (offers, orders, planned invoices) and released invoices. These statuses have no cashflow impact by default. Can be configured in Tidely otherwise.

v2.6.0​

Improvements​

  • Bulk transaction creation — the bulk create response now returns a created array pairing each created transaction's externalId (the submitted one, or a server-generated identifier when none was supplied) with its Tidely transactionId and its index in the request array. The previous transactionIds field (a bare ID list that could not be correlated with the submitted transactions) has been removed; it was never populated.

v2.5.0​

New Features​

  • API bank account provider types — the BankProvider type was extended by the values API and PARTNER. These new types are counted towards the maximum bank account limit of the Tidely account (as opposed to offline accounts). Accounts created via the Public or Partner API now receive the respective types.
  • Bank account conversion — (Public) API accounts can be converted to offline accounts and vice-versa. This function is available in the bank settings in the UI as well as via a new /bank-accounts/{id}/convert endpoint. A bank account can only be converted once every 30 days.

v2.4.0​

New Features​

Public API​

  • Cashflow — new GET /cashflow endpoint returning the cashflow of the authenticated company keyed by period start date (MONTH, WEEK or DAY). Each period bucket contains start/end balances (actual, prognosed, total and plan), sales and purchases totals, amounts per category, aggregated income and expense details, and non-financial KPIs, plus per-period overdraft and liquidity information. All amounts are returned with two decimals. The scenario (scenarioId, defaults to the base forecast) and the date range (from/to, defaulting to 6 periods back and 18 periods ahead, maximum 36 periods) are optional query parameters. Requires the CASHFLOW_READ scope.

v2.3.0​

Improvements​

  • Invoice filtering — GET /invoices now accepts an optional, repeatable externalId query parameter to filter the results by external identifier (up to 100 values per request, to stay within URL length limits).

v2.2.0​

New Features​

Public API​

  • Bank account transaction existence check — a new POST /bank-account-transactions/exists endpoint lets clients check whether transactions with given external IDs already exist for a bank account, useful for deduplication before a bulk create or reconciliation after a resend (up to 1000 external IDs per request).

Improvements​

  • Bulk transaction creation — the bulk create response now reports skippedCount and skipped details for transactions that were skipped because they already existed (matched by externalId).

v2.1.0​

New Features​

Partner API​

  • Subscription information on accounts — the Account object now includes a subscriptionInformation field exposing the full set of subscription limits and feature flags for the account. This covers numeric limits (maxAllowedUsers, maxAllowedBankAccounts, maxAllowedCompanies, etc.), add-on counts (bankAccountAddons, companyAddons, userAddons), the billing period (subscriptionPeriod: MONTHLY, YEARLY, or TWO_YEARS), and boolean feature flags such as consolidationAllowed, aiAnalyticsAllowed, ebicsAllowed, and others.

v2.0.0​

Initial release of API v2. See the Migration Guide (v1 → v2) for upgrade instructions.

Breaking Changes​

  • New base URLs — the URL path structure changed:
    • Public API: https://api.tidely.com/api/v1/open-api → https://api.tidely.com/public/v2
    • All clients must update their base URL to migrate
  • Pagination response format — paginated endpoints now return a consistent structure with the metadata fields number, size, totalElements, and totalPages alongside the data array
  • Invoices — the single unified import endpoint of v1 has been replaced by a full set of CRUD operations. Invoices can now be listed, retrieved, created (individually or in bulk), updated, and deleted independently. Clients relying on the v1 import endpoint must migrate to the new resource-oriented operations

New Features​

The API is now split into a Public API (API-key based, for end users) and a new Partner API (OAuth 2.0, for white-label partners and system integrators operating on behalf of multiple customers via the X-Account-Id header).

Public API​

  • Bank account management — full lifecycle management of bank accounts, including access to their balances
  • Bank account transaction management — full lifecycle management of transactions, with bulk creation support
  • Company access — read-only access to company data
  • Bulk operations — bulk creation for invoices and bank account transactions

Partner API​

  • Account and user provisioning — partners can create and manage Tidely Accounts (the end customers they serve) as well as the Users within those accounts, enabling fully programmatic onboarding
  • Multi-customer operation — operate on behalf of any managed customer by selecting the target account via the X-Account-Id header
  • Embedded integration — obtain short-lived init tokens that log a user directly into the embedded Tidely frontend without a login screen
  • Full Public API surface — the Partner API also exposes the same financial planning, invoice, bank account, and transaction capabilities as the Public API, scoped per customer account

Improvements​

  • Error responses — improved, consistent error format with a causes field listing individual validation errors and failure reasons

v1 Status​

v1 is now deprecated but remains operational with security patches and bugfixes. End of life has not been scheduled; at least 6 months notice will be given. The v1 documentation remains available at https://api.tidely.com/tidely-open-api/swagger-ui/index.html.