Managed Connector for ERP systems

Connect your ERP system to the Peppol network. In one day.

We are the only digital postman in Slovakia providing a simple Peppol "socket" for ERP systems.

Request a verified sandboxOpen Connector documentation

We create access manually after verifying the integrator. Public self-service is not available.

Developers connecting an ERP system to electronic delivery through ePošťák Connector
01Your ERP sends ordinary invoice data
02ePošťák handles formatting, checks, and delivery
03You identify customers with the IDs you already use

Connector is the new recommended ERP path. Existing SAPI and Enterprise API integrations do not have to migrate.

Fastest way to start

Send a document, track its state, and respond from one client.

The official SDK handles sign-in and keeps every call connected to the right company. If you use your own HTTP client, the whole flow is documented. Check state regularly or enable instant alerts.

Recommended · TypeScript SDK

npm i @epostak/sdk

Open all 6 SDKs on GitHub
import { EPostak } from "@epostak/sdk";

const client = new EPostak({
  clientId: process.env.EPOSTAK_CONNECTOR_CLIENT_ID!,
  clientSecret: process.env.EPOSTAK_CONNECTOR_CLIENT_SECRET!,
  baseUrl: "https://dev.epostak.sk/api/v1",
});

const customer = client.connector.customers.for("erp-acme");
const document = await customer.documents.send({
  externalId: "invoice-2026-0042",
  number: "2026-0042",
  buyerReference: "OBJ-2026-0042",
  recipient: { country: "SK", taxId: "2120123456" },
  lines: [
    { description: "ERP service", quantity: 1, unitPrice: 100, vatRate: 23 },
  ],
});

const page = await customer.events.list({ limit: 100 });
for (const event of page.events) {
  if (event.type === "document.received") {
    await customer.documents.acknowledge(
      event.documentId,
      `erp:${event.documentId}`,
    );
  }
}

console.log(document.id, page.nextCursor);

The same simple flow for every company is available across six SDKs. TypeScript is on npm; Python, PHP, .NET, Java, and Ruby are available as source on GitHub.

Flow for your own HTTP client

  1. 1. POST /api/v1/auth/token

    Sign in the application with the assigned details. Reuse the short-lived access until it expires.

  2. 2. POST /api/v1/connector/documents

    Send the customer and document IDs, invoice data, and a key that prevents duplicate creation.

  3. 3. GET /api/v1/connector/events

    Read state changes regularly. Save the position of the last change only after your ERP processes it successfully.

  4. 4. POST …/{documentId}/acknowledge or /respond

    One call confirms the ERP import; the other sends a decision to the counterparty, for example {"status":"accepted"}.

ePošťák approves the integrator, assigns companies, and handles their Peppol registration. Once registration is complete, set your own stable ERP customer ID for every company.

From ERP to evidence

You provide the document. Connector manages delivery.

The ERP knows its customer and invoice. ePošťák takes over network discovery, electronic-format generation, validation, queueing, and recovery.

Your ERP sends

  • the customer ID already stored in your ERP
  • invoice data as JSON
  • company, tax, VAT, or Peppol ID if you know it

ePošťák handles

  1. checks access to the customer
  2. finds the recipient and checks whether it can receive the invoice
  3. builds and validates the e-invoice
  4. queues delivery, retries, and recovers state

Your ERP receives

  • a document ID for later calls
  • a clear document state
  • events, history, and evidence

An ordinary company or tax ID is enough for most recipients. Supply a Peppol ID only when you already know it.

What you send and what you receive

Send invoice data. Receive one ID and a clear next step.

Your customer ID connects the document to the right approved company. If you repeat the same submission after an outage, Connector does not create a duplicate.

Data from your ERP
Ordinary accounting data
POST /api/v1/connector/documents
Authorization: Bearer <token>
Idempotency-Key: erp-acme:invoice:2026-0042

{
  "customerRef": "erp-acme",
  "externalId": "invoice-2026-0042",
  "number": "2026-0042",
  "recipient": {
    "country": "SK",
    "taxId": "2120123456"
  },
  "lines": [{
    "description": "Monthly licence",
    "quantity": 1,
    "unitPrice": 100,
    "vatRate": 23
  }]
}
ePošťák response
201 Created
{
  "id": "8e4b8f0e-21d3-4d2a-9c2b-24a3f8a0c111",
  "customerRef": "erp-acme",
  "externalId": "invoice-2026-0042",
  "state": "queued",
  "replayed": false,
  "links": {
    "self": "/api/v1/connector/documents/8e4b…",
    "evidence": "/api/v1/connector/documents/8e4b…/evidence"
  }
}
Document ID and allowed actions
01

Send now or later

Send the document immediately or only prepare it. The response always shows whether sending or cancellation is still available.

02

Safe repetition

If the connection fails, repeat the same submission with the same key. Connector returns the same document and does not create a duplicate.

03

One ID throughout processing

Use the same document ID while it waits, sends, arrives, reports changes, and provides evidence.

From sending to confirmation

Your ERP always knows what happened and what it can do next.

Create the document once. Then read its state, use the offered action, and receive changes through regular checks or instant alerts.

01
documents

Create or list

POST /api/v1/connector/documents · GET /api/v1/connector/documents

Send the invoice data. The same path lists documents for the selected company.

02
detail

Read detail

GET /api/v1/connector/documents/{documentId}

Returns the current state and only the actions that are safe at that moment.

03
available actions

Send or cancel a prepared document

POST …/{documentId}/send · POST …/{documentId}/cancel

The ERP does not need its own action rules; it uses the send or cancel option offered by the document detail.

04
state changes

Read changes

GET /api/v1/connector/events

Changes carry the state of outbound and inbound documents. Save the last position only after successful ERP processing.

05
instant alerts

Receive changes immediately

PUT /api/v1/connector/webhook · POST /api/v1/connector/webhook/test · GET …/webhook/deliveries/{deliveryId}

Configure optional instant alerts once for the whole account. Every change identifies the company it belongs to. The debugger finds a company by customerRef and shows the exact body, every attempt, a human diagnosis, and safe replay.

06
acknowledge

Confirm processing

POST /api/v1/connector/documents/{documentId}/acknowledge

The ERP can safely repeat the confirmation. It confirms only the local import; nothing is sent to the counterparty.

07
respond

Respond to the counterparty

POST /api/v1/connector/documents/{documentId}/respond?customerRef=...

A body such as {"status":"accepted"} sends the response to the counterparty. Available statuses: received, in_process, under_query, conditionally_accepted, rejected, accepted, and paid.

Send now or later

Send the document immediately or prepare it for later. The response always shows whether sending or cancellation is available.

Safe repetition after an outage

After an interruption, repeat the same submission. Connector returns the original document, so the ERP never has to guess whether a duplicate was created.

Regular checks or instant alerts

Check state regularly or enable instant alerts. Regular checks remain the reliable source after an outage.

What your ERP needs to remember

Five values cover sending, receiving, and finding a document.

ePošťák handles Peppol identifiers and network rules. Your code works with customer and document data, state, and available actions.

Customer ID in your ERP

Send the ID you already use for the company in your ERP. Set it in the Integrator Portal; it stays locked after the first use.

Recipient details

Send the country and company, tax, or VAT ID. An exact Peppol ID is optional.

Document ID

Use the same ID for detail, state changes, support, and evidence.

Document state

A clear state tells you whether the document is waiting, sending, delivered, or needs attention.

Available actions

Connector offers only the safe actions available at that moment, including a separate response to an inbound invoice.

A simpler integration

Start with one document and continue from its state.

Your ERP sends an invoice, receives its ID, and sees the safe next action at every step. It does not have to assemble separate flows for sending, receiving, and recovery.

AreaPreviously, you assembled several stepsNow one document guides the flow
Where to startEvery phase required choosing the right technical operation.Send the document and receive the safe next actions in the response.
Recipient identityThe ERP had to know network and addressing details.Provide the country and an ordinary company, tax, or VAT ID.
Send laterQueueing and its actions required a separate flow.Choose whether to send the document now or prepare it for later.
Failure recoveryThe ERP had to match results to repeated attempts itself.A repeated call safely returns the same document and never creates a duplicate.
State and inboundState, inbound documents, and synchronization used different flows.Read state, inbound documents, confirmation, and counterparty responses in one place.

Advanced options remain available, but you do not need them for normal sending, receiving, and evidence.

No disruption to existing integrations

Adopt the new Connector without changing SAPI or Enterprise API.

Existing SAPI, Enterprise API, and older Connector integrations keep working as they do today. The new Connector is a simpler choice for new ERP connections; you do not need to change current calls, headers, or sign-in.

Connector

Recommended for new ERP integrations that do not want to handle Peppol formats, addressing, and network rules.

Enterprise API

For teams that need control over individual operations, multiple companies, and their own processing flow.

SAPI

The standardized contract remains available to existing testers and integrations that require SAPI-SK compatibility.

Open Enterprise API documentationCompare all API layers

Optional tools

Core sending works without any extra tools.

For a normal integration, send a document and read its changes. Use Mapper and the support package only when they solve a specific problem.

Mapper

If your ERP cannot produce the recommended format, Mapper translates its JSON, CSV, XML, or invoice extract. Submit the result in the same way as a normal document.

POST /api/v1/connector/mapper

Support package and evidence

For diagnostics or audit, retrieve a technical package and delivery evidence for a specific document without expanding the core ERP model.

GET /api/v1/connector/documents/{documentId}/support-packet
View optional operations in the documentation

Manually verified access

We prepare the sandbox after a short integrator review.

We do not run public self-service or issue identities automatically. This protects production data, customer relationships, and trust in the integrator program.

Request sandbox access by emailRead Connector documentation

info@epostak.sk · tell us the concrete integration you are building

  1. 01

    Email us

    Include the company, product or integration purpose, and the technical contact's name and email.

  2. 02

    An operator creates access

    After verification, we prepare an isolated sandbox, sign-in details, and approved companies including their Peppol registration.

  3. 03

    Link your customer IDs

    After Peppol registration is complete, assign each approved company the ID you already use in your ERP. Connector uses it to select the right company every time.

  4. 04

    Verify the full flow

    Test sending, state tracking, inbound documents, confirmation, and counterparty responses. Production go-live is approved separately.