AutoInvoice REST API covers the following API’s
You will find more information of the APIs below. Before you continue, make sure you have read our Integration guide
How to get started and get the necessary keys to set up the integration is explained in our Integration guide
You will also also find there feature specific guides for sending, receiving, companies and settings, services and networks and billing that list what API method to use for different tasks.
Detailed technical documentation can be found at swagger.maventa.com. Select the environment and correct API in the top-right corner of the page and you will find a full list of methods with detailed descriptions of parameters and responses.
You can also try out the API directly in your browser with the Swagger user interface. Just click the “Authorize” button first and then “Try it out” button found under each method.
Updated at 15.02.2024
This example has a collection with all the available endpoints and an example environment.
In order to use the collection successfully:
baseUrl
and tokenUrl
are given in collection’s (the parent) Variables tab.BearerToken
and as Token it uses the environment variable access_token
which is created when you call the token endpoint.scope
, client_id
, client_secret
, vendor_api_key
).POST /oauth2/token
endpoint to get access_token
environment variable created to your environment variables. In Tests tab there is a step that sets the access_token
from response to a environment variabel.
No Auth
in the Authorization tabInherits auth from the parent
Authentication to REST API is based on the Oauth2 standard. Using of all API functions requires a valid Oauth2 bearer token, retrievable with the user_api_key and company_id . Expiry is set on server side and the mechanism to handle the expiry of the token is suggested to be handled gracefully on the client side.
The endpoint for aquiring the token is POST /oauth2/token. This endpoint provides authentication to all of the AutoInvoice REST APIs.
POST /oauth2/token
expires_in
field
Authenticating requires a user_api_key and company_id. To create an account in testing, registrations can be done in AutoInvoice Web UI, then logging in, and navigating to settings.
Also you need a vendor_api_key. When you have registered a company account in testing, contact your integration contact point or Maventa support to convert your account into a partner account and create a vendor_api_key for you.
Call the POST /oauth2/token
method with company credentials:
Notes:
Call the POST /oauth2/token
method with operator credentials:
The client should always handle any server/connection issues gracefully. Do not lock up or throw exceptions directly at your users. There can be both scheduled and unscheduled breaks in the service which should be handled on the client side, for example with messages like “Service unavailable, please try again later”.
AutoXChange API (also known as AX API) can be used to create companies, send and receive invoices, orders and other trading documents, register webhooks and activate different networks and services such as Peppol or Scan. It also includes Detect, a service that performs automatic checks and analysis on invoices.
All companies using AutoInvoice have an own account that is registered with unique business ID and company details. After registration company settings can be configured, including activation of different services and networks. Before account is ready to be used fully, it needs to be verified to ensure Know Your Customer process has been completed.
You can register webhooks to monitor when company authrization status changes, and when services and networks gets activated.
Register company as invoice or document receiver and activate services. The endpoint for profile registrations is POST /v1/company/profiles
You can also use webhooks to get notifications when the registration status changes.
Networks to register
VISMA
- Internal invoice receiving. This network needs to be enabled to be able to receive invoices also via other networks like Peppol and scan.PEPPOL
- Receiving in the Peppol network. Read more about Peppol registrations here.BANK
- Sending and receiving in the Finnish bank network. Only for Finnish companies. Request to activate is sent automatically when company completes the customer authentication process. Activation takes typically from 1-3 days.SCAN
- Receiving from scan service activated via AutoInvoice. Read more about scan service from here.SCAN_DOCUMENTS
(or VISMASCANNER) - Receiving other documents than invoices via scan applications (Visma Scanner mobile application, DocScan web application)
VOUCHER
RECEIVABLES
- DEPRECATED - Use PUT /v1/services/receivables for receivables management service activation. Read more about the service from here.INEXCHANGE
- Profile for operator InExchange - usage agreed separately.NEMHANDEL
- Profile for Nemhandel registrations - usage agreed separately.AISPROOM
- Profile for operator Sproom - internal use only.Profiles not visible in this list are deprecated or in experimental stage. Please contact your integration contact point if you have further questions.
Below you can find examples of how to register networks and profiles
Invoices are sent by providing an XML file and specifying other necessary data for send as parameters on the api call.
direction=SENT
or GET /v1/invoices/{id}to poll status of sent documents to see those are either delivered successfully or failed in delivery. You can also use webhooks to get notifications of invoices states.NOTE! Sending or receiving of invoices is not allowed if company_state is unverified (-1) and API will return error message “Unauthorized”. Invoices can be sent after the authorization is done.
See more guidance and recommended routine for invoice sending in Integration guide
Check supported invoice formats from here and some example XML files from here.
To receive invoices, register the company first as invoice receiver, like this.
Invoices are received by listing new incoming invoices in AutoInvoice and then downloading the invoice and attachments into the financial system.
direction=RECEIVED
, received_at_start
, and received_at_end
to get list of invoices available for download. It is possible to use the param fields
to limit the amount of data returned on the response. You can also use webhooks to get notifications of received invoices.See more guidance and recommended routine for invoice receiving in Integration guide
To enable receiving of documents from Peppol. Use the POST /v1/company/profiles endpoint.
Example request:
{
"network":"PEPPOL",
"profiles":["INVOICE_AND_CREDIT_NOTE"]
}
Example response:
{
"id": "ce2e8bda-355a-4e58-b2be-830c434b8ab9",
"status": "pending",
"profiles": [
"INVOICE_AND_CREDIT_NOTE"
],
"profile_version": null,
"endpoint_id": "003712345678",
"scheme": "0216",
"network": "PEPPOL"
}
The identifier used when registering varies depending on the country and what kind of identifier has been used to when the company was created. The current defaults are listed in the table below.
Country | scheme |
---|---|
Norway | 0192 (NO:ORG) |
Sweden | 0007 (SE:ORGNR) |
Finland | 0216 (FI:OVT2) |
Denmark | 0182 (DK:DIGST) |
The Netherlands | 0106 (NL:KVK), 9944 (NL:VAT) |
The Peppol identifier (scheme
and endpoint_id
) to be used for receiving will be automatically resolved from identifiers associated with the company. In addition to the defaults it is possible to register alternative or additional identifiers such as GLN, please contact your integration support for more information.
To enable receiving of invoices and credit notes from Peppol. The profile to use when registering is INVOICE_AND_CREDIT_NOTE
.
Note: Receiving of invoices in the VISMA
network should have been enabled before Peppol receiving can be enabled. See the Invoice receiving guide for details.
The receiving of ordering and other document types can also be enabled using this endpoint. In these cases it’s also required to specify the desired profile version (profile_version
) in the request. Note: Make sure the system integrating is able to process the requested profile version. See Document receiving for details.
Example request:
{
"network":"PEPPOL",
"profiles":["INVOICE_RESPONSE"],
"profile_version":"PEPPOLBIS30"
}
Supported profiles and versions:
profile | profile_version | Supported markets | Notes |
---|---|---|---|
ORDER | PEPPOLBIS30, EHF30 | FI, NO, SE, DK, NL | |
ORDER_RESPONSE | PEPPOLBIS30, EHF30 | FI, NO, SE, DK, NL | |
CATALOGUE | PEPPOLBIS30, EHF30 | FI, NO, SE, DK, NL | |
CATALOGUE_RESPONSE | PEPPOLBIS30, EHF30 | FI, NO, SE, DK, NL | |
DESPATCH_ADVICE | PEPPOLBIS30, EHF30 | FI, NO, SE, DK, NL | |
REMINDER | PEPPOLBIS30, EHF30 | FI, NO, SE, DK, NL | |
INVOICE_RESPONSE | PEPPOLBIS30 | FI, NO, SE, DK, NL, BE | |
MESSAGE_LEVEL_RESPONSE | PEPPOLBIS30 | FI, NO, SE, DK, NL, BE | |
DEPRECATED: Use INVOICE_AND_CREDIT_NOTE | |||
DEPRECATED: Use INVOICE_AND_CREDIT_NOTE |
EHF30 is a Norwegian national format and should be preferred for Norwegian customers.
{
"network_settings": {
"return_email":"example@example.com",
"return_address":{
"post_code":"00000",
"post_office":"cityX",
"street_address":"Street 1"
},
"other_docs":false
},
"network":"SCAN",
"profiles":["INVOICE_AND_CREDIT_NOTE"]
}
To work on preventing invoice fraud, AutoInvoice supports functionality to report us receiving of suspected fraudulent invoices.
Integrators can add the reporting functionality into their system to give the users an easy way to do reports in the context of the invoice handling.
See more guidance and example flow for fraud reporting in Integration guide
Note that this endpoint is meant for other trading documents than invoices and credit notes, such as order documents, vouchers and reminders. For exchanging invoices and credit notes see Invoice Exchange. Please also note that format conversions and full look up features are not supported for this endpoint.
Documents are sent by sending a document file, usually an XML, and specifying other necessary data as parameters on the api call.
POST /v1/documents
to send a document, getting back a document ID in returnGET /v1/documents/{id}
to poll status of sent documents to see those are either delivered successfully or failed in delivery. You can also use webhooks to get notifications of document statesCurrently POST /v1/documents
does not provide automatic lookup features, so in order to send a document both the recipient and the operator needs to be specified during the send. This can be done by specifying the recipient and recipient operator as parameters in the POST call. Recipient information is also parsed from supported XML file formats.
To receive documents, register first the company as document receiver, like this.
Documents are received by listing new incoming documents in AutoInvoice and then downloading the document and attachments into the financial system.
direction=RECEIVED
, received_at_start
, and received_at_end
to get list of documents available for download. It is possible to use the param fields
to limit the amount of data returned on the response.AutoInvoice supports registering webhooks. Using the AX API you can subscribe to certain type of events, and when that event happens we will send a HTTP POST request to the endpoint you defined.
Currently the event types are following:
We expect HTTP 200, 201 or 204 responses when the server has successfully handled the event. If for some reason the response is something else or the server is unavailable we will retry the request every hour for 24 hours.
The requests are expected to finish in under 5 seconds, requests that timeout are considered as failures and will be retried. No long running processing should ever be done in the webhook request.
Even though we try to call your webhook endpoint multiple times, nothing is 100% guaranteed, so we recommend still having a fallback routine in place. For example for invoices you can use SOAP API’s sent_invoices_status or REST API’s GET /v1/invoices to check for any unfetched or pending invoices, to be sure nothing was left behind in case handling a webhook has failed.
Below you can find examples of the payload we send to your webhook address when something happens. It is possible to add more details, so if you have any ideas what would be useful, just contact AutoInvoice support.
Subscribing to events happens through the POST /v1/company/notifications endpoint.
Once you have authenticated as a company you can call this endpoint to register a webhook for that particular company.
We have also a possibility to register webhooks for partners (aka vendor webhooks).
When a registration is done for a partner it covers all the companies that have been linked to the partner company’s vendor api key. The registration for a partner is a one time operation, after the registration is active the endpoint registered will receive events for all companies associated with the partner. This is the recommended way for partners to register their webhooks. Linking and unlinking the vendor api key is a requirement for this feature to fully function. More about partner accounts here.
If you want to register webhooks for a partner, authenticate with the partner company credentials and specify destination_type
as VENDOR_WEBHOOK
when subscribing to the events.
Key | Type | Description |
---|---|---|
destination_type | string | Type of the hook WEBHOOK or VENDOR_WEBHOOK |
destination | string | Endpoint url |
There is a third posibility to register vendor webhooks based on vendor key.
This registration allows you to filter notifications based on vendor keys. This is helpful if you own multiple vendor api keys, and want notifications separately.
Registering based on vendor keys requires you to pass vendor_key
in the payload.
Key | Type | Description |
---|---|---|
destination_type | string | VENDOR_WEBHOOK |
destination | string | Endpoint url |
vendor_key | string | your_vendor_key |
It might be a good idea to include some sort of authorization in your URL to ensure that the messages sent to your endpoint are really from us.
Use can use:
https://user:examplesecret@your-erp.com/webhooks
https://your-erp.com/webhooks?secret=examplesecret
Please note that the webhook endpoint needs to support TLS 1.2. Older versions such as SSLv2, SSLv3, TLS 1.0 and TLS 1.1 are not supported.
Scope for the /oauth2/token: company
PUT /v1/services/op_invoice_credit
start the OP Laskulaina onboarding.GET /v1/services/op_invoice_credit
to finalize the activation and get the current information about the serviceGET /v1/services/op_invoice_credit/available_credit
to check the credit balancePOST /v1/services/op_invoice_credit/withdrawal
to make a withdrawalPOST /v1/services/op_invoice_credit/direct_payment
to inform OP about a direct payment to company’s own accountGET /v1/services/op_invoice_credit/account_statement
to fetch the account statement (SEPA XML)See more guidance for OP Laskulaina - Invoice credit service in Integration guide
Scope for the /oauth2/token: analysis
PATCH /v1/services/detect/checks
to activate and deactivate checksGET /v1/services/detect/checks
to see check activation statusGET /v1/definitions/detect/checks
to see all available checks, their description and possible result messagesGET /v1/analysis/{id}
to fetch the check results with invoice idSee more guidance for Detect service in Integration guide
You will find more information about the data type definitions used by this API from /v1/definitions
namespace.
Some of these methods are publicly available, others will require an authenticated API user.
GET /v1/definitions/detect/checks
to see all available checks, their description and possible result messagesGET /v1/definitions/operators
to list all the currently supported roaming operators and their operator codes.
The Validator API can be used for validation service, which provides XML schema and schematron validations for XML business documents.
Receivables API is used for Receivables management service. The service helps to automate the debt collection process and is currently available for Finnish customers.
See more information of and integrating instructions for the service in the Integration guide
Detailed technical information in Swagger: Receivables API technical documentation
For using Receivables API the authentication scope receivables:assignments is required.
PUT /v1/services/receivables
to initiate the activation of Receivables Management service.GET /v1/services/receivables
to fetch the status of the activation to see when the service is activated. Or register a webhook to get a event from AutoInvoice when the service gets activated (or rejected).PATCH /v1/services/receivables
to change the setting for using own invoice image and own payments details with the serviceMore information about the assignments and event usage is explained in the Integration guide
GET /v1/assignments
to list and get all the assignments and their events based on given filtering parameters (e.g. debtor name, assignment creation date, closing date..).GET /v1/assignments/{assignment_id}
to fetch one assignment and it’s events.GET /v1/assignments/{assignment_id}/events
to fetch only events related to the one assignment.GET /v1/assignments/overview
to fetch an overview of assignments (how many assignments are all together open, how many are soon to due and how many are already dued. See an example implementation)POST /v1/assignments/{assignment_id}/events
to add a new event to an assignment (e.g. mark direct payment, request due date change, cancel assignment..)POST /v1/assignments/{assignment_id}/events/{event_id}/seen
to mark event as seenGET /v1/events
to list assignment eventsGET /v1/service_levels
to list the service levels for all of your customers. This method will only return customers that have a special service level set (premium, vip or service_bypass), the default service level is named “default” and that applies to every customer that does not have a service level. There is no way to list customers with the default service level.GET /v1/service_levels/{customer_bid}
to get service level for specific customer (with customer bid)PATCH /v1/service_levels/{customer_bid}
to set service level for customer (with customer bid)Messaging functionality is used for the communication between Visma Amili and the customer. It is highly recommended to add this functionality as part of the integration to make sure both parties have a functional discussion connection and important messages do not get lost.
API endpoints for messaging functionality
GET /v1/message_threads - Lists all the message threads (shown latest message from each of the message thread)
PATCH /v1/message_threads/{thread_id} - Flag a message thread
GET /v1/message_threads/{thread_id} - Show message thread information (shows only the latest message)
GET /v1/message_threads/{thread_id}/messages - Show all the messages inside a message thread
POST /v1/message_threads/{thread_id}/messages - Add a message to a message thread
POST /v1/assignments/{assignment_id}/messages - Add a message for an assignment (this will create message thread if one does not exist yet, or add a new message to an existing message thread)
GET /v1/assignments/{assignment_id}/messages - Show all the messages for an assignment
PUT /v1/messages/{message_id}/seen - Mark a message as seen
AutoInvoice Direct Print (also known as Payslip) is a service that enables sending of EPL and PDF files as letters through the printing service in Finland. Service was initially build to send payslip material, but it can be used for sending any kind of letters, as long as the printing service rules are followed.
See more information of the Mass printing service (Payslip) in the Integration guide
Stage: https://payslip-stage.maventa.com
Prod: https://payslip.maventa.com
Use POST /register
to activate the service
Authentication as HTTP headers with on of the following authentication keys:
USERNAME
and USERPW
with which you registered your Direct Print API accountCOMPANY-UUID
and USER-API-KEY
of your AutoInvoice accountUse POST /input_public
to send zip package
Use POST /file_status
to check the status of the sent package