Which Israeli invoicing system is easiest to integrate with?

Judged on integration experience rather than features, EZcount stands out mainly because it offers a real demo environment at demo.ezcount.co.il with its own API key. Since an issued tax document cannot be deleted, being able to develop and test without creating real documents saves more effort than any difference in interface syntax. Verify the current state of each system's sandbox before committing.

Do Israeli invoicing APIs follow REST conventions?

Not in the resource-per-entity sense. EZcount is a JSON POST to a single createDoc endpoint, and Rivhit is a WCF-style service built around named operations such as Document.New. There is no DELETE on an invoice anywhere, which is consistent with the underlying rule that an issued tax document is cancelled by an offsetting document rather than removed.

Does Hashavshevet have an API like the cloud invoicing systems?

Do not assume so. Hashavshevet originates in the desktop world rather than as a cloud service, so the first question is whether an interface suitable for your specific need exists and in which version, not how to call it. This is the one system on the list where an integration should never be priced before that has been confirmed directly.

What is the biggest cost in an invoicing API integration?

Not the HTTP call. It is deciding which document type to issue and when, whether amounts include VAT, how exempt dealers are handled, and how allocation numbers fit the flow. These are identical across every system and are accounting decisions requiring the business accountant's sign-off, not technical choices a developer should make alone.

Should a business switch invoicing systems for a better API?

Almost never. The invoicing system serves the bookkeeping and the accountant who works in it daily, not the developer who integrates with it once. The interface differences amount to roughly a day of work, while migrating systems means moving historical documents and retraining whoever keeps the books. Integrate with what is already there.

Israeli Invoicing APIs Compared

An integrator's comparison of the Israeli invoicing systems - authentication styles, whether a sandbox exists, the interface shape, and the four questions that actually decide the integration cost regardless of which one you pick.

Most Israeli invoicing systems expose an API, and when you need to issue documents automatically from another system, "which is easiest to work with" comes up early. This comparison is not about features or price - it is about the interface, and about what actually determines the project's cost.

A note on reliability: endpoints, document codes and product names in this market change. What follows is a starting point that points you at the right questions - the current official documentation is the binding source, and it should be opened before writing code and before committing to a client timeline.

What the interfaces look like

System	Interface shape	Auth	Sandbox
EZcount / EasyCount	JSON POST to a single endpoint - `/api/createDoc`	`api_key` + `developer_email` in the body	Yes - `demo.ezcount.co.il` with its own key
Rivhit	WCF-style service, named operations - `Document.New`	Credentials in the request body	Verify against the docs
iCount	API v3	API key in an `Authorization` header	Verify against the docs
Morning (Green Invoice)	REST	Key-based	Verify against the docs
Hashavshevet	Desktop software in origin - do not assume a cloud API	-	-

Three notes on the table:

None of them is modern REST in the sense of a resource per entity with HTTP verbs. EZcount is one endpoint that takes everything; Rivhit is named operations. If you arrive expecting DELETE /invoices/123 you will be disappointed everywhere - and that is fine, because a tax document is never deleted anyway.

Hashavshevet is the significant outlier. It comes from the desktop world, so it is the only one where the first question is not "how do I call the API" but "is there an interface that fits what I need at all, and in which version". Do not price an integration against it on an assumption. See automating Hashavshevet and Rivhit.

iCount is documented but its documentation resists automated access - open it in a browser rather than relying on web examples, some of which refer to older interface versions.

The criterion that matters most and is usually ignored: a sandbox

This is what I put first when someone asks which to choose.

A tax document is not an ordinary record. Once issued it exists for tax purposes, has a sequential number, and cannot be deleted. The only way to cancel is an offsetting document with negative values.

Which means: developing against production leaves a document requiring accounting treatment behind every test mistake. Ten development iterations equals ten documents to cancel by hand.

EZcount has a real demo environment on the same endpoint path with a separate key. That is a genuine operational advantage, and in my view it outweighs any difference in syntax. For the others - ask explicitly before starting; it is a fair question to put to their support.

In every case: keep the base URL and the API key as two separate environment variables, and make sure automated tests always point at the test environment.

What is identical everywhere - and where the real cost sits

Once the first call works, the differences between systems all but vanish. What stays the same:

1. The retry problem

You send a request, the server issues the document, the connection drops before the response returns. Your code sees a timeout, reads it as failure, retries - and now there are two tax documents.

A timeout is not a failure, it is an absence of knowledge. Before any retry, check whether the document already exists, keyed on a unique reference you store on your side. A missing document is fixed in a minute; a duplicate needs a cancellation and a paper trail.

2. Document type

This is the choice with legal meaning. Tax invoice, combined invoice-receipt, receipt and credit note are not interchangeable - they determine when revenue is recognised.

In Rivhit it also shapes the request: documents representing receipt of money require a payment object, and each payment method has its own mandatory fields.

This is the business accountant's decision, not the developer's.

3. VAT and exempt dealers

Whether the amounts you send include VAT - verify against a real document in the test environment rather than assuming. And an exempt dealer does not issue a tax invoice at all; if the system serves more than one dealer type, that changes the document type.

4. Allocation numbers

The Tax Authority requirement applies regardless of which system you picked. Make sure the flow handles it before go-live. See invoice allocation numbers for developers.

Security - identical everywhere

The API key permits issuing tax documents on behalf of the business. In most of these systems it does not expire on a schedule. So: environment variables or a secrets manager only. Not source control, not logs, and not any code running in a browser.

And persist the full API response even on success - it is your only evidence when an accounting query arrives.

So which to choose

In most cases you will not choose - the business already works with a system and its accountant knows it. Switching invoicing systems because of an API is a poor decision: the system serves the bookkeeping, not the developer.

Where there is a genuine choice, the practical order:

Is there a sandbox? This saves the most pain.
Is the documentation accessible and current? Live docs with examples beat an elegant interface.
Does the accountant know the system? That determines how many questions are resolved in one phone call.
Interface style. Last, deliberately - it is a day of work, not a week.

Israeli Invoicing APIs Compared: Which Is Easiest to Integrate

Key takeaways