Does Morning (Green Invoice) have an API?

Yes. Morning provides a modern REST API with token-based authentication covering document creation, customers and document status. It is one of the more straightforward Israeli financial systems to integrate with, largely because it was designed as a cloud product from the start. Always work from the current official documentation for exact endpoints and field names, since these change over time.

Which document type should the automation issue?

That is a bookkeeping decision, not a technical one, and it should be made with your accountant before any code is written. Israeli invoicing distinguishes between quotes, orders, delivery notes, tax invoices, receipts and combined invoice-receipts, and each has different legal meaning, numbering and reversal procedure. Map each business trigger to a document type explicitly and encode that mapping as a named constant rather than a value buried in a request.

What happens if the same invoice gets issued twice?

You have a real accounting problem, not a data cleanup task - a duplicate tax document has to be reversed through a proper credit process, and if it reached the customer you also have a service issue. This is why every issuance path must be idempotent: key the operation on your own order reference, check for an already-issued document before calling the API, and store the returned document ID. With that check in place, a retried webhook becomes a no-op instead of a second invoice.

How long does this integration take to build?

A single flow - issue a document when an order is paid, with a proper job queue and error handling - is typically one to two weeks. Adding recurring invoices and customer synchronisation takes it to three or four weeks. Pulling payment status back into a CRM or dashboard adds another couple of weeks. It is one of the cheapest useful integrations available, which is why it makes a good first project.

Should a person still approve invoices after automation?

For the first few weeks, yes. Have the automation create documents in draft and require approval before issuance. This is how you find the data problems that only appear at volume - customer records with malformed tax IDs, shipping charges that should be merged into a line, rounding that does not match what the accountant expects. Once the approval step stops catching anything for a sustained period, remove it.

Automating Invoices with the Morning (Green Invoice) API

Morning is the easiest Israeli invoicing system to automate, which makes it the best first integration for most small businesses. Here is the architecture that works, the document-type trap that catches everyone, and why idempotency matters more here than anywhere else.

Of all the Israeli financial systems a small business might want to automate, Morning (formerly Green Invoice) is the friendliest. It is cloud-native, it has a modern REST API with token-based authentication, and it was built in an era where integration was expected rather than bolted on. That combination makes it the natural first automation project for a lot of businesses.

This guide covers what to automate, the architecture that survives contact with production, and the specific mistakes that turn a two-week project into an accounting cleanup.

What Is Worth Automating

In rough order of value:

Issue a document when an order is paid. Store checkout, payment link, or booking confirmation triggers the document. This removes the most daily manual work.
Recurring monthly invoices. Retainers and subscriptions issued on a schedule from a list, rather than by hand on the first of the month.
Quote to invoice. When a quote is accepted, convert it rather than re-entering the line items.
Payment reconciliation. Pull document and payment status back into your own system so you know what is outstanding without logging in.
Customer sync. Keep the customer list aligned with your CRM so nobody is created twice with slightly different details.

Most businesses only need the first one to justify the whole project.

The Document Type Trap

This is where nearly every first integration goes wrong. Israeli invoicing distinguishes between several document types - quotes, orders, delivery notes, tax invoices, receipts, and the combined invoice-receipt - and they are not interchangeable. They have different legal and accounting meanings, different numbering sequences, and different reversal procedures.

Before writing any code, sit with whoever does your bookkeeping and write down explicitly: for each business event that will trigger automation, which document type should be produced. Put that mapping in the code as a named constant, not as a magic number buried in a request body.

Getting this wrong is not a bug you patch. An incorrectly issued tax document has to be reversed through a proper credit process, and if it has already been sent to the customer, you are also having an awkward conversation.

Architecture That Works

Never call the API directly from a webhook handler

The pattern that fails: payment webhook arrives, handler immediately calls the invoicing API, handler returns. When the API is slow or briefly unavailable, the webhook times out, the payment provider retries, and you issue two invoices.

The pattern that works: webhook arrives, you write an "issue document" job into your own database with the order reference, and acknowledge immediately. A separate worker picks the job up, calls the API, records the resulting document ID, and marks the job complete. Retries are safe because the job is keyed on the order reference.

Idempotency, seriously

Before issuing, check your own database for a document already issued against this order reference. If one exists, return it. This single check is what stands between a network blip and a duplicate tax document.

Store the returned document ID and number against the order. That record is also what your support process needs when a customer asks for their invoice again.

Token handling

Morning's API uses short-lived tokens obtained from long-lived credentials. Do not fetch a new token per request and do not cache one forever. Cache it with its expiry, refresh proactively before it lapses, and handle a 401 by refreshing once and retrying. Credentials belong in a secrets store, never in the repository.

An error queue with the document draft attached

Failures here are usually data problems: a customer with a malformed tax ID, a line item with no price, an amount that does not reconcile. The failed job should be visible with the exact payload and the API's error text, so it can be fixed and retried rather than re-created by hand.

Run It in Draft First

For the first two to four weeks, have the automation create documents in draft and require a person to approve issuance. This is not timidity - it is how you discover that 3% of your customer records have a tax ID with a trailing space, or that your store sends the shipping cost as a separate line the accountant wants merged.

Once the approval step stops catching anything, remove it.

Timeline and Cost

Scope	Typical build
Issue a document on order paid, one trigger, error queue	1-2 weeks
Add recurring invoices and customer sync	3-4 weeks
Add payment reconciliation back into a CRM or dashboard	5-7 weeks

This is one of the cheaper integrations available, which is exactly why it is a good place to start: it proves the pattern, it produces visible daily value, and the team learns what an error queue is for before the stakes get higher.

One Caveat

Invoicing sits inside tax and regulatory territory, and the rules that apply to your business are a question for your accountant, not for a developer. Decide the document mapping and the issuance policy with them, keep a person in the approval loop until you have confidence, and check the current API documentation rather than relying on any guide - including this one - for exact field and endpoint details.

To scope an invoicing automation for your setup, book a free call. Related: how to automate invoicing, the Israeli software stack and what connects to what, and automating invoices and payment reminders.