Automatic invoices with Fakturownia and inFakt
How to connect your own Fakturownia or inFakt account, what lands on the invoice Insy creates for each sale, and the cases where no invoice is created at all.
Insy can push an invoice into your own Fakturownia or inFakt account when a sale goes through. The document is created under your account, numbered by your provider, and Insy keeps only the number and — for Fakturownia — a link to the PDF.
This is about the invoices you issue to your buyers. It is not the commission invoice Insy issues to you for platform fees; that one is produced by Insy and has nothing to do with this integration.
What you need before it can work
Business information is stored per Stripe account, not per community — so every community and product that sells through the same Stripe account shares one record. You edit it on the Business information screen of a community or a product, or on the Stripe account itself under your account settings.
The fields:
- Customer type — individual or company. Required, and it decides which of the fields below you can even see.
- NIP — required, and only shown, when you pick company.
- Buyer — the name. Required.
- Street, Postal code, City — all required.
- VAT rate — optional whole number from 0 to 23. Only shown when you pick company.
Connecting a provider
Both providers live on the Integrations screen of a community, and on the Integrations screen of a digital product. Each has a card — Fakturownia, inFakt — with a Connect button that opens a short form. After saving, that button becomes View; the dialog it opens shows whether the provider has rejected anything, and a Reconfigure button inside it brings the form back.
Two fields, both required.
API Key — an API token from your own Fakturownia account. Insy sends it as api_token in
the body of the request that creates the invoice.
Fakturownia subdomain — the part before .fakturownia.pl in your account’s address. For
mycompany.fakturownia.pl you enter mycompany. Insy posts to
https://your-subdomain.fakturownia.pl/invoices.json, so a typo here is the same as a wrong
key.
One field.
API Key — an API key from your own inFakt account. Insy sends it in the X-inFakt-ApiKey
header to https://api.infakt.pl/api/v3, and no other value is stored: the seller details on
the invoice come from your inFakt account, not from Insy.
Insy does not link to your provider or explain where the key is generated — you create it in the provider’s own panel and paste it in.
Fakturownia always wins
Both keys fit in the same record, and both cards will happily show themselves as connected. But Insy picks the provider by looking at the Fakturownia key first: inFakt is only used when the Fakturownia key is empty.
There is no provider switch and no Disconnect. The API has no delete for this integration, and both forms refuse an empty key — so once a Fakturownia key has been saved, there is no way from the interface to clear it and fall back to inFakt.
When an invoice is created
Exactly two moments, both on the Stripe rail:
- The first payment of a subscription — when the subscription checkout completes.
- A one-time payment — both the hosted checkout in payment mode and the embedded checkout’s successful payment.
Insy keys the invoice to the payment, so a payment can never produce two invoices.
What ends up on the invoice
Always exactly one line item, quantity 1. Its name is the pricing plan the buyer bought — or the
literal word Payment on a one-time sale where the plan can’t be resolved — and its gross value is
the amount charged.
| On the invoice | Where it comes from |
|---|---|
| Line item name | The pricing plan’s name, or Payment as a fallback |
| Line item amount | The gross amount actually charged, quantity always 1 |
| VAT rate | The VAT rate from your business information; 23% if you left it empty |
| Buyer name and email | The name and email from checkout |
| Buyer NIP | Never set — see below |
| Sale date, issue date, payment due | All today’s date |
| Payment status | Marked paid |
| Invoice number | Assigned by your provider; Insy has no numbering of its own |
Because the VAT rate field is only shown when your business information says company, a seller registered as an individual has no way to change the rate: every invoice goes out at 23%.
Where the two providers differ
| Fakturownia | inFakt | |
|---|---|---|
| Fields you supply | API key and subdomain | API key |
| Seller details | Taken from your Insy business information | Taken from your inFakt account |
| Currency of the sale | Sent through to the invoice | Not sent — your inFakt account’s default is used |
| Amounts sent as | Gross | Net, computed back from the gross amount |
| Buyer name | One field | Split at the first space into first and last name |
| Document link kept by Insy | A PDF link | None |
| Marked paid | In the same request | In the same request, plus a follow-up call a few seconds later |
The buyer does not receive it
Insy never sends the invoice to anyone. Fakturownia is given the buyer’s email address as a field on the document and inFakt is given it as the invoice recipient, but Insy never calls either provider’s send-email endpoint — and the document is not shown to the buyer anywhere in Insy either.
If your buyer needs the invoice, send it from your provider’s panel.
KSeF
When it goes wrong
The card turns red and the badge says Payment errorProvider rejected the request
When your provider rejects the request — which is what a wrong, revoked or mistyped key produces — Insy records the returned status code and response body against the integration and stops. The card switches to an error state whose badge reads Payment error. That label is shared with other parts of the app and says nothing about the buyer’s payment: the sale itself went through, only the invoice didn’t.
The error always reads Unknown error, with no detailStored but not displayed
The card looks for fields the backend never writes, so it falls back to Unknown error every time, with no status code. The provider’s real status code and response body are stored — but no screen displays them. Ask support@insy.io to read them out for you.
The card stays red after you fix the keyErrors are never cleared
Nothing clears the recorded errors — not reconfiguring the integration, not a later successful invoice. Once your provider has rejected a single request, the card stays in the error state permanently. The reliable way to tell whether it works now is to check whether new invoices are appearing in your provider’s account.
A sale produced no invoice and nothing was flaggedSilent skips
If the community or product has no integration, or no API key, or the Stripe account has no business information saved, generation stops before anything is recorded. There is no error on the card, no email, and no marker on the sale. Silence is the expected symptom of a misconfigured setup, so verify against your provider’s account rather than against the card.
You want a missing invoice re-issuedRetry is admin-only, and lossy
There is no retry button for creators; only Insy staff can retry a stored invoice record, and a
record only exists if generation got past the checks above. The retry is also lossy: it rebuilds
the document from data that doesn’t include the original line, so it goes out as a single line
named Payment for the full payment amount, with an empty buyer name. Issuing the invoice by
hand in your provider’s panel is usually the cleaner fix.