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.
Key takeaways
- Automating invoice issuance is the highest-ROI first integration for most small Israeli businesses - it is small, it runs daily, and manual issuance is where errors are most expensive.
- Pick the right document type before you write code. Issuing a tax invoice where a receipt or a quote was intended is a bookkeeping problem, not a bug you can just fix.
- Every issuance call must be idempotent and keyed on your own order reference. A retried request that issues a second invoice creates a document you cannot simply delete.
- Run it in draft mode first. Generate documents automatically but have a person approve issuance for the first few weeks - the bugs you find will be in your data, not in the API.
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.
How do you connect Morning (Green Invoice) to a CRM or a business website?
Through the Morning API: create an API key in Morning's developer settings, exchange it for a one-hour access token, and have the website or CRM send POST /documents with the document type, client and income rows. A payment/received or document/created webhook updates the CRM in return. We build these connections; one such workflow is priced at $300 - $1,800.
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 Morning API at a glance: URLs, token and document codes
These values come from Morning's developer documentation at developers.morning.co; the old greeninvoice.co.il/api-docs address now redirects there.
| Item | Value |
|---|---|
| Production base URL | https://api.greeninvoice.co.il/api/v1 |
| Sandbox base URL | https://sandbox.d.greeninvoice.co.il/api/v1, with its own set of API keys |
| Access token | POST https://api.morning.co/idp/v1/oauth/token with grant_type: client_credentials, client_id and client_secret; in the sandbox the host is https://api.sandbox.morning.dev |
| Token lifetime | The returned accessToken is valid for one hour and goes in Authorization: Bearer |
| Create a document | POST /documents; required fields: type, lang, currency, vatType, income |
| Income row | Required: description, quantity, price, currency, vatType |
| Receipt for an existing invoice | Pass the invoice id in linkedDocumentIds, and Morning closes the original invoice |
The document type is a number. The codes most integrations use:
10- quote (הצעת מחיר)300- proforma invoice (חשבון עסקה)305- tax invoice (חשבונית מס)320- tax invoice-receipt (חשבונית מס / קבלה)330- credit note (חשבונית זיכוי)400- receipt (קבלה)
API access also depends on the subscription. The token endpoint answers unauthorized_client when the plan does not include API access, and at the time of writing Morning's pricing page lists API, integrations and webhooks from the Best plan up.
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.
Morning webhooks: what they send and how to verify them
Morning webhooks are set up in the Morning interface, under Developer Tools and then Webhooks, not through an API call. Each subscribed event arrives as an HTTP POST with a JSON body. The events that matter for a CRM or a website are document/created, payment/received and client/created.
- Verify the signature. When the webhook has a secret, each delivery carries
x-webhook-signature: the HMAC-SHA256 of the raw body, hex-encoded. Compute it over the raw bytes before any JSON parsing, because re-serialised JSON no longer matches. - Deduplicate on
x-webhook-delivery-id, the unique id of each delivery. - Acknowledge quickly with 200, 201, 202 or 204. Any other status, a redirect or a timeout counts as a failed delivery, and after 15 failures the webhook becomes inactive and stops sending.
That last rule is why the job-queue pattern above matters twice. A handler that does slow work inline risks duplicate documents, and over time it can switch the webhook off with nothing in your own system saying so. A nightly check that lists recent documents through POST /documents/search catches what a dead webhook missed.
Which Morning API errors will you actually hit?
Morning returns error messages in Hebrew alongside a numeric code, so branch on the code. The ones that come up in invoicing integrations:
| Code | Meaning |
|---|---|
| 401 | Access denied - usually an expired one-hour token |
| 1007 | Missing permission |
| 1010 | A request with identical data already exists |
| 1108 | Invalid VAT rate; it must be between 0 and 1, so 0.18 rather than 18 |
| 1111 | Invalid dealer or company number |
| 1112 | The account has issued its maximum number of documents for this month |
| 1119 | A search page size above 100 |
Code 1112 deserves an alert of its own: an automation that suddenly issues more documents than usual can hit it, and from then on nothing new is issued until the account is sorted out.
Run It in Draft First
For the first one to two 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 | 2 - 3 weeks |
| Add payment reconciliation back into a CRM or dashboard | 3 - 4 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, connecting invoicing software to a CRM, and the Israeli invoicing API comparison.
Sources
Frequently asked questions
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.
Does the Morning (Green Invoice) API have a sandbox?
Yes. The sandbox base URL is https://sandbox.d.greeninvoice.co.il/api/v1, and tokens for it come from https://api.sandbox.morning.dev. Each environment needs its own API keys, so production keys will not work in the sandbox. Morning recommends building and testing the integration there before switching to production.
How long is a Morning API access token valid?
One hour. The token endpoint returns an accessToken, a signed JWT scoped to the business of your API keys. After an hour, calls return 401 Unauthorized and you request a new token with the same client_id and client_secret. Cache the token with its expiry and refresh it shortly before it lapses.
Which Morning plan includes API access?
At the time of writing, Morning's pricing page lists automation through API, integrations and webhooks in the Best and Extra plans, and Prime includes everything in Extra; Basic does not list it. When a plan lacks API access, the token endpoint answers with the error unauthorized_client.
Keep reading
Related service
Integrations
Make the systems you already pay for talk to each other.
Have a project like this?
Tell me what you're trying to automate or build. I reply within 24 business hours with a few targeted questions, then we walk through it on a free 30-minute call, with no commitment. You come away with a scope, a timeline and a fixed price - or a straight answer that it isn't worth building.