> ## 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 warehouse > Creates a new warehouse including its inbound and outbound numbering series. The response returns the final persisted warehouse object. ## OpenAPI ````yaml /en/openapi.yaml post /warehouses 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: /warehouses: post: tags: - Warehouses summary: Create warehouse description: >- Creates a new warehouse including its inbound and outbound numbering series. The response returns the final persisted warehouse object. operationId: createWarehouse requestBody: required: true content: application/json: schema: $ref: '#/components/schemas/WarehouseCreateInput' responses: '201': description: Warehouse created. headers: X-Request-Id: $ref: '#/components/headers/XRequestId' content: application/json: schema: $ref: '#/components/schemas/Warehouse' '422': $ref: '#/components/responses/ValidationError' '429': $ref: '#/components/responses/TooManyRequests' '500': $ref: '#/components/responses/InternalServerError' '503': $ref: '#/components/responses/ServiceUnavailable' components: schemas: WarehouseCreateInput: description: Payload used to create a warehouse. All business fields are required. type: object required: - name - code - inboundNumericalSeriesPattern - inboundNumericalSeriesNextNumber - outboundNumericalSeriesPattern - outboundNumericalSeriesNextNumber properties: name: description: Warehouse name. type: string maxLength: 255 example: Main warehouse code: description: Internal warehouse code unique within the token scope. type: string maxLength: 255 example: MAIN-WH inboundNumericalSeriesPattern: description: >- Numbering-series pattern for warehouse inbound receipts. It must contain a counter token. type: string maxLength: 255 example: INB-(YY)-(CCCC) inboundNumericalSeriesNextNumber: description: Next sequence number for the inbound series. Minimum value is `1`. type: integer minimum: 1 example: 1 outboundNumericalSeriesPattern: description: >- Numbering-series pattern for warehouse outbound receipts. It must contain a counter token. type: string maxLength: 255 example: OUT-(YY)-(CCCC) outboundNumericalSeriesNextNumber: description: Next sequence number for the outbound series. Minimum value is `1`. type: integer minimum: 1 example: 1 Warehouse: description: >- Warehouse, including inbound and outbound numbering-series configuration. type: object properties: id: description: Internal warehouse ID in Fintoro. type: integer example: 301 name: description: Warehouse name displayed in Fintoro. type: string example: Main warehouse code: description: Internal warehouse code unique within the token scope. type: string example: MAIN-WH inboundNumericalSeriesPattern: description: >- Numbering-series pattern used for warehouse inbound receipts of this warehouse. type: string example: INB-(YY)-(CCCC) inboundNumericalSeriesNextNumber: description: >- Next sequence number that will be used when automatically generating a warehouse inbound receipt. type: integer example: 12 outboundNumericalSeriesPattern: description: >- Numbering-series pattern used for warehouse outbound receipts of this warehouse. type: string example: OUT-(YY)-(CCCC) outboundNumericalSeriesNextNumber: description: >- Next sequence number that will be used when automatically generating a warehouse outbound receipt. type: integer example: 8 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: ValidationError: description: Request payload or query parameters failed validation rules. 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: The given data was invalid. errors: type: object additionalProperties: type: array items: type: string 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. ````