A practical developer's guide to the EZcount / EasyCount document API - the createDoc endpoint, the demo environment, document type codes, how cancellations actually work, and the design decisions that matter before you write a line of code.
Key takeaways
- There is a real demo environment at demo.ezcount.co.il with its own API key. Build and test against it - a tax document issued by mistake in production is a bookkeeping problem, not a bug you can delete.
- A tax document cannot be edited or deleted. Cancelling a receipt means submitting the same document again with negative values - design your retry logic around that, or a network timeout will produce duplicate invoices.
- The document type code is the single most important field. It decides whether you created an invoice, a receipt, a combined invoice-receipt or a credit note - and each has different legal meaning.
- Store the returned document ID and URL on your own record immediately. It is the only durable link between your order and the official tax document, and you will need it for reconciliation.
EZcount, also known as EasyCount, is one of the common cloud invoicing systems in Israel, and it exposes an API that lets you issue tax documents directly from your own system. This guide covers what you need to decide before you start - not just how to send a request, but how to design the integration so it does not create an accounting mess.
Endpoint and authentication
Document creation is a POST with a JSON body to /api/createDoc:
- Production:
https://www.ezcount.co.il/api/createDoc - Demo:
https://demo.ezcount.co.il/api/createDoc
Authentication is not OAuth and there is no separate login step. You send api_key and developer_email in the body of every call. The key is generated in the system's own interface, and the demo environment has its own separate key.
The operational consequence: the api_key is a full credential. It does not expire on a fixed schedule, and anyone holding it can issue tax documents on behalf of the business. It should never appear in source control, logs or client-side code - only in environment variables or a secrets store.
The demo environment is not a nicety
A tax document is not an ordinary database row. Once issued it exists for tax purposes, receives a sequential number, and cannot be deleted. Developing against production means every test mistake leaves behind a document that needs accounting treatment.
So: keep the base URL and the API key as two separate environment variables and switch to production only at the end. Automated tests should always point at the demo.
Document type codes
The type field decides which document is created, and it is the choice with legal meaning. Codes that recur in the documentation and in usage examples include:
- 320 - combined tax invoice and receipt, the most common document when payment is taken at the time of the order
- 333 - credit note
- 400 - receipt
- 405 - appears in usage examples
Important: the complete and authoritative list lives in EZcount's live API documentation and can change. Do not hard-code a type without verifying it against the current documentation, and do not infer one by reasoning - the difference between an invoice and a combined invoice-receipt is a difference in when revenue is recognised.
The real problem: cancellation and retries
There is no delete and no edit. The way to cancel a document is to submit it again with every value negated - negative amounts - producing an offsetting document that zeroes out the first. This is standard practice in Israeli invoicing, but it changes how the code has to be written.
The scenario that breaks integrations: you send a create request, the server issues the document, and then the connection drops before the response reaches you. Your code sees a timeout, treats it as a failure, and retries - and now there are two identical invoices with two sequential numbers, one of which needs manual cancellation.
The defence is not automatic retry. Before any retry, check whether the document already exists, and store a unique reference to your own order that you can search by. A missing document you issue by hand is far better than a duplicate you cancel by hand.
What to persist on your side
The response contains the details of the created document. As soon as it arrives, store on your own record:
- The document ID and its sequential number
- The document URL (the PDF), so you never have to regenerate it
- A timestamp and the document type
- The full API response, including on success - it is your only evidence if a dispute arises later
Decisions to make before you start
- Who owns the accounting logic? If your system decides when to issue a tax invoice versus a combined invoice-receipt, that decision belongs to the business's accountant, not to the developer.
- VAT. Confirm whether the system expects amounts inclusive or exclusive of VAT, and verify it in the demo against a real document rather than assuming.
- Exempt dealers. An exempt dealer does not issue a tax invoice at all. If your system serves more than one dealer type, that changes the document type code.
- Allocation numbers. The Israeli Tax Authority requires an allocation number for invoices above a threshold amount. Make sure your flow handles this before going live.
EZcount publishes sample code in several languages including PHP, C#, Java, Python, Node.js and Ruby, which shortens the first connection considerably. But the code is the easy part - the decisions above are what determine whether the integration holds up.
Frequently asked questions
Does EZcount have an API?
Yes. EZcount (EasyCount) exposes a REST-style documents API. Document creation is a JSON POST to /api/createDoc, authenticated by sending an api_key and developer_email in the request body. Sample SDKs are published for PHP, C#, Java, Python, Node.js, Ruby and others.
Is there a sandbox for testing EZcount integrations?
Yes - a demo environment at demo.ezcount.co.il with its own API key, using the same endpoint path. Use it for all development and automated testing. A tax document issued by mistake in production cannot be deleted and has to be cancelled through an offsetting document.
How do you cancel an invoice created through the EZcount API?
You do not delete it. You submit the same document again with all values negated - negative amounts - which creates an offsetting document. This is why retry logic needs care: a timed-out request may have succeeded on the server, and blindly retrying produces a duplicate that then needs a manual cancellation.
What is document type 320 in EZcount?
320 is the combined tax invoice and receipt, the document most commonly issued when payment is collected at the time of the order. Other codes seen in the documentation include 333 for a credit note and 400 for a receipt. Always verify the full list against the current official documentation rather than hard-coding from memory, since the choice carries legal meaning.
How should the EZcount API key be stored?
As a server-side secret only - an environment variable or a secrets manager. It does not expire on a fixed schedule and it authorises issuing tax documents on behalf of the business, so it must never appear in source control, logs, or any client-side code. Keep the demo and production keys as separate variables.
Keep reading
Related service
Integrations
Make the systems you already pay for talk to each other.
About the author
Yehonatan Saadia
Freelance automation, web & MVP engineer
I'm Yehonatan Saadia, a senior engineer who builds business automation, custom websites, and MVPs for small and mid-sized companies across the US, Europe, and Israel. These guides come from real client work, not theory.
Work with meHave a project like this?
Tell me what you're trying to automate or build and I'll tell you the fastest reliable way to ship it.