Public API changelog

All notable changes to the QUiCK Public API (/1/ and /2/ endpoints) are documented here.

2026-10-14

• PATCH /2/expenses/{id}/update/ and PATCH /2/incomes/{id}/update/ now keep the automatically generated payment in line with the record after every update, the same way as QUiCK itself does. Previously these endpoints saved payment_method without touching the payments: an invoice switched to cash stayed unpaid, and one switched back to transfer kept its old automatic payment.
• cash and card create the automatic payment, or update it to the current amount, account and date; transfer and cod remove it. A card payment needs paid_through. A cash payment is always booked to the company's cash account (Házipénztár) in the invoice's currency, which replaces any paid_through sent with it.
• This runs on every update, not only when payment_method changes: an update of any field adds a missing automatic payment, and a change of the amount is carried over to the payment. Incomes synced from Számlázz or Billingo are the exception, see below.
• No automatic payment is added next to a payment recorded by a user or synced from an integration, and an incomplete expense gets none.
• Expenses: on the free plan, a card payment without paid_through is booked to the company's bank account.
• Incomes: the automatic payment is dated by fulfilled_at, so an income without it gets none. A cancelled, storno or zero-amount income has all of its payments, user-recorded ones included, replaced by a single zero-amount payment on every update -- previously only when is_cancelled changed.
• Incomes synced from Számlázz or Billingo get their payments from the sync, so their automatic payment is only brought in line when payment_method, paid_through or exchange_rate changes, and it is recorded without an account, the same way as the sync records it. Any other update, such as setting tags, leaves their payments alone.

2026-10-07

• Error responses from POST /2/incomes/create/, POST /2/partners/create/ and PATCH /2/partners/{partnerId}/update/ now carry an error_code field next to _error. It is a stable machine identifier that is never translated and does not change with ?lang=, so it is the field to branch on -- _error is human-facing text. The duplicate and conflict cases read duplicate_invoice_number and partner_conflict, which is what tells a retry apart from a malformed request; ordinary validation failures read invalid. The rest of the body is unchanged, so this is additive.
• Other endpoints are unaffected for now. The field is being added one endpoint at a time; the API Reference shows which responses already declare it.

2026-09-30

• POST /2/incomes/create/ creates an income as an accounting document (income_type=2) in a single call -- the header, at least one revenue categorization, optional invoice line items and an optional invoice image, all created together in one transaction. Use this to bring in invoices issued through a system of your own -- for example under a foreign entity -- that don't go through an accounting-software or NAV sync.
• Amounts are validated strictly on this endpoint: the revenue categorizations' combined gross amount must match the invoice's gross amount, and each one's net plus VAT must equal its own gross, with no way to opt out.
• exchange_rate defaults to 1 and exchange_date is optional, so an income in the company's default currency needs neither. For any other currency the actual rate is required.
• Every referenced id (partner, revenue type, VAT rate, tags, ledger numbers, VAT category) must belong to the company; an id of another company returns 400.
• Sending an invoice_number that already exists for the company returns 400 with the existing record's id in existing_income_id, so a retried request can tell whether it already went through.
• Automatic revenue-coding only runs for the accounting-software sync -- it does not apply to incomes created through this endpoint. Send the coding directly with the income, or set it afterwards through PATCH /2/incomes/{id}/update/.
• POST /2/incomes/create/ also accepts a storno: send invoice_type 1 with the cancelled document's number in referred_invoice_number. The referred accounting document is set to cancelled and its payments are replaced by a single zero-amount payment. Only accounting documents are matched -- a storno sent here never cancels an invoice synced from invoicing software or NAV. If the storno arrives first, it is accepted and nothing is cancelled; the original sent later is not cancelled retroactively, so send it with is_cancelled: true or set that afterwards. referred_invoice_number now takes up to 64 characters (previously 32).
• PATCH /2/incomes/{id}/update/ accepts is_cancelled on accounting documents that are not processed yet. Changing it recalculates the document's payments: a cancelled document gets a single zero-amount payment.
• New POST /2/partners/create/ and PATCH /2/partners/{partnerId}/update/ endpoints create and update partners (customers and/or vendors). At least one of is_customer/is_vendor must be true.
• Partner data is never merged into or matched against an existing partner by name or tax number. If a create or update would collide with another partner of the company (same tax number, or the same name and address), the request is rejected with a 400 naming the colliding partner's id, rather than being merged into it.
• A partner linked to an integration only accepts default_account_number, default_account_name, is_customer and is_vendor through PATCH /2/partners/{partnerId}/update/; sending any other field is rejected with a 400 naming the offending fields.
• tax_number is normalised before saving, the same way as in QUiCK: dashes are removed from a Hungarian tax number, so 12345678-1-23 is stored and returned as 12345678123. Empty strings are rejected on every text field; send null to clear one.

2026-09-23

• GET /2/currencies/ returns the currency catalogue: the id -> ISO code pairs behind every currency field in expense, income and payment payloads. Previously those ids could not be resolved through the API at all, so integrations had to hard-code a mapping.

2026-09-09

• Published this changelog and a public, unauthenticated API reference page on a dedicated docs domain.
• The 10 /1/ endpoints that have a verified /2/ replacement (expenses list/detail, taxes create/update/delete/list, salaries create/update/delete/list) are now marked deprecated in the OpenAPI schema, pointing at their /2/ replacement.
• The OpenAPI schema's operation tags were consolidated into a documented, one-tag-per-operation vocabulary (e.g. expense-types and revenue-types folded into Expenses/Incomes, ledger numbers / VAT categories / audit XML folded into Accounting) -- if you generate an SDK or navigate the docs by tag, section names changed.
• The OpenAPI schema content (description/summary/help text) is now served bilingually: Hungarian by default, ?lang=en for English. operationIds, tag names, and schema/property names are unaffected -- still plain English identifiers.
• POST /2/expenses/create/ now validates that uploaded content actually matches a supported file type, regardless of the declared filename extension -- content that isn't a real PDF/JPEG/PNG/XML now returns 400 instead of being silently accepted.

2026-08-26

• PATCH /2/company-info/update/{company_id}/ accepts a new income_policies field, and GET /2/company-info/ (and the update response) now returns it -- previously only editable as raw JSON in Django admin.

  • Validation only checks that the submitted JSON is structurally and semantically processable by the policy engine (an unknown key, wrong type, or unusable combination returns a field-level error). It does not check referential integrity for revenue_type/ledger_number/ tag -- the engine legitimately auto-creates those.
  • Two independent parts share a "v": 2 key: policies (the rule engine that auto-assigns revenue_type, job_number, ledger_number, tag and split rules to incoming invoices) and ignore_policies (import-skip rules).
  • Sending null deletes the existing configuration.

2026-08-12

• GET /2/expenses supports filtering by custom field text search and by amount range.

2026-07-29

• Requests authenticated via OAuth now return 403 if the company requires two-factor authentication and the authenticated user hasn't enabled it.

2026-07-27

• GET /2/expenses supports filtering by updated_since.

  • Returns only expenses modified since the given timestamp -- creation alone doesn't count as a modification; to discover new expenses, keep using date_field=created_at with from_date.
  • ISO 8601 with a timezone offset (e.g. 2026-07-01T12:00:00Z or 2026-07-01T12:00:00+02:00); a value without a timezone is interpreted as UTC.
  • URL-encode the + in a +HH:MM offset (%2B) -- otherwise it decodes as a space in the query string and the request fails with an invalid date format error.
  • Looks back at most 30 days; an older value returns 400, at which point a full resync is required (query without updated_since).
  • Results are ordered by modification time; pagination uses the existing cursor-based pagination.
  • At-least-once semantics: an expense modified mid-page may appear twice, but is never dropped.
  • Deleted expenses simply disappear from the list (no tombstone).

2026-07-15

• Fixed ledger_number being unexpectedly editable on checked or integration-synced expenses; it is now frozen as intended.
• GET /2/expenses and GET /2/expenses/{expense_id}/ now include the id on the ledger_number, vat_ledger_number, and company_vat_category reference objects (previously name/code only), matching the income detail output -- lets you reliably identify the referenced record even when code is null or name isn't unique.

2026-07-08

• PATCH /2/incomes/{income_id}/update/ gained new accounting fields:

  • accounting_id (str, nullable) -- external accounting reference; submit null or an empty string to clear it. Editable only when enable_accounting_id is on for the company and the income hasn't been booked yet.
  • vat_period_type (nullable: monthly, quarterly, yearly)
  • vat_period_started_at (date, nullable) -- any date is accepted and rounded down to the start of its period (e.g. 2026-02-15 + quarterly -> 2026-01-01)
  • vat_period_type and vat_period_started_at must be submitted together (both or neither), otherwise the endpoint errors; submitting both as null clears the VAT period. Editable only when enable_vat_period is on and the income hasn't been booked yet.
  • accounting_period_start and accounting_period_end must be submitted together, and the start date can't be after the end date.

• GET /1/incomes/{income_id}/ gained new fields, returned when fields=accounting is requested: accounting_id, vat_period_type, vat_period_started_at, vat_period_ended_at.

  • Only present in the response when accounting is included in fields.
  • editable_fields reflects these too -- accounting_id, vat_period_type, and vat_period_started_at appear as editable depending on company settings (enable_accounting_id, enable_vat_period) and the income's processing status.

2026-07-01

• New GET /2/revenue-types/ endpoint lists revenue types, sorted case-insensitively by name.

• New POST /2/revenue-types/create/ endpoint creates revenue types.

  • Every created revenue type gets is_external=True, so it won't be auto-deleted.
  • Multiple revenue types can be created in one request; partial success is supported.

• New POST /2/revenue-types/update/ endpoint updates revenue types by id, in bulk, with partial success; sets is_external=True on the updated types.

• New POST /2/revenue-types/delete/ endpoint deletes revenue types by id; an unknown id or one belonging to another company lands in failed_ids instead of failing the whole request.

• PATCH /2/incomes/{income_id}/update/ (new endpoint) supports partial updates to an income.

  • All fields are optional; only submitted fields are changed.
  • Supported income types: invoice (type=1), accounting document (type=2), cash receipt (type=6), collective receipt (type=7).
  • Which fields are editable depends on the income's type and processing status (see editable_fields on the income detail response).
  • Invoice and accounting document: vat_area, due_at, payment_method, planned_payment_date, paid_through, secondary_id, exchange_rate, exchange_date, accounting_period_start, accounting_period_end, tags, simple_tags, assignments, note, needs_review, review_done, ledger_number_id are editable.
  • Accounting document only: invoice_number, net_amount, gross_amount, currency, fulfilled_at, issued_at, partner_id, partner_name, partner_zip_code, partner_city, partner_address, partner_country, partner_tax_number, partner_account_number (ignored on invoices).

  • Cash receipt and collective receipt: invoice_number, net_amount, vat_amount, gross_amount, currency, exchange_rate, exchange_date, fulfilled_at (also sets due_at and issued_at), secondary_id, tags, simple_tags, assignments.

    • A collective receipt coming from an integration only allows secondary_id, tags, simple_tags, and assignments (and within assignments, only revenue_type).

  • List fields (tags, simple_tags): the submitted list replaces the full set.

  • assignments: the submitted list replaces all of the income's assignments.

    • Assignment fields: revenue_type (int), net_amount, vat_amount, gross_amount, vat (VAT category id), tags ([int]), job_number, ledger_number_id, vat_ledger_number_id, company_vat_category_id (the last three only apply under advanced accounting).

  • Response: the same shape as the GET /1/incomes/{income_id}/ detail response.

• GET /1/incomes/{income_id}/ gained a new secondary_id field.

• vat_percent/percent fields changed from integer to float on:

  • GET /1/incomes and GET /1/incomes/{income_id}/: items[].vat_percent
  • GET /1/incomes/{income_id}/: assignments[].vat.percent
  • GET /2/expenses and GET /2/expenses/{expense_id}/: items[].vat_percent
  • GET /2/expenses/{expense_id}/: assignments[].vat.percent
  • Enables correctly handling non-integer VAT rates (e.g. 4.9%).

• Company VAT category endpoints gained a type field (cost or revenue):

  • GET /2/accounting/vat-categories/ returns type (read-only).

  • POST /2/accounting/vat-categories/create/ accepts an optional type, defaulting to cost.

    • created_vat_categories in the response now returns the full VAT category (id, name, percent, vat_area, country, type) instead of the previous ledger-number-like shape.

  • POST /2/accounting/vat-categories/update/{vat_category_id}/ accepts an optional type.

• GET /1/incomes/{income_id}/ gained a new editable_fields field -- lists which fields (income- and assignment-level) can be edited, depending on the income's source/type and processing status.

2026-06-25

• GET /2/monthly-taxes/ (with fields=taxes) per-tax items gained source (manual, or an integration label such as navm2m) and description.
• GET /2/monthly-taxes/ supports filtering by ?source=; an unrecognized value returns 400.
• POST /2/taxes/update/ on a tax synced from an integration now ignores changes to every field except tags (previously any field could be submitted, with unclear effect on the synced data).

2026-06-24

• New GET /2/expense-types/ endpoint lists expense types, sorted case-insensitively by name.

• New POST /2/expense-types/create/ endpoint creates expense types.

  • Every created expense type gets is_external=True, so it won't be auto-deleted.
  • Multiple expense types can be created in one request; partial success is supported (one invalid item, e.g. a duplicate name, doesn't block the rest).

• New POST /2/expense-types/update/ endpoint updates expense types by id, in bulk, with partial success; sets is_external=True on the updated types.

• New POST /2/expense-types/delete/ endpoint deletes expense types by id; an unknown id or one belonging to another company lands in failed_ids instead of failing the whole request.

2026-04-01

• GET /2/expenses/{expense_id}/ gained a new editable_fields field -- lists which fields can be edited on the expense, depending on its source and processing status.

• PATCH /2/expenses/{expense_id}/update/ editable-field coverage expanded: every field listed in the detail response's editable_fields is now editable, on both the expense and its assignments.

  • List fields (tags, simple_tags):

    • An empty list clears every existing value on the expense.
    • A non-empty list: values already on the expense that also appear in the list are left alone; values in the list but not yet on the expense are added; values on the expense but not in the list are removed.

  • Assignments follow the same add/remove logic:

    • An assignment submitted with an id is edited with the submitted values.
    • An assignment submitted without an id is added.
    • An assignment on the expense but not included in the request is removed.
    • assignments itself stays optional, but if submitted it must contain at least one item -- an empty list is rejected.

2026-03-11

• GET /1/artifacts/expense/ and GET /1/artifacts/income/ gained filename and extension fields -- only present when has_artifact is true.

• PATCH /2/expenses/{expense_id}/update/ can set secondary_id and excluded_from_accounting on an expense.

  • secondary_id: str
  • excluded_from_accounting: bool -- this is an action; submitting true creates an action object.
  • Submitting excluded_from_accounting=true for an expense that's already excluded returns an error.

• New GET /2/monthly-taxes/ endpoint lists a company's taxes grouped by month.

  • Filters: to_date, from_date, is_paid, is_installment.
  • fields=taxes includes per-tax detail (and a tags list) under each month; omitted, only the monthly totals are returned.

• New POST /2/taxes/create/ endpoint creates taxes.

  • Always HUF -- currency isn't accepted.
  • Multiple taxes across different months can be created in one call.
  • tags/simple_tags accept tag ids directly on creation.
  • code can't be submitted together with name or account_number.
  • Response: the monthly-tax list response for the created taxes.

• New POST /2/taxes/update/ endpoint updates taxes by id, in bulk. Response: the monthly-tax list response for the updated taxes.

• New POST /2/taxes/delete/ endpoint deletes taxes by id (204 No Content).
• New GET /2/monthly-salaries/, POST /2/salaries/create/, POST /2/salaries/update/, and POST /2/salaries/delete/ endpoints -- same shape as the taxes endpoints above, for salary costs (a given tax_number can only appear once per month).

2026-03-04

• GET /2/expenses and GET /2/expenses/{expense_id} now return artifact_created_at, artifact_filename and artifact_extension when the expense has an artifact (has_artifact is true).
• PATCH /2/company-info/update/{company_id}/ accepts enable_vat_period and enable_accounting_id, letting these company settings be turned on/off through the API.

• Added tag endpoints:

  • GET /2/tags/ -- lists the company's tags, filterable by name and is_external.
  • POST /2/tags/create/ -- creates tags; all API-created tags get is_external: true and are not auto-deleted even if unused.
  • PATCH /2/tags/update/ -- updates tags; also sets is_external: true on the edited tag.
  • POST /2/tags/delete/ -- deletes tags not referenced by any expense/income/etc.; response splits ids into deleted and not_deleted.

2026-01-14

• GET /2/documents now returns attached and unattached documents by default; filter with ?is_attached=true/false.
• GET /2/expenses supports filtering partially paid expenses with ?is_installment=true/false.
• Monthly taxes and monthly salaries endpoints support filtering by paid (?is_paid=true/false) and partially paid (?is_installment=true/false) status.