Nordlet

← Документация / Ръководства

Начало на работа

API ключове, първи заявки, пълният цикъл на фактуриране, SDK и уебхукове.

Nordlet е счетоводна платформа с водещо API за пазара на ЕС/ЕИП, стартираща с пълно съответствие с литовското законодателство. Всичко, което продуктът прави - фактуриране, главна книга (general ledger), банково съгласуване (bank reconciliation), i.SAF - е достъпно чрез едно JSON API.

1. Получаване на API ключ

Всяка заявка се автентикира с Bearer API ключ, обвързан с една компания:

Authorization: Bearer nl_...

За локална разработка можете да инициализирате компания и ключ:

pnpm --filter @nordlet/db bootstrap:dev     # празна компания
pnpm --filter @nordlet/api seed:demo        # компания с демо данни

Интерактивна API справка (API reference) (OpenAPI спецификация на адрес /openapi.json; локална инстанция предоставя същата справка на http://localhost:3001/docs).

Postman

Предпочитате Postman? Импортирайте готовата колекция - всеки ендпоинт (endpoint), групов по модули, с предварително настроено Bearer удостоверяване: Nordlet Postman collection. След импортиране задайте на променливата bearerToken на колекцията вашия API ключ и всяка заявка ще бъде автентикирана.

Тестови компании (Sandbox)

За целите на интеграционното тестване създайте компания с isSandbox: true (POST /v1/account/companies/create или поставете отметка в квадратчето за тестова среда по време на регистрацията в приложението). Една тестова компания функционира точно като реална - със същите модули и същото API, което ви позволява да преминете през реален обем от транзакции - но тя е видимо обозначена като тестови данни, а изтриването ѝ премахва всичко незабавно, вместо след 10-дневния срок за съхранение. Можете да стартирате произволен брой тестови компании успоредно с реалната си компания в рамките на един и същ акаунт; флагът е неизменен след създаването, така че реалните счетоводни регистри никога да не могат да бъдат прекласифицирани тихо като тестови данни. Използването в тестова компания се отчита и таксува точно както в реална компания: заявки, страници за сканиране на документи, съхранение и такса за реактивиране. Данъчните декларации и електронните фактури на тестовата компания винаги се изпращат към тестовите ендпоинти на администрацията.

2. Първи заявки

Всяка операция представлява POST /v1/{module}/{resource}/{action} с JSON тяло. Създаване на клиент (партньор):

curl -X POST https://api.nordlet.com/v1/partners/create \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: partner-create-001" \
  -d '{"name": "UAB Klientas", "code": "301111222", "vatCode": "LT100001112223"}'

Издаване на фактура (сумите са десетични низове, никога с плаваща запетая):

curl -X POST https://api.nordlet.com/v1/sales/invoices/create \
  -H "Authorization: Bearer $API_KEY" -H "Content-Type: application/json" \
  -d '{
    "partnerId": "<partner id>",
    "lines": [{"description": "Konsultacijos", "quantity": 4, "unitPriceExclVat": "75.0000", "vatClassifierCode": "PVM1"}]
  }'

curl -X POST https://api.nordlet.com/v1/sales/invoices/issue \
  -H "Authorization: Bearer $API_KEY" -H "Content-Type: application/json" \
  -d '{"id": "<invoice id>", "issueDate": "2026-07-09"}'

Издаването генерира пореден номер без пропуски (SF-1), проверява дали счетоводният период е отворен и записва балансираната счетоводна статия (Дт 2410 вземания / Кт 5001 приходи / Кт 4492 ДДС) в рамките на същата транзакция.

3. Пълният цикъл

Стъпка Заявка
Прехвърляне на счетоводството от предходна система migration/books/validate → migration/books/import - вижте Мигриране от друга система
Регистриране на фактура от доставчик purchases/invoices/create → purchases/invoices/register
Импортиране на банково извлечение bank/statements/import (camt.053 XML) или bank/transactions/import (JSON)
Получаване на предложения за съвпадение bank/transactions/suggest-matches
Съгласуване (реконсилиране) на плащане bank/transactions/match - записва плащането и актуализира paymentStatus
Плащане към доставчици bank/payments/export - pain.001 SEPA файл за вашата банка
Месечни ДДС регистри declarations/lt/isaf/generate - i.SAF 1.2 XML за VMI
Данни за справка-декларация по ДДС declarations/lt/fr0600/compute - полета по FR0600, съгласувани с регистрите
Экспедиране на стоки с товарителница transport/waybills/create → issue, след което declarations/lt/ivaz/generate - i.VAZ XML за VMI

4. TypeScript SDK

import { createNordletClient, idempotent } from '@nordlet/sdk'

const client = createNordletClient({
  baseUrl: 'https://api.nordlet.com',
  apiKey: process.env.NORDLET_API_KEY!,
})

const { data, error } = await client.POST('/v1/sales/invoices/create', {
  body: {
    partnerId,
    lines: [{ description: 'Konsultacijos', quantity: 4, unitPriceExclVat: '75.0000' }],
  },
  ...idempotent(`order-${orderId}`),
})

SDK-то се генерира от актуалната OpenAPI спецификация (pnpm --filter @nordlet/sdk generate), така че всяка заявка и отговор са напълно типизирани.

5. Уебхукове (Webhooks)

Абонирайте се за събития вместо да изпращате периодични заявки за проверка (polling):

curl -X POST https://api.nordlet.com/v1/webhooks/subscriptions/create \
  -H "Authorization: Bearer $API_KEY" -H "Content-Type: application/json" \
  -d '{"url": "https://example.com/hooks/hyperion", "events": ["sale_invoice.issued", "sale_invoice.paid"]}'

Доставките носят времеви отпечатък с HMAC подпис (x-nordlet-signature-v2: t=<unix seconds>,v1=<hex> върху <timestamp>.<raw body> с вашия секретен ключ за абонамент) наред с оригиналния x-nordlet-signature: sha256=<hex> на суровото тяло, като се правят опити за повторно изпращане в продължение на около 24 часа. Вижте API конвенции относно прозореца за повторно изпращане.

Всяко тяло на доставка представлява { id, version, companyId, eventType, createdAt, data }: version е версията на обвивката (в момента 1), а companyId е компанията, към която принадлежи събитието, така че един получател да може да обслужва няколко компании. Абонирането за име, което не е в списъка по-долу, се отхвърля с код 400; използвайте "*" за всички събития. След 5 неуспешни опита за доставка подред, абонаментът се поставя на пауза и собствениците на компанията получават имейл; можете да го възобновите в Акаунт → Уебхукове (Account → Webhooks) или чрез webhooks/subscriptions/update и isActive: true.

Събития: agreement.invoice_generated, bank_feed.synced, document_capture.peppol_received, filing.failed, filing.rejected, goods_receipt.posted, intercompany.invoice_mirrored, item.created, item.deleted, item.updated, lead.converted, lead.created, partner_inquiry.created, payroll_run.approved, payroll_run.reversed, pos_report.created, price_list.updated, purchase_invoice.paid, purchase_invoice.registered, purchase_order.approved, purchase_order.received, refund_liability.actual, refund_liability.trued_up, report.completed, report.failed, revenue_recognition.modified, revenue_recognition.posted, sale_invoice.einvoice_sent, sale_invoice.issued, sale_invoice.paid, sale_invoice.peppol_delivered, sale_invoice.peppol_failed, sale_invoice.peppol_rejected, sale_invoice.peppol_sent, sale_invoice.quote_sent, sale_invoice.sent, sales_order.created, sales_order.fulfilled, settlement.imported, settlement.posted, settlement.updated, stock.changed, stock.reorder_needed, vat_review.opened, vat_review.resolved. OpenAPI документът описва всяко от тях в секцията x-webhooks.

Вижте API конвенции за заявки за списъци, обвивки за грешки, семантика на идемпотентността (idempotency) и лимити на заявките (rate limits).