Developer information and tools

• API Documentation
• Developer tools
• EDI File formats
• European Norm
• Universal Business Language – UBL
• Peppol ISO6523 Identifiers

Our goal is to make exchanging electronic business documents as easy and straightforward as possible. The API is suited for all developers regardless of their level of expertise in the field of electronic invoicing and relevant business frameworks.

The Messaging API helps you implement sending or receiving electronic business documents to your business partners. Using MAPI, for example, a supplier can send an invoice to their customer, while a customer can issue an order to their supplier or retrieve an invoice sent to them.

Start by learning more about Transactions and how to send an electronic business document generated from metadata. The requests are authenticated using HTTP Basic Authentication.

The quickest way to try out the Messaging API is through Postman, a flexible and comprehensive tool for developing and testing APIs.

Messaging API – Guided Tour for Transaction Services

This is a step-by-step guide to using Transaction Services for sending and receiving electronic business documents from a backend, such as an ERP system. For more details, check our online documentation: https://apidocs.unimaze.com

Transaction Services are used for creating or parsing electronic business documents with JSON metadata, which abstracts the underlying XML (or EDI) technical specifications. For working with raw XML, please refer to Messaging API – Guided Tour for Messaging Services.

Sending electronic documents

1. Create a random unique identifier (GUID) and store internally. This will become the message identifier (:mid).

2. Prepare the JSON message and submit the business documents using:

• POST /transactions/submit-invoice
• POST /transactions/correct-with-invoice
• POST /transactions/submit-order, etc.

When including additional attachments in the message, ensure the parameter more is set to true. Otherwise set it to false to trigger processing and delivery of the message.

3. Optionally, stream a binary payload as attachment (e.g. timesheet, product description) using:

• POST /messages/:mid/documents

The content type must be a valid MIME type, supported are images, PDF, XLSX, CSV and plain text files. Set more to either true or false depending on if processing can be triggered or not.

4. Check the state of the message any time using:

• GET messages/:mid/status

This will both give delivery information as well as message handling traces. The states: a) Delivered (delivered to endpoint), b) PendingReview (some data may be incorrect, check message errors and warnings) and c) Parked (manually parked) may be considered final states.

5. Store the referenceId parameter for each document for later displaying the document(s) [see Receiving electronic documents, #4]

Receiving electronic documents

1. Fetch a list of pending incoming messages using:

• GET /messages?status=pendingdelivery&transfer=inbound

For each message, make a note of the unique identifier (GUID), the action parameter and the referenceId of the document(s).

2. Based on the action parameter, get business document data in JSON format using:

• GET /transactions/submit-invoice?messageId=:mid
• GET /transactions/correct-with-credit?messageId=:mid
• GET /transactions/submit-order?messageId=:mid, etc.

3. Change the state of the message to delivered using:

• POST /messages/:mid/mark-as-delivered

Generally, marking the message delivered should be done as soon as possible (within hours).

4. To allow a user to view the document, use:

• GET /messages/display/:referenceId (optionally add the ?lang= parameter)