> ## Documentation Index
> Fetch the complete documentation index at: https://www.finta.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Update transaction

> Updates one or more dashboard-editable fields. Send any non-empty subset of
`merchant`, `category_id`, `department_id`, `accounting_date`, and `spread`.

All requested fields are applied atomically in a stable server-defined order;
JSON object key order has no effect. If any change fails, none are applied.

Set `department_id`, `accounting_date`, or `spread` to null to remove the
assignment, accounting-date override, or spread. Accounting-date removal
restores the transaction date. A resulting accounting date cannot precede
the company's incorporation date. When that date is unavailable, the lower
bound is two years before the server's current date. The date must also be
earlier than three years after the server's current date. Transaction
eligibility rules still apply.




## OpenAPI

````yaml /openapi.yaml patch /transactions/{id}
openapi: 3.0.3
info:
  title: Finta API
  version: '1.0'
  description: >
    The Finta API provides programmatic access to your company's financial data,

    including transactions, journal entries, categories, financial reports, and
    the team directory.


    ## Authentication


    Each API key is scoped to a single company. There is no company ID
    parameter.

    The key already knows which company it belongs to. If you have access to
    multiple

    companies, create a separate key for each.


    A key acts as its owner; it does not have a separate permission snapshot.
    The owner

    must currently have **API access: Manage**, plus the permission required by
    the endpoint:


    | Endpoint | Required permission |

    |----------|---------------------|

    | `GET /company` | Company: View |

    | `GET /team` | Team & access: View |

    | `DELETE /team/invitations/{id}` | Team & access: Manage; target-management
    limits apply. No additional Growth/RBAC gate. |

    | `POST /team/invitations/{id}/resend` | Team & access: Manage;
    target-management limits apply. No additional Growth/RBAC gate. |

    | `PATCH /team/invitations/{id}` | Team & access: Manage; RBAC and
    active/trialing Growth required, with grant and target limits. |

    | `POST /team/invitations` | Team & access: Manage; requested grants must
    also be allowed for the person and plan. |

    | `GET /categories`, `GET /departments` | Accounting setup: View |

    | `GET /integrations` | Integrations: View |

    | `GET /reports/*` | Reports: View |

    | `GET /transactions`, `GET /transactions/{id}` | Transactions: View |

    | `PATCH /transactions/{id}` | Transactions: Manage |

    | `GET /journal_entries`, `GET /aggregations/total`, `GET
    /parties/merchants` | Reports: View |


    Permission changes apply to the next request. Removing API access
    permanently revokes

    the owner's active keys for that company; restoring access requires creating
    a new key.


    Authenticate by including your API key in the `Authorization` header:


    ```

    Authorization: Bearer finta_...

    ```


    ### Key prefix convention


    Every Finta credential is prefixed so it can be recognized at a glance in
    logs, error messages, and secret scanners. Today there is one credential
    type and its prefix is `finta_`. As additional credential or token types are
    introduced (for example restricted keys or webhook signing secrets), each
    will have its own distinct prefix that stacks on the brand prefix (e.g.
    `finta_<type>_...`). Treat the prefix as load-bearing: do not strip it
    before sending, and do not assume a missing or unknown prefix is still a
    Finta credential.


    ## Rate Limits


    The API enforces two independent limits. Both surface as `429 Too Many
    Requests`, but they are distinct error codes with different retry guidance.


    ### Per-minute burst limit


    Authenticated requests are limited to **6,000 requests per 60 seconds** (100
    per second) per API key. Unauthenticated requests (missing or invalid key)
    are limited to **120 requests per 60 seconds** per IP address.


    The window is **fixed**, not rolling. Each 60-second wall-clock interval is
    its own counter; all requests within that interval share it, and the counter
    resets to 0 in a single step at the next boundary. Available budget jumps
    from `0` back to the full bucket size (`6000` for authenticated API keys,
    `120` for unauthenticated IP buckets) instantaneously at the boundary,
    rather than aging out one slot at a time. Trust `X-RateLimit-Reset` for the
    exact reset timestamp.


    Successful responses and burst-limit rejections include the following
    headers.

    Do not assume they are present on other errors: early authentication,
    authorization,

    and monthly-limit rejections can omit them. This describes existing header
    behavior,

    not a new quota policy.


    | Header | Description |

    |--------|-------------|

    | `X-RateLimit-Limit` | Maximum requests per window (`6000` for
    authenticated requests, `120` for unauthenticated). |

    | `X-RateLimit-Remaining` | Requests remaining in the current window. |

    | `X-RateLimit-Reset` | Unix timestamp when the window resets. |


    On a 429 for this case, an additional header is included:


    | Header | Description |

    |--------|-------------|

    | `Retry-After` | Number of seconds until the next request is safe. |


    The error body is `type: rate_limit_error` / `code: rate_limit_exceeded`.


    **Retry guidance:** This case is retryable. Honor `Retry-After` as the
    minimum wait, then apply exponential backoff with jitter for any retries
    beyond the first (cap at a few minutes; abandon after a small number of
    attempts to avoid retry storms). Do not retry tighter than `Retry-After`.


    ### Monthly per-company limit


    Each company has a monthly cap on total API calls, independent of the
    per-minute burst:


    | Plan | Monthly cap |

    |------|-------------|

    | Formation | 10 |

    | Startup | 300 |

    | Growth | 30,000 |


    Counts reset at **midnight Pacific Time (US & Canada)** on the 1st of each
    month. This is the Finta application's configured time zone; the cap is
    computed in that zone, not in UTC. Consumers in other time zones should
    convert the local-midnight Pacific boundary to their own clock; note that
    the absolute UTC offset shifts by one hour twice a year for daylight saving
    (PST is UTC-8, PDT is UTC-7). Blocked requests are not counted toward the
    limit. The error body is `type: limit_error` / `code:
    monthly_limit_exceeded`, and the `message` field includes the reset date in
    human-readable form.


    **Retry guidance:** This case is **not retryable in the short term.** No
    `Retry-After` header is sent, deliberately, because the only meaningful
    remediation is to upgrade the plan (Settings -> Plans at app.finta.com) or
    wait until the 1st of the next month. Naive retry loops should branch on
    `error.code` and stop retrying when they see `monthly_limit_exceeded`. SDKs
    that auto-retry on 429 should look at `error.code` (or the absence of
    `Retry-After`) before re-issuing.


    Existing temporary user/company limit overrides may change the allowance and
    wording

    of the monthly-limit message. The error code and no-short-term-retry rule
    remain unchanged.


    ## Pagination


    List endpoints use cursor-based pagination. Pass `limit` to control page
    size

    (default 100, max 500). To fetch the next page, pass `starting_after` with
    the

    `next_cursor` value from the previous response. Responses include `object:
    "list"`,

    `url` (the canonical path of the collection, relative to the API host),
    `has_more`

    (whether more results exist), `next_cursor` (an opaque value to pass
    unchanged as `starting_after`),

    and `data` (the page of items).


    ## Amounts


    Every monetary field in the API follows two non-negotiable rules:


    1. **Integer cents.** Monetary values are integers, never floats and never
    formatted strings. `$499.00` is `49900`. `$1,500.00` is `150000`. Divide by
    100 to get dollars. This avoids floating-point precision errors in financial
    calculations.

    2. **`_cents` suffix.** The field name always ends in `_cents` (e.g.
    `amount_cents`, `balance_cents`, `total_cents`, `net_income_cents`,
    `change_in_cash_cents`, `cash_cents`). If a field name does not end in
    `_cents`, it is not a monetary value.


    These rules apply to every monetary field across every endpoint
    (transactions, journal entries, income statement, balance sheet, cash flow).
    There are no exceptions and there is no "summary" or "display" sibling field
    that returns the same amount in dollars or as a string. If you encounter a
    field that appears to hold a monetary value but does not end in `_cents`, or
    whose value is not an integer, treat it as a bug and report it.


    Sign conventions:


    - **Income statement**: revenue/income amounts are positive, expense amounts
    are negative. Summing every section's `total_cents` yields net income
    without sign-flipping.

    - **Balance sheet**: `balance_cents` carries the natural-sign cumulative
    balance for that account at the report date.

    - **Cash flow**: `amount_cents` is positive for cash inflows and negative
    for cash outflows.


    ## Errors


    Errors return a consistent JSON structure:


    ```json

    {
      "error": {
        "type": "invalid_request_error",
        "code": "resource_missing",
        "message": "The requested resource was not found.",
        "doc_url": "https://www.finta.com/docs/api-reference/errors#resource_missing"
      }
    }

    ```


    ### Status codes


    | Status | Meaning |

    |--------|---------|

    | `200 OK` | Request succeeded. |

    | `201 Created` | A new invitation was created. |

    | `400 Bad Request` | Request was malformed or had invalid parameters. |

    | `401 Unauthorized` | The bearer credential is missing, malformed, or
    unrecognized. The fix is to obtain a valid API key. |

    | `403 Forbidden` | The API key is valid, but the caller does not have
    permission to access the resource. The fix is to regain the required company
    or product-area access. See the `Forbidden` response component for the
    specific codes. |

    | `404 Not Found` | The requested resource, or the endpoint itself, does not
    exist. Unknown or renamed paths (for example an old hyphenated report path
    like `/reports/income-statement` instead of `/reports/income_statement`)
    return this same envelope with `type: invalid_request_error` and `code:
    resource_missing`, as JSON, regardless of the `Accept` header. |

    | `422 Unprocessable Entity` | Invitation data failed validation, for
    example an invalid email or a conflicting invitation or existing teammate. |

    | `429 Too Many Requests` | Either the per-minute burst rate limit
    (retryable, with `Retry-After`) or the monthly per-company API call limit
    (not retryable in the short term, no `Retry-After`). Branch on `error.code`
    to distinguish the two and avoid retry storms on monthly exhaustion. See the
    Rate Limits section for the full retry guidance. |

    | `5xx` | An unexpected error on Finta's side. Retry with exponential
    backoff. |


    The `error.type` and `error.code` fields are stable identifiers safe to
    switch on programmatically. The `error.message` is human-readable and may
    change without notice.
servers:
  - url: https://app.finta.com/api/v1
    description: Production
security:
  - bearerAuth: []
tags:
  - name: Company
    description: Retrieve company metadata
  - name: Team
    description: Retrieve company members and manage invitations
  - name: Categories
    description: List your chart of accounts categories
  - name: Departments
    description: List the departments available to the authenticated company
  - name: Integrations
    description: List the authenticated company's integrations and their connection status
  - name: Aggregations
    description: Compute a single figure for one category and its descendants
  - name: Transactions
    description: >
      Transactions are what your bank shows you: a single line like "AWS charged
      you $499."

      Most API consumers want transactions. For accounting-level detail, see
      Journal Entries.


      Amounts are in cents (e.g. `amount_cents: 49900` = $499.00).
  - name: Journal Entries
    description: >
      Journal entries are the accounting records that transactions create. A
      single $499 AWS

      charge becomes two journal entries: debit Software $499, credit Cash $499
      (double-entry

      bookkeeping). Use journal entries when you need accounting-level detail.


      Amounts are in cents (e.g. `amount_cents: 49900` = $499.00).
  - name: Parties
    description: Discover observed counterparties for category-scoped financial queries.
  - name: Reports
    description: >
      Financial statements: income statement, balance sheet, and cash flow. Each
      report

      returns the complete statement for a single period. You cannot filter to
      one category

      or request multiple periods in one call.
paths:
  /transactions/{id}:
    patch:
      tags:
        - Transactions
      summary: Update transaction
      description: >
        Updates one or more dashboard-editable fields. Send any non-empty subset
        of

        `merchant`, `category_id`, `department_id`, `accounting_date`, and
        `spread`.


        All requested fields are applied atomically in a stable server-defined
        order;

        JSON object key order has no effect. If any change fails, none are
        applied.


        Set `department_id`, `accounting_date`, or `spread` to null to remove
        the

        assignment, accounting-date override, or spread. Accounting-date removal

        restores the transaction date. A resulting accounting date cannot
        precede

        the company's incorporation date. When that date is unavailable, the
        lower

        bound is two years before the server's current date. The date must also
        be

        earlier than three years after the server's current date. Transaction

        eligibility rules still apply.
      operationId: updateTransaction
      parameters:
        - $ref: '#/components/parameters/TransactionId'
      requestBody:
        required: true
        content:
          application/json:
            schema:
              type: object
              minProperties: 1
              additionalProperties: false
              properties:
                merchant:
                  type: string
                  minLength: 1
                  description: New merchant or payee name.
                  example: Amazon Web Services
                category_id:
                  type: string
                  description: Selectable category ID with `cat_` prefix.
                  pattern: ^cat_
                  example: cat_v5e6f7g8h9i0j1
                department_id:
                  type: string
                  nullable: true
                  description: >-
                    Assignable department ID with `dept_` prefix, or null to
                    remove the department.
                  pattern: ^dept_
                  example: dept_d4e5f6g7h8i9j0
                accounting_date:
                  type: string
                  format: date
                  nullable: true
                  description: >
                    Accounting date override, or null to restore the transaction
                    date. The resulting

                    date must be on or after the company's incorporation date,
                    falling back to two years

                    before the server's current date when incorporation date is
                    unavailable. It must be

                    earlier than three years after the server's current date.
                  example: '2026-02-28'
                spread:
                  type: integer
                  minimum: 1
                  nullable: true
                  description: >-
                    Number of months to spread the transaction over, or null to
                    remove its spread.
                  example: 12
            example:
              merchant: Amazon Web Services
              accounting_date: '2026-02-28'
      responses:
        '200':
          description: The updated transaction
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Transaction'
              example:
                id: txn_a1b2c3d4e5f6g7
                object: transaction
                date: '2026-02-15'
                accounting_date: '2026-02-15'
                amount_cents: -49900
                currency: USD
                merchant: AWS
                description: null
                categorized: true
                category_id: cat_v5e6f7g8h9i0j1
                category_name: Software
                department_id: dept_d4e5f6g7h8i9j0
                department_name: Engineering
                transaction_type: standard
                source:
                  vendor: mercury
                  type: bank
                  account_name: Mercury Checking
                status: approved
                spread: null
                transfer_id: null
                created: 1771183600
        '400':
          description: >-
            The request contains no supported fields, an unknown field, or an
            invalid field value
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Error'
              example:
                error:
                  type: invalid_request_error
                  code: parameter_missing
                  message: >-
                    Provide at least one of: merchant, category id, department
                    id, accounting date, and spread.
                  doc_url: >-
                    https://www.finta.com/docs/api-reference/errors#parameter_missing
        '401':
          $ref: '#/components/responses/Unauthorized'
        '403':
          $ref: '#/components/responses/Forbidden'
        '404':
          description: >-
            The transaction, category, or department was not found, was
            unavailable through the API, or had the wrong ID prefix
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Error'
              examples:
                invalid_transaction_id:
                  summary: Transaction ID has the wrong prefix
                  value:
                    error:
                      type: invalid_request_error
                      code: resource_missing
                      message: id must be a transaction ID starting with txn_.
                      doc_url: >-
                        https://www.finta.com/docs/api-reference/errors#resource_missing
                      param: id
                transaction_missing:
                  summary: Transaction not found
                  value:
                    error:
                      type: invalid_request_error
                      code: resource_missing
                      message: No transaction found for id.
                      doc_url: >-
                        https://www.finta.com/docs/api-reference/errors#resource_missing
                      param: id
                invalid_category_id:
                  summary: Category ID has the wrong prefix
                  value:
                    error:
                      type: invalid_request_error
                      code: resource_missing
                      message: category_id must be a category ID starting with cat_.
                      doc_url: >-
                        https://www.finta.com/docs/api-reference/errors#resource_missing
                      param: category_id
                category_missing:
                  summary: Category is missing or not available to the company
                  value:
                    error:
                      type: invalid_request_error
                      code: resource_missing
                      message: No category found for category_id.
                      doc_url: >-
                        https://www.finta.com/docs/api-reference/errors#resource_missing
                      param: category_id
                invalid_department_id:
                  summary: Department ID has the wrong prefix
                  value:
                    error:
                      type: invalid_request_error
                      code: resource_missing
                      message: >-
                        department_id must be a department ID starting with
                        dept_.
                      doc_url: >-
                        https://www.finta.com/docs/api-reference/errors#resource_missing
                      param: department_id
                unsupported_category_change:
                  summary: The transaction cannot be categorized through this endpoint
                  value:
                    error:
                      type: invalid_request_error
                      code: resource_missing
                      message: >-
                        The requested transaction cannot be categorized through
                        this endpoint.
                      doc_url: >-
                        https://www.finta.com/docs/api-reference/errors#resource_missing
                      param: id
        '422':
          description: >-
            A requested change was rejected by bookkeeping eligibility or
            validation rules; no fields were updated
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Error'
              examples:
                ineligible_transaction:
                  summary: The transaction does not support accounting-date edits
                  value:
                    error:
                      type: invalid_request_error
                      code: transaction_update_failed
                      message: >-
                        Accounting date can't be changed for transfer
                        transactions.
                      doc_url: >-
                        https://www.finta.com/docs/api-reference/errors#transaction_update_failed
                      param: accounting_date
                accounting_date_out_of_bounds:
                  summary: >-
                    The accounting date precedes the company's incorporation
                    date
                  value:
                    error:
                      type: invalid_request_error
                      code: transaction_update_failed
                      message: >-
                        Accounting date can't be before the company's
                        incorporation date (03/15/2024)
                      doc_url: >-
                        https://www.finta.com/docs/api-reference/errors#transaction_update_failed
                      param: accounting_date
        '429':
          $ref: '#/components/responses/RateLimited'
components:
  parameters:
    TransactionId:
      name: id
      in: path
      required: true
      description: Transaction ID with `txn_` prefix.
      schema:
        type: string
        pattern: ^txn_
      example: txn_a1b2c3d4e5f6g7
  schemas:
    Transaction:
      type: object
      required:
        - id
        - object
        - date
        - accounting_date
        - amount_cents
        - currency
        - categorized
        - department_id
        - department_name
        - transaction_type
        - source
        - status
        - created
      properties:
        id:
          type: string
          description: Unique identifier with `txn_` prefix.
          example: txn_abc123
        object:
          type: string
          enum:
            - transaction
        date:
          type: string
          format: date
          description: Transaction date.
          example: '2026-02-15'
        accounting_date:
          type: string
          format: date
          nullable: true
          description: >-
            Date used for accounting and financial reports. Defaults to `date`
            unless overridden.
          example: '2026-02-15'
        amount_cents:
          type: integer
          description: >-
            Transaction amount in cents. Positive for income, negative for
            expenses. Divide by 100 to get the dollar amount.
          example: -49900
        currency:
          type: string
          description: ISO 4217 currency code.
          example: USD
        merchant:
          type: string
          nullable: true
          description: Merchant or payee name.
          example: AWS
        description:
          type: string
          nullable: true
          description: >-
            Description provided by the bank or payment processor. Null when not
            available.
          example: null
        categorized:
          type: boolean
          description: >-
            Whether the transaction has been categorized. False when assigned to
            Uncategorized Income or Uncategorized Expenses. Note that
            `category_id` is still present for uncategorized transactions.
        category_id:
          type: string
          nullable: true
          description: Prefixed ID of the assigned category.
          example: cat_v5e6f7g8h9i0j1
        category_name:
          type: string
          nullable: true
          description: Name of the assigned category.
          example: Software
        department_id:
          type: string
          nullable: true
          description: Prefixed ID of the assigned department.
          example: dept_d4e5f6g7h8i9j0
        department_name:
          type: string
          nullable: true
          description: Name of the assigned department.
          example: Engineering
        transaction_type:
          type: string
          enum:
            - standard
            - transfer
            - split
          description: >-
            Type of transaction: `standard` (normal), `transfer` (matched
            transfer between accounts), or `split` (parent of split children).
        source:
          type: object
          description: Where the transaction originated.
          properties:
            vendor:
              type: string
              description: >-
                Integration or vendor name (e.g. `mercury`, `brex`, `stripe`,
                `ramp`).
              example: mercury
            type:
              type: string
              nullable: true
              description: Source account type.
              enum:
                - bank
                - credit
                - reimbursement
              example: bank
            account_name:
              type: string
              nullable: true
              description: Display name of the source account.
              example: Mercury Checking
        status:
          type: string
          enum:
            - approved
            - pending
          description: Approval status of the transaction.
        spread:
          type: integer
          nullable: true
          description: >-
            Number of months this transaction is spread over, or null if not
            spread.
          example: null
        transfer_id:
          type: string
          nullable: true
          description: Prefixed ID of the associated transfer, or null if not a transfer.
          example: null
        created:
          type: integer
          description: Unix timestamp of when the transaction was created.
          example: 1771183600
    Error:
      type: object
      required:
        - error
      properties:
        error:
          type: object
          required:
            - type
            - code
            - message
            - doc_url
          properties:
            type:
              type: string
              enum:
                - authentication_error
                - permission_error
                - invalid_request_error
                - rate_limit_error
                - limit_error
                - api_error
              description: >-
                The error category. `authentication_error` (401) means the
                bearer credential was missing, malformed, or unrecognized.
                `permission_error` (403) means the credential was valid but the
                caller is not allowed to access the resource.
                `invalid_request_error` covers invalid parameters, unavailable
                resources, and invitation validation failures.
                `rate_limit_error` is for per-minute burst limits (retry
                shortly). `limit_error` is for monthly API call limits per
                company (upgrade or wait for reset). `api_error` denotes an
                operation failure on the server (500); retry the same invitation
                body with exponential backoff.
            code:
              type: string
              enum:
                - invalid_api_key
                - user_inactive
                - user_removed_from_company
                - company_closed
                - subscription_required
                - staging_access_denied
                - insufficient_permission
                - resource_missing
                - parameter_missing
                - category_update_failed
                - transaction_update_failed
                - rate_limit_exceeded
                - monthly_limit_exceeded
                - invalid_date_range
                - invalid_date
                - invalid_request
                - plan_upgrade_required
                - feature_disabled
                - invitation_invalid
                - invitation_create_failed
                - permissions_update_failed
                - invitation_resend_failed
                - invitation_revoke_failed
              description: A specific error code.
            message:
              type: string
              description: A human-readable description of the error.
            doc_url:
              type: string
              format: uri
              description: A link to documentation about this error.
              example: https://www.finta.com/docs/api-reference/errors#invalid_api_key
            param:
              type: string
              nullable: true
              description: The parameter that caused the error, if applicable.
  responses:
    Unauthorized:
      description: >-
        Authentication failed. Returned when the bearer credential itself is
        missing, malformed, or unrecognized. The consumer should obtain a valid
        API key and retry. This is distinct from `403 Forbidden`, which is
        returned when the credential is valid but the caller is not allowed to
        access the resource.
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/Error'
          example:
            error:
              type: authentication_error
              code: invalid_api_key
              message: >-
                Invalid API key provided. Check that your API key is correct and
                active.
              doc_url: https://www.finta.com/docs/api-reference/errors#invalid_api_key
    Forbidden:
      description: >-
        The API key was successfully authenticated, but the caller is not
        allowed to access this resource. The fix is not "get a new key" (that
        returns 401) but "regain access" (reactivate the user, restore company
        access, restore an active subscription, or ask an administrator for the
        required product permission). These codes can be returned, distinguished
        by `error.code`:
          - `user_inactive` - the user that owns the API key has been deactivated.
          - `user_removed_from_company` - the user no longer has access to the company the key was created for.
          - `company_closed` - the company is closed, closing, or deleted.
          - `subscription_required` - the company does not have an active subscription.
          - `staging_access_denied` - the staging environment is restricted to Finta users.
          - `insufficient_permission` - the key owner lacks API access or the endpoint's required area permission.
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/Error'
          examples:
            user_inactive:
              summary: User has been deactivated
              value:
                error:
                  type: permission_error
                  code: user_inactive
                  message: >-
                    The user associated with this API key is no longer active.
                    Reactivate the user or create a new API key under an active
                    user.
                  doc_url: >-
                    https://www.finta.com/docs/api-reference/errors#user_inactive
            user_removed_from_company:
              summary: User no longer has access to this company
              value:
                error:
                  type: permission_error
                  code: user_removed_from_company
                  message: >-
                    The user associated with this API key no longer has access
                    to this company. Ask a company admin to re-grant access,
                    then create a new API key.
                  doc_url: >-
                    https://www.finta.com/docs/api-reference/errors#user_removed_from_company
            company_closed:
              summary: Company is closed
              value:
                error:
                  type: permission_error
                  code: company_closed
                  message: >-
                    This company is closed. The API is not available for closed
                    companies.
                  doc_url: >-
                    https://www.finta.com/docs/api-reference/errors#company_closed
            subscription_required:
              summary: Company subscription is not active
              value:
                error:
                  type: permission_error
                  code: subscription_required
                  message: >-
                    This company does not have an active subscription. Visit
                    Settings -> Plans at app.finta.com to resolve, then retry.
                  doc_url: >-
                    https://www.finta.com/docs/api-reference/errors#subscription_required
            staging_access_denied:
              summary: Staging access is restricted
              value:
                error:
                  type: permission_error
                  code: staging_access_denied
                  message: This staging environment is restricted to Finta users.
                  doc_url: >-
                    https://www.finta.com/docs/api-reference/errors#staging_access_denied
            insufficient_permission:
              summary: Key owner lacks the required product permission
              value:
                error:
                  type: permission_error
                  code: insufficient_permission
                  message: >-
                    The API key owner needs the Transactions: View permission to
                    use this endpoint.
                  doc_url: >-
                    https://www.finta.com/docs/api-reference/errors#insufficient_permission
    RateLimited:
      description: >-
        Too many requests. Two distinct limits can trigger a 429: (1) Per-minute
        burst limit (6,000 requests per 60 seconds per API key) returns
        `rate_limit_error` / `rate_limit_exceeded` with `Retry-After` header.
        (2) Monthly API call limit per company returns `limit_error` /
        `monthly_limit_exceeded` with the reset date in the message. Monthly
        limits vary by plan: Formation (10/month), Startup (300/month), Growth
        (30,000/month). Blocked requests do not count toward the limit.
      headers:
        Retry-After:
          schema:
            type: integer
          description: >-
            Seconds until the burst rate limit resets. Only present for
            rate_limit_error responses.
        X-RateLimit-Limit:
          schema:
            type: integer
          description: >-
            Maximum requests per burst window. Only present for rate_limit_error
            responses.
        X-RateLimit-Remaining:
          schema:
            type: integer
          description: >-
            Requests remaining in burst window (0 when rate limited). Only
            present for rate_limit_error responses.
        X-RateLimit-Reset:
          schema:
            type: integer
          description: >-
            Unix timestamp when the burst window resets. Only present for
            rate_limit_error responses.
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/Error'
          examples:
            burst_rate_limit:
              summary: Per-minute burst rate limit exceeded
              value:
                error:
                  type: rate_limit_error
                  code: rate_limit_exceeded
                  message: >-
                    Too many requests. Please retry after the Retry-After
                    period.
                  doc_url: >-
                    https://www.finta.com/docs/api-reference/errors#rate_limit_exceeded
            monthly_limit:
              summary: Monthly API call limit exceeded
              value:
                error:
                  type: limit_error
                  code: monthly_limit_exceeded
                  message: >-
                    Monthly API limit reached. Your plan allows 300 calls per
                    company per month. Resets on April 1, 2026. Upgrade in
                    Settings -> Plans at app.finta.com.
                  doc_url: >-
                    https://www.finta.com/docs/api-reference/errors#monthly_limit_exceeded
  securitySchemes:
    bearerAuth:
      type: http
      scheme: bearer
      description: API key prefixed with `finta_`

````