Invoice4U API: Issuing Invoices Automatically From Your Website or CRM

The Invoice4U API lets a website, online store or CRM issue invoices, receipts and credit notes in Invoice4U automatically. It is a .NET WCF service with a JSON entry point: you POST to https://api.invoice4u.co.il/Services/ApiService.svc/{Operation}, for example CreateDocument, with the parameters and a token. The two things that trip up most integrations are the {"d": ...} response envelope and errors that arrive with HTTP status 200.

Invoice4U is an Israeli invoicing service, also offered through Verifone's payment products. Its official documentation sits on an Apiary page that renders only in a browser, so this guide is built from the service's own published WSDL contract, checked against live responses on 30 September 2026.

How does the Invoice4U API work?

The service exposes one endpoint with 157 operations, listed in its WSDL at ApiService.svc?singleWsdl. It speaks SOAP natively, but you do not need a SOAP client: an ASP.NET JSON entry point accepts a JSON body on the bare operation path.

Operation parameter names come from the contract and are case-sensitive. CreateDocument, CreateDocumentWithIdentifierValidation and SendDocumentByMail take doc and token. CreateCustomer takes cu and token. FetchAllocationNumber takes docId and token.

Invoice4U API example: a tax invoice receipt in one request

A whole tax invoice receipt for a paid order is one POST. The field names and types below are taken from the service contract: DocumentType, ClientID and PaymentType are integers, Quantity, Price and Amount are doubles, and Date is a WCF date. 12345 stands for the Invoice4U customer ID you found or created first.

POST https://apiqa.invoice4u.co.il/Services/ApiService.svc/CreateDocumentWithIdentifierValidation
Content-Type: application/json

{
  "token": "<token>",
  "doc": {
    "DocumentType": 3,
    "ClientID": 12345,
    "Subject": "Order 1042",
    "TaxIncluded": true,
    "ApiIdentifier": "order-1042",
    "IsSendUserMail": true,
    "Items": [
      { "Name": "Monthly plan", "Code": "PLAN-M", "Quantity": 1, "Price": 300 }
    ],
    "Payments": [
      { "PaymentType": 1, "Amount": 300, "Date": "\/Date(1793952000000)\/" }
    ]
  }
}

What each part does: DocumentType: 3 is a tax invoice receipt, so the request carries both the item and the payment, and the two totals must match. PaymentType: 1 is a credit card. ApiIdentifier is your own order number, which makes a retry after a timeout get rejected instead of issuing a second document. IsSendUserMail emails the document to the customer. The answer is the same Document object inside d: read d.Errors first, and only when it is empty save d.DocumentNumber (a long) and d.ID (a GUID) against the order.

Why does a failed Invoice4U call return 200?

Invoice4U reports business errors inside the payload, not in the HTTP status. A call without a valid token returns status 200 with this body:

{"d": {"Errors": [{"Error": "UnauthorizedUser", "ID": 80, "Paramters": null}], "TaxRate": -1}}

So an integration that checks only response.ok records every failure as a success, and an order is marked "invoiced" when no invoice exists. The rule is: read d, and treat any non-empty Errors array as a failure. Note the field name Paramters - it is misspelled in the contract itself, so a strict deserialiser has to match it exactly.

An invalid key is a second case of the same rule. VerifyLoginApiKey with a key that does not exist answered {"d": null}, also with status 200, on both the production and the QA endpoint when we tested it on 7 November 2026. So an empty d is a failure too, not an empty success.

Issuing an invoice from an order, step by step

1. Get an API key from the Invoice4U account owner, and test against the QA endpoint first.
2. Find or create the customer. GetCustomerByEmail looks one up; CreateCustomer takes a cu object with Name, Email, Phone or Cell, Address, City and UniqueID (the ת"ז or ח"פ).
3. Build the doc object: DocumentType, ClientID, Subject, Currency, TaxIncluded, and Items with Name, Code, Quantity and Price.
4. For an invoice-receipt, add Payments with PaymentType, Amount and Date. The totals of items and payments must agree.
5. Set ApiIdentifier to your order id and call CreateDocumentWithIdentifierValidation.
6. Check Errors. On success, store the returned DocumentNumber and document id on the order.
7. Send it to the customer, either with IsSendUserMail on the document or with SendDocumentByMail afterwards.

Which DocumentType codes does Invoice4U use?

DocumentType is a number, and the contract defines these values:

Codes 11 and 12 do not exist, so an integration that counts upward from 10 sends an invalid type. Payment methods are numeric too, in PaymentTypes: 1 credit card, 2 cheque, 3 bank transfer, 4 cash, 8 Bit, 9 PayBox. Which document to issue for which sale is explained in receipt, tax invoice or invoice-receipt.

What goes wrong in an Invoice4U integration

• Duplicate invoices. A timeout on CreateDocument does not mean nothing was issued. The ApiIdentifier route exists so that a retry is rejected instead of producing a second numbered document, which then has to be cancelled with a credit invoice.
• Date formats. WCF's JSON dates are /Date(milliseconds)/, not ISO strings. Serialise dates in that form, and parse them that way on the way back.
• Two amount fields. Money appears twice, for example Total and TotalDecimal, next to a UseDecimalValues flag. Decide which one your integration reads, and check it against a real document before trusting it.
• Allocation numbers. The document carries AllocationNumber, AllocationMessage and ForceGenerateAllocationNumber, and FetchAllocationNumber requests one for an existing document. When an Israeli allocation number is required is set by the Tax Authority, not by the API - see the allocation number API.
• Logging the token. The token rides in the request body, so a debug log of full request bodies leaks it.

The same pattern with another invoicing service is in automating Morning (Green Invoice) through its API, and the payment side in issuing an invoice automatically after payment.

What to have ready before you start

• An Invoice4U API key, and access to the QA environment for testing.
• A decision on which document each sale produces - invoice-receipt at payment, or invoice first and receipt later.
• Customer records with ת"ז or ח"פ where your business needs them.
• VAT handling decided per product: prices with or without VAT (TaxIncluded).
• Somewhere to store the Invoice4U document number against each order.

Sources

• Invoice4U ApiService WSDL contract
• Verifone developer docs - Invoice4U payment documents