e-Faktura API

Authentication

Every request (except getting an OAuth token, the public Bridge-release list and the health check) carries an Authorization: Bearer header.

API keys

Create keys in the console, scoped to specific permissions (“scopes”) and optionally to a subset of your client companies. A key looks like:

mfk_test_7hqk2m9vslgp4wz3c1yxfb0e
mfk_live_9k2pqxlt5m0wnzvcb1y47rghf

The test/live segment is the environment — sandbox keys can only touch environment: "sandbox" documents, live keys only production ones. Keys are shown once at creation; only a hash is stored server-side. Rotate a key from the console: the old one keeps working for up to 7 days so you can roll deploys without downtime.

Authorization: Bearer mfk_test_7hqk2m9vslgp4wz3c1yxfb0e

OAuth 2.0 client credentials (vendors)

Vendors integrating on behalf of many client companies can use OAuth 2.0 client-credentials (RFC 6749 §4.4) instead of a static key:

POST /v1/oauth/token
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials&client_id=mfc_...&client_secret=...&scope=einvoices:read einvoices:write

This returns a short-lived (15-minute) bearer token whose scopes are the intersection of what you asked for and what the client is allowed. This is the one endpoint whose error body is plain OAuth 2.0 JSON ({ error, error_description }), not application/problem+json — see Errors.

Scopes

Multi-company keys

A key or token that has access to more than one client company must send X-Company-Id on every request; a key scoped to exactly one company can omit it.

Environments

mfk_test_... keys (and sandbox OAuth clients) only ever talk to UJP’s test system or the Merot simulator — see Sandbox. Production keys need production_allowed on the account, which requires an active paid plan.