> ## Documentation Index > Fetch the complete documentation index at: https://docs.fintoro.sk/llms.txt > Use this file to discover all available pages before exploring further. # Create document payment > Creates a new payment for a public document. ### Supported document types Only `invoice`, `proforma`, and `credit-note` are supported. ### Business behavior - The payment is always linked to one document via `documentType` + `documentId`. - The minimal create payload is only `documentType` + `documentId`; all other fields can be omitted and are derived server-side. - If `paymentDate` is omitted, today's date is used. - If `paymentMethodId` is omitted, the payment method from the source document is used. - If `currencyId` is omitted, the currency from the source document is used. - If `amount` is omitted, the current remaining `toBePaid` amount from the source document is used. This shortcut only works when the document still has a non-zero `toBePaid`; otherwise the endpoint returns `422`. - If `amount` is sent explicitly, it can have at most 2 decimal places. - If `amount` is sent explicitly, its magnitude must not exceed the current `toBePaid` and it must keep the same sign, so the payment cannot over-settle the document or move in the opposite direction. - If `currencyRate` is omitted, the system derives it from the final `paymentDate` using the previous day's rate. - If you send `currencyRate` for a currency other than `EUR`, that override value is used as-is. - If the final payment currency is `EUR`, the backend always stores and returns `currencyRate = 1.0`, even when you send a different value. - Creating a payment recalculates the document payment status exactly like the web and mobile flows. - If you later issue a payment receipt invoice for a proforma payment, the payment response may expose it in `receiptInvoice`. If you send an `Idempotency-Key`, the same key with the same payload returns the original response without creating the payment again. ## OpenAPI ````yaml /en/openapi.yaml post /document-payments openapi: 3.1.0 info: title: Fintoro API v1 version: 1.0.0 description: > Fintoro API v1 is a REST API for integrating Fintoro invoicing, CRM, and warehouse workflows into third-party systems. Production and sandbox companies use the same base URL `https://app.fintoro.sk/api/public/v1`. The bearer token decides which company you work with. The optional `Accept-Language` request header localizes system-owned labels in lookups, in related response objects, and in validation errors. The `Content-Language` response header returns the language used in the response. For onboarding and operational guidance, also see: - [Getting started](/en/getting-started) - [Authentication](/en/authentication) - [Webhooks](/en/webhooks) - [Sandbox testing](/en/sandbox-testing) - [API conventions](/en/conventions) - [Errors and idempotency](/en/errors-and-idempotency) servers: - url: https://app.fintoro.sk/api/public/v1 description: Production Fintoro API. security: - bearerAuth: [] tags: - name: Token identity description: >- Technical read-only endpoint that confirms which company the current bearer token belongs to. - name: Lookups description: >- Read-only lookup endpoints for integration data. These endpoints return lookup datasets with stable IDs that are safe to cache on your side. When new lookup values are added, existing IDs do not change or get reassigned. - name: Numerical Series description: >- Read-only endpoints for numerical series. They return the live configuration used when creating documents, including the next generated document number and variable symbol. - name: Subjects description: Look up and verify subject details before creating a client. - name: Clients description: >- Manage clients, including billing address, delivery address, and client-scoped default values that can be reused when building payloads for new documents. Create, update, and delete operations can emit `clients.created`, `clients.updated`, and `clients.deleted` webhook events. - name: Suppliers description: >- Manage suppliers, including billing address and identifier data used by the warehouse inbound resolve-or-create flow. Create, update, and delete operations can emit `suppliers.created`, `suppliers.updated`, and `suppliers.deleted` webhook events. - name: Business Case Statuses description: >- Manage business-case statuses. Statuses represent pipeline columns. In this API version, a reorder endpoint is not available; when a status is deleted, linked business cases are detached to `null`. Create, update, and delete operations can emit `business-case-statuses.created`, `business-case-statuses.updated`, and `business-case-statuses.deleted` webhook events. - name: Business Cases description: >- Manage business cases, including the nested client or supplier and an optional status. Reorder flows and changing the linked contact through update are not available in this API version. Create, update, and delete operations can emit `business-cases.created`, `business-cases.updated`, and `business-cases.deleted` webhook events. - name: CRM Events description: >- Manage CRM events for `note`, `email`, `phone_call`, and `document_linked`. Attachments use a separate two-step upload endpoint. Create, update, and delete operations can emit `contact-activity-logs.created`, `contact-activity-logs.updated`, and `contact-activity-logs.deleted` webhook events. - name: Bank Accounts description: >- Manage bank accounts, including bank details, primary account state, and open banking metadata. Create, update, and delete operations can emit `bank-accounts.created`, `bank-accounts.updated`, and `bank-accounts.deleted` webhook events. - name: Webhooks description: >- Manage outbound webhook subscriptions for Fintoro API. This section covers subscription CRUD, manual secret rotation, and the delivery payload contract for event-driven integrations. The delivery contract, signature verification, retry behavior, and full event catalog are documented in the [Webhooks guide](/en/webhooks). - name: Warehouses description: >- CRUD operations for warehouses, including inbound and outbound numbering series. Create, update, and delete operations can emit `warehouses.created`, `warehouses.updated`, and `warehouses.deleted` webhook events. - name: Warehouse Inbound Receipts description: >- CRUD operations for warehouse inbound receipts, including warehouse detail, supplier snapshot, receipt items, and `pdfDownloadUrl`. Create, update, and delete operations can emit `warehouse-inbound-receipts.created`, `warehouse-inbound-receipts.updated`, and `warehouse-inbound-receipts.deleted` webhook events. - name: Warehouse Outbound Receipts description: >- CRUD operations for warehouse outbound receipts, including warehouse detail, client snapshot, receipt items, and `pdfDownloadUrl`. Create and update use the same stock-availability validation as the web. Create, update, and delete operations can emit `warehouse-outbound-receipts.created`, `warehouse-outbound-receipts.updated`, and `warehouse-outbound-receipts.deleted` webhook events. - name: Price List Items description: >- CRUD operations for price list and warehouse items. These endpoints return the unit as a nested object, support filtering by name, EAN, warehouse code, price, and stock, and expose the same business contract that Fintoro uses for warehouse tracking, EANs, and purchase prices. Create, update, and delete operations can emit `price-list-items.created`, `price-list-items.updated`, and `price-list-items.deleted` webhook events. Stock changes caused by warehouse inbound and outbound receipts can emit the `price-list-items.stock-updated` webhook event. - name: Document Payments description: >- Payment records for public documents. This section covers listing payments of one document, creating a new payment, showing one payment, and deleting it. Supported document types are `invoice`, `proforma`, `credit-note`, `received-invoice`, and `received-receipt`. Create and delete operations can emit `document-payments.created` and `document-payments.deleted` webhook events. When a newly recorded payment makes a supported document fully paid, Fintoro can also emit the matching `*.paid` event for that document resource. - name: Document Emails description: >- Send supported public documents by email. The endpoint uses a single contract around `documentType` + `documentId`, validates document ownership, and supports `invoice`, `proforma`, `order`, `credit-note`, and `quotation`. - name: Invoices description: >- CRUD operations for invoices. Create, update, and delete operations can emit `invoices.created`, `invoices.updated`, and `invoices.deleted` webhook events. When a recorded payment makes the invoice fully paid, Fintoro can also emit `invoices.paid`. - name: Credit Notes description: >- CRUD operations for credit notes. The contract uses camelCase payloads, a full `PUT` update flow, and an explicit link to the original invoice through `invoiceId`. The credit-note client is always derived from the selected source invoice; `clientId` is not part of the request contract, and inline client resolution or create behavior is not supported here. Create, update, and delete operations can emit `credit-notes.created`, `credit-notes.updated`, and `credit-notes.deleted` webhook events. When a recorded payment makes the credit note fully paid, Fintoro can also emit `credit-notes.paid`. - name: Proformas description: >- CRUD operations for proformas. The contract follows the same philosophy as the public invoice API: camelCase payloads, deterministic client resolve/create behavior, create-like defaults, and a full `PUT` update flow with no patch fallback to the previous persisted document state. Create, update, and delete operations can emit `proformas.created`, `proformas.updated`, `proformas.deleted`, and, when a recorded payment makes the document fully paid, `proformas.paid`. - name: Orders description: >- CRUD operations for orders. The contract uses camelCase payloads, deterministic client resolve/create behavior, create-like defaults, and a full `PUT` update flow with no patch fallback to the previous persisted document state. Create, update, and delete operations can emit `orders.created`, `orders.updated`, and `orders.deleted` webhook events. - name: Quotations description: >- CRUD operations for quotations. The contract uses camelCase payloads, deterministic client resolve/create behavior, create-like defaults, and a full `PUT` update flow with no patch fallback to the previous persisted document state. Create, update, and delete operations can emit `quotations.created`, `quotations.updated`, and `quotations.deleted` webhook events. paths: /document-payments: post: tags: - Document Payments summary: Create document payment description: > Creates a new payment for a public document. ### Supported document types Only `invoice`, `proforma`, and `credit-note` are supported. ### Business behavior - The payment is always linked to one document via `documentType` + `documentId`. - The minimal create payload is only `documentType` + `documentId`; all other fields can be omitted and are derived server-side. - If `paymentDate` is omitted, today's date is used. - If `paymentMethodId` is omitted, the payment method from the source document is used. - If `currencyId` is omitted, the currency from the source document is used. - If `amount` is omitted, the current remaining `toBePaid` amount from the source document is used. This shortcut only works when the document still has a non-zero `toBePaid`; otherwise the endpoint returns `422`. - If `amount` is sent explicitly, it can have at most 2 decimal places. - If `amount` is sent explicitly, its magnitude must not exceed the current `toBePaid` and it must keep the same sign, so the payment cannot over-settle the document or move in the opposite direction. - If `currencyRate` is omitted, the system derives it from the final `paymentDate` using the previous day's rate. - If you send `currencyRate` for a currency other than `EUR`, that override value is used as-is. - If the final payment currency is `EUR`, the backend always stores and returns `currencyRate = 1.0`, even when you send a different value. - Creating a payment recalculates the document payment status exactly like the web and mobile flows. - If you later issue a payment receipt invoice for a proforma payment, the payment response may expose it in `receiptInvoice`. If you send an `Idempotency-Key`, the same key with the same payload returns the original response without creating the payment again. operationId: createDocumentPayment parameters: - $ref: '#/components/parameters/IdempotencyKey' requestBody: required: true content: application/json: schema: $ref: '#/components/schemas/DocumentPaymentInput' responses: '201': description: Document payment created. headers: X-Request-Id: $ref: '#/components/headers/XRequestId' Idempotency-Key: description: >- The original idempotency key when it was provided in the request. schema: type: string Idempotency-Status: description: >- `Original` for the first processed request or `Repeated` when the original response is replayed. schema: type: string enum: - Original - Repeated content: application/json: schema: $ref: '#/components/schemas/DocumentPayment' '422': description: >- The request payload failed validation rules or a payment business rule. headers: X-Request-Id: $ref: '#/components/headers/XRequestId' content: application/json: schema: type: object properties: message: type: string example: The given data was invalid. error: type: - string - 'null' example: Idempotency-Key reused with different request payload errors: type: - object - 'null' additionalProperties: type: array items: type: string '429': $ref: '#/components/responses/TooManyRequests' '500': $ref: '#/components/responses/InternalServerError' '503': $ref: '#/components/responses/ServiceUnavailable' components: parameters: IdempotencyKey: name: Idempotency-Key in: header required: false description: >- Optional request identifier for safe retries. Use a unique value for each create request you want to retry safely. schema: type: string example: invoice-create-2026-03-03-001 schemas: DocumentPaymentInput: description: >- Payload used to create a document payment. Only `invoice`, `proforma`, and `credit-note` documents are supported, and the target document must be available in the token scope. type: object required: - documentType - documentId properties: documentType: description: Type of the document you are paying. type: string enum: - invoice - proforma - credit-note example: invoice documentId: description: ID of the document you are paying. type: integer example: 301 currencyId: description: >- Optional currency ID from the [currency reference table](/en/reference-tables#currencies). If omitted, the source document currency is used. type: integer example: 1 currencyRate: description: >- Exchange rate of the payment currency against EUR. If omitted, the system derives it from the final `paymentDate` using the previous day's rate. If provided for a currency other than `EUR`, the override value is used as-is. If the final payment currency is `EUR`, the backend always stores `1.0`. type: number format: float example: 1 paymentDate: description: Payment date in `Y-m-d` format. If omitted, today's date is used. type: string format: date example: '2026-03-07' paymentMethodId: description: >- Optional payment method ID from the [payment method reference table](/en/reference-tables#payment-methods). If omitted, the source document payment method is used. type: integer example: 1 amount: description: >- Payment amount in the payment currency. If omitted, the current remaining `toBePaid` amount from the source document is used. This derived amount is available only when the source document has a non-zero `toBePaid`; otherwise the endpoint returns `422`. If sent explicitly, it can have at most 2 decimal places, its magnitude must not exceed the current `toBePaid`, and it must keep the same sign. The backend also accepts negative amounts, for example when settling a credit note. type: number format: float multipleOf: 0.01 example: 15.5 DocumentPayment: description: One payment of a public document. type: object properties: id: description: Internal payment ID. type: integer example: 801 documentType: description: Type of the document this payment belongs to. type: string enum: - invoice - proforma - credit-note example: invoice documentId: description: ID of the document this payment belongs to. type: integer example: 301 paymentMethod: $ref: '#/components/schemas/PaymentMethod' description: Used payment method as a nested lookup object. currency: $ref: '#/components/schemas/Currency' description: Payment currency as a nested lookup object. paymentDate: description: Payment date in `Y-m-d` format. type: string format: date example: '2026-03-07' amount: description: Payment amount in the payment currency. type: number format: float example: 15.5 currencyRate: description: >- Exchange rate of the payment currency against EUR. If the payment currency is `EUR`, the backend always returns `1.0`. type: number format: float example: 1 receiptInvoice: description: Preview of the linked payment receipt invoice, when it exists. anyOf: - $ref: '#/components/schemas/InvoicePreview' - type: 'null' PaymentMethod: description: Payment method available in Fintoro API lookup endpoints. type: object properties: id: description: Stable payment method ID used across the API. type: integer example: 1 name: description: >- Localized payment-method label. When you send `Accept-Language`, the backend translates this system-owned label accordingly. type: string example: Bank transfer Currency: description: Currency available in Fintoro API lookup endpoints. type: object properties: id: description: Stable currency ID used across the API. type: integer example: 1 symbol: description: ISO or internal currency symbol. type: string example: EUR name: description: >- Localized currency label. When you send `Accept-Language`, the backend translates this system-owned label accordingly. type: string example: Euro mark: description: Short currency mark displayed in Fintoro. type: string example: € InvoicePreview: description: >- Simplified invoice preview object returned by the list endpoint. It does not include line items or the bank account snapshot, but it does include the full historical client snapshot in `client`; use the invoice detail endpoint for the complete document. type: object properties: id: description: Internal invoice ID in Fintoro. type: integer example: 301 uuid: description: Stable UUID of the invoice. type: string example: 6b1b8c9e-66e6-4fb5-b2db-6d7c7f0f8f19 type: description: Document type. type: string example: invoice number: description: Invoice number. type: string example: '20260001' clientId: description: Live ID of the client linked to the invoice. type: integer example: 101 client: $ref: '#/components/schemas/InvoicePreviewClient' description: >- Historical client snapshot stored directly on the invoice without the live client ID. The live ID is available separately in `clientId`. issueDate: description: Invoice issue date. type: string format: date example: '2026-03-03' dueDate: description: Invoice due date. type: string format: date example: '2026-03-17' deliveryDate: description: Delivery date. type: string format: date example: '2026-03-03' currency: $ref: '#/components/schemas/Currency' description: Invoice currency as a nested object. total: description: Total amount without VAT. type: number format: float example: 200 totalWithVat: description: Total amount with VAT. type: number format: float example: 240 toBePaid: description: Remaining amount to be paid. type: number format: float example: 240 status: description: Current payment status of the invoice. type: string enum: - paid - unpaid - partially_paid - overdue - will_not_be_paid example: unpaid hasVat: description: Indicates whether the invoice contains any VAT-bearing items. type: boolean example: true InvoicePreviewClient: description: >- Historical client snapshot embedded directly in a document preview response. The live client ID is exposed separately through `clientId`. allOf: - $ref: '#/components/schemas/ClientSnapshot' ClientSnapshot: description: >- Historical client snapshot stored directly on the document. This object represents the client data exactly as it existed when the document was issued or last re-saved. If the client changes later, for example the name or billing address, the document keeps this historical value for auditability and long-term data persistence. Example: a document issued to `Main Street 1, Bratislava` remains historically correct even if the client profile now contains a different billing address. type: object properties: name: description: >- Person name or company name stored on the invoice at that moment in time. type: string example: Acme s.r.o. type: description: Client type stored on the invoice. type: string example: company subjectId: type: - string - 'null' description: >- Business ID of the client or company. For Slovak entities, you can typically also find this value through the [subject registry lookup](#operation/searchSubjects). example: '12345678' taxId: description: Tax ID stored on the invoice when it was available. type: - string - 'null' example: '2020123456' vatId: description: VAT ID stored on the invoice when it was available. type: - string - 'null' example: SK2020123456 isVatPayer: description: >- Indicates whether the client was marked as a VAT payer when this snapshot was stored. type: boolean example: true email: description: Client contact email stored on the invoice. type: - string - 'null' example: billing@acme.test street: description: Billing street and house number stored on the invoice. type: - string - 'null' example: Main Street 1 city: description: Billing city stored on the invoice. type: - string - 'null' example: Bratislava zip: description: Billing ZIP or postal code stored on the invoice. type: - string - 'null' example: '81101' countryId: description: >- Country ID from the [country reference table](/en/reference-tables#countries). type: - integer - 'null' example: 703 country: description: Billing country stored on the invoice as a nested object. anyOf: - $ref: '#/components/schemas/Country' - type: 'null' hasDeliveryAddress: description: >- Indicates whether this snapshot contains a separate delivery address. type: boolean example: true deliveryStreet: description: Delivery street and house number stored on the invoice. type: - string - 'null' example: Warehouse 9 deliveryCity: description: Delivery city stored on the invoice. type: - string - 'null' example: Kosice deliveryZip: description: Delivery ZIP or postal code stored on the invoice. type: - string - 'null' example: '04001' deliveryCountryId: description: >- Country ID from the [country reference table](/en/reference-tables#countries). type: - integer - 'null' example: 703 deliveryCountry: description: Delivery country stored on the invoice as a nested object. anyOf: - $ref: '#/components/schemas/Country' - type: 'null' Country: description: >- Country available in Fintoro API lookup endpoints and in nested objects where the country is returned directly in the response. type: object properties: id: description: Stable country ID used across the API. type: integer example: 703 name: description: >- Localized country label. When you send `Accept-Language`, the backend translates this system-owned label accordingly. type: string example: Slovakia code: description: Two-letter ISO country code. type: string example: SK eu: description: Indicates whether the country is part of the European Union. type: boolean example: true headers: XRequestId: description: >- Unique request identifier used for tracing, audit logs, and support diagnostics. schema: type: string example: req_public_api_01 ContentLanguage: description: Language selected for the request based on `Accept-Language`. schema: type: string example: en responses: TooManyRequests: description: >- The company exceeded the Fintoro API rate limit. This 429 response includes the same `X-RateLimit-Limit` and `X-RateLimit-Remaining` headers as other throttled responses and additionally adds `Retry-After` and `X-RateLimit-Reset`. If you need a higher limit, contact info@fintoro.sk for custom enterprise terms. headers: X-Request-Id: $ref: '#/components/headers/XRequestId' X-RateLimit-Limit: description: >- Maximum number of requests allowed for the company in the current 60-second window. This header is returned on all throttled responses, not only on 429. schema: type: integer example: 120 X-RateLimit-Remaining: description: >- Number of requests remaining for the company in the current 60-second window. This header is returned on all throttled responses, not only on 429. schema: type: integer example: 0 Retry-After: description: >- Number of seconds after which you can safely retry the request. This header is sent only on 429 responses. schema: type: integer example: 60 X-RateLimit-Reset: description: >- Unix timestamp when the current rate-limit window resets. This header is sent only on 429 responses. schema: type: integer example: 1774810800 content: application/json: schema: type: object properties: message: type: string example: Too Many Attempts. InternalServerError: description: >- An unexpected internal error occurred. This should not happen in normal operation and is automatically reported to us. headers: X-Request-Id: $ref: '#/components/headers/XRequestId' Content-Language: $ref: '#/components/headers/ContentLanguage' content: application/json: schema: type: object properties: message: type: string example: Server Error ServiceUnavailable: description: >- The API is temporarily unavailable during scheduled maintenance. We announce planned downtime at least 24 hours in advance. headers: X-Request-Id: $ref: '#/components/headers/XRequestId' Content-Language: $ref: '#/components/headers/ContentLanguage' content: application/json: schema: type: object properties: message: type: string example: Service Unavailable securitySchemes: bearerAuth: type: http scheme: bearer bearerFormat: Token description: Bearer token created for a specific company in Integrations → API. ````