Every API here is available over the APIs.io API and to AI agents over MCP.
openapi: 3.2.0
info:
title: Visma.net ERP Customer Contract API
version: v1
servers:
- url: https://api.finance.visma.net
tags:
- name: Customer Contract
paths:
/v1/customerContract/{contractId}:
get:
tags:
- Customer Contract
summary: Get a specific Customer Contract
description: 'Data for the customer contract
The response headers include an ETag after a successful GET operation.'
operationId: CustomerContract_GetCustomerContractBycontractId
parameters:
- name: contractId
in: path
description: Identifies the customer contract
required: true
schema:
type: string
- name: erp-api-background
in: header
description: 'Accepts the request and queues it to be executed in the background by our least busy worker. Responds with 202 Accepted and a document containing a JobId reference and details state location.
Supported values:
* a URL: when the background operation is finished, a notification will be posted to the URL with a document containing a reference id, status code and a details state location.
* "none" (without quotes): Fire and forget; no notification will be sent when background operation is finished.
* "subscription[:<name_1>=<value_1>,..,<name_n>=<value_n>]" (without quotes): when the background operation is finsihed, a notification is posted to the Webhook subscription set up in Developer Portal for your integration client.
Optionally a set of name-value pairs can be added. These will be sent as headers in the POST request to the Webhook subscription''s url.
To find status and details of a background-api operation, GET .. v1/background/{id}. To get the response payload of a background-api operation, if any, GET .. v1/background/{id}/content'
schema:
type: string
responses:
'200':
description: OK
content:
application/json:
schema:
$ref: '#/components/schemas/CustomerContractDto'
text/json:
schema:
$ref: '#/components/schemas/CustomerContractDto'
'202':
description: Server accepted and queued the request for background execution.
content:
application/json:
schema:
$ref: '#/components/schemas/BackgroundApiAcceptedDto'
text/json:
schema:
$ref: '#/components/schemas/BackgroundApiAcceptedDto'
security:
- interactiveapi: []
put:
tags:
- Customer Contract
summary: Update a specific CustomerContract
description: 'Response Message has StatusCode NoContent if PUT operation succeed
Response Message has StatusCode BadRequest if PUT operation failed
In this endpoint, If-Match can be checked against resource current version when calling with ''erp-api-background'' HTTP header.'
operationId: CustomerContract_PutBycontractId
parameters:
- name: contractId
in: path
description: Identifies the CustomerContract to update
required: true
schema:
type: string
- name: erp-api-background
in: header
description: 'Accepts the request and queues it to be executed in the background by our least busy worker. Responds with 202 Accepted and a document containing a JobId reference and details state location.
Supported values:
* a URL: when the background operation is finished, a notification will be posted to the URL with a document containing a reference id, status code and a details state location.
* "none" (without quotes): Fire and forget; no notification will be sent when background operation is finished.
* "subscription[:<name_1>=<value_1>,..,<name_n>=<value_n>]" (without quotes): when the background operation is finsihed, a notification is posted to the Webhook subscription set up in Developer Portal for your integration client.
Optionally a set of name-value pairs can be added. These will be sent as headers in the POST request to the Webhook subscription''s url.
To find status and details of a background-api operation, GET .. v1/background/{id}. To get the response payload of a background-api operation, if any, GET .. v1/background/{id}/content'
schema:
type: string
- name: If-Match
in: header
description: 'The If-Match HTTP header allows clients to update a resource only if its current version matches a specific ETag. This mechanism helps prevent conflicts when multiple clients attempt to modify the same resource simultaneously.
The If-Match header should be included in the request headers using the following syntax: If-Match: "etag_value"
* If the update is successful, the server responds with 204 No Content and includes the new ETag value in the response headers.
* If the ETag on the server does not match the value provided in the If-Match header, the server responds with 412 Precondition Failed.'
schema:
type: string
requestBody:
description: Defines the data for the CustomerContract to update
content:
application/json:
schema:
$ref: '#/components/schemas/CustomerContractUpdateDto'
text/json:
schema:
$ref: '#/components/schemas/CustomerContractUpdateDto'
application/xml:
schema:
$ref: '#/components/schemas/CustomerContractUpdateDto'
text/xml:
schema:
$ref: '#/components/schemas/CustomerContractUpdateDto'
application/x-www-form-urlencoded:
schema:
$ref: '#/components/schemas/CustomerContractUpdateDto'
required: true
x-bodyName: customerContract
responses:
'204':
description: NoContent
content:
application/json:
schema:
type: object
text/json:
schema:
type: object
'412':
description: Customer contract version does not match with If-Match header
content:
application/json: {}
text/json: {}
'202':
description: Server accepted and queued the request for background execution.
content:
application/json:
schema:
$ref: '#/components/schemas/BackgroundApiAcceptedDto'
text/json:
schema:
$ref: '#/components/schemas/BackgroundApiAcceptedDto'
security:
- interactiveapi: []
/v1/customerContract:
get:
tags:
- Customer Contract
summary: Get a range of Customer Contracts, a filter needs to be specified…
operationId: CustomerContract_GetAll
parameters:
- name: greaterThanValue
in: query
schema:
type: string
- name: numberToRead
in: query
schema:
type: integer
format: int32
- name: skipRecords
in: query
schema:
type: integer
format: int32
- name: orderBy
in: query
schema:
type: string
- name: lastModifiedDateTime
in: query
schema:
type: string
- name: lastModifiedDateTimeCondition
in: query
schema:
type: string
- name: contractTemplate
in: query
schema:
type: string
- name: status
in: query
schema:
enum:
- Draft
- InApproval
- Active
- Expired
- Canceled
- Completed
- InUpgrade
- PendingActivation
type: string
- name: customer
in: query
schema:
type: string
- name: expandSummary
in: query
schema:
type: boolean
- name: expandDetails
in: query
schema:
type: boolean
- name: attributes
in: query
description: " Attributes (additional information) connected to the entity.\n Examples:\n{{base}}/customerContract?attributes={\"AttributeID\":\"ValueID\",\"AttributeID\":\"ValueID\"}\n{{base}}/customerContract?attributes={\"AttributeID\":\"ValueID1,ValueID2\"}"
schema:
type: string
- name: expandAttributes
in: query
schema:
type: boolean
- name: erp-api-background
in: header
description: 'Accepts the request and queues it to be executed in the background by our least busy worker. Responds with 202 Accepted and a document containing a JobId reference and details state location.
Supported values:
* a URL: when the background operation is finished, a notification will be posted to the URL with a document containing a reference id, status code and a details state location.
* "none" (without quotes): Fire and forget; no notification will be sent when background operation is finished.
* "subscription[:<name_1>=<value_1>,..,<name_n>=<value_n>]" (without quotes): when the background operation is finsihed, a notification is posted to the Webhook subscription set up in Developer Portal for your integration client.
Optionally a set of name-value pairs can be added. These will be sent as headers in the POST request to the Webhook subscription''s url.
To find status and details of a background-api operation, GET .. v1/background/{id}. To get the response payload of a background-api operation, if any, GET .. v1/background/{id}/content'
schema:
type: string
responses:
'200':
description: OK
content:
application/json:
schema:
type: array
items:
$ref: '#/components/schemas/CustomerContractDto'
text/json:
schema:
type: array
items:
$ref: '#/components/schemas/CustomerContractDto'
'202':
description: Server accepted and queued the request for background execution.
content:
application/json:
schema:
$ref: '#/components/schemas/BackgroundApiAcceptedDto'
text/json:
schema:
$ref: '#/components/schemas/BackgroundApiAcceptedDto'
security:
- interactiveapi: []
post:
tags:
- Customer Contract
summary: Create a CustomerContract
description: 'Response Message has StatusCode Created if POST operation succeed
Response Message has StatusCode BadRequest or InternalServerError if POST operation failed
The response headers include an ETag after a successful POST operation.'
operationId: CustomerContract_CreateCustomerContract
parameters:
- name: erp-api-background
in: header
description: 'Accepts the request and queues it to be executed in the background by our least busy worker. Responds with 202 Accepted and a document containing a JobId reference and details state location.
Supported values:
* a URL: when the background operation is finished, a notification will be posted to the URL with a document containing a reference id, status code and a details state location.
* "none" (without quotes): Fire and forget; no notification will be sent when background operation is finished.
* "subscription[:<name_1>=<value_1>,..,<name_n>=<value_n>]" (without quotes): when the background operation is finsihed, a notification is posted to the Webhook subscription set up in Developer Portal for your integration client.
Optionally a set of name-value pairs can be added. These will be sent as headers in the POST request to the Webhook subscription''s url.
To find status and details of a background-api operation, GET .. v1/background/{id}. To get the response payload of a background-api operation, if any, GET .. v1/background/{id}/content'
schema:
type: string
requestBody:
description: Defines the data for the CustomerContract to create
content:
application/json:
schema:
$ref: '#/components/schemas/CustomerContractUpdateDto'
text/json:
schema:
$ref: '#/components/schemas/CustomerContractUpdateDto'
application/xml:
schema:
$ref: '#/components/schemas/CustomerContractUpdateDto'
text/xml:
schema:
$ref: '#/components/schemas/CustomerContractUpdateDto'
application/x-www-form-urlencoded:
schema:
$ref: '#/components/schemas/CustomerContractUpdateDto'
required: true
x-bodyName: customerContract
responses:
'201':
description: Created
content:
application/json:
schema:
type: object
text/json:
schema:
type: object
'202':
description: Server accepted and queued the request for background execution.
content:
application/json:
schema:
$ref: '#/components/schemas/BackgroundApiAcceptedDto'
text/json:
schema:
$ref: '#/components/schemas/BackgroundApiAcceptedDto'
security:
- interactiveapi: []
/v1/customerContract/{contractId}/summary:
get:
tags:
- Customer Contract
summary: Get a specific Customer Contract Summary
operationId: CustomerContract_GetCustomerContractSummaryBycontractId
parameters:
- name: contractId
in: path
description: Identifies the customer contract
required: true
schema:
type: string
- name: erp-api-background
in: header
description: 'Accepts the request and queues it to be executed in the background by our least busy worker. Responds with 202 Accepted and a document containing a JobId reference and details state location.
Supported values:
* a URL: when the background operation is finished, a notification will be posted to the URL with a document containing a reference id, status code and a details state location.
* "none" (without quotes): Fire and forget; no notification will be sent when background operation is finished.
* "subscription[:<name_1>=<value_1>,..,<name_n>=<value_n>]" (without quotes): when the background operation is finsihed, a notification is posted to the Webhook subscription set up in Developer Portal for your integration client.
Optionally a set of name-value pairs can be added. These will be sent as headers in the POST request to the Webhook subscription''s url.
To find status and details of a background-api operation, GET .. v1/background/{id}. To get the response payload of a background-api operation, if any, GET .. v1/background/{id}/content'
schema:
type: string
responses:
'200':
description: OK
content:
application/json:
schema:
$ref: '#/components/schemas/CustomerContractSummaryDto'
text/json:
schema:
$ref: '#/components/schemas/CustomerContractSummaryDto'
application/xml:
schema:
$ref: '#/components/schemas/CustomerContractSummaryDto'
text/xml:
schema:
$ref: '#/components/schemas/CustomerContractSummaryDto'
'202':
description: Server accepted and queued the request for background execution.
content:
application/json:
schema:
$ref: '#/components/schemas/BackgroundApiAcceptedDto'
text/json:
schema:
$ref: '#/components/schemas/BackgroundApiAcceptedDto'
application/xml:
schema:
$ref: '#/components/schemas/BackgroundApiAcceptedDto'
text/xml:
schema:
$ref: '#/components/schemas/BackgroundApiAcceptedDto'
security:
- interactiveapi: []
/v1/customerContract/{contractId}/details:
get:
tags:
- Customer Contract
summary: Get a specific Customer Contract Details
operationId: CustomerContract_GetCustomerContractDetailsBycontractId
parameters:
- name: contractId
in: path
description: Identifies the customer contract
required: true
schema:
type: string
- name: erp-api-background
in: header
description: 'Accepts the request and queues it to be executed in the background by our least busy worker. Responds with 202 Accepted and a document containing a JobId reference and details state location.
Supported values:
* a URL: when the background operation is finished, a notification will be posted to the URL with a document containing a reference id, status code and a details state location.
* "none" (without quotes): Fire and forget; no notification will be sent when background operation is finished.
* "subscription[:<name_1>=<value_1>,..,<name_n>=<value_n>]" (without quotes): when the background operation is finsihed, a notification is posted to the Webhook subscription set up in Developer Portal for your integration client.
Optionally a set of name-value pairs can be added. These will be sent as headers in the POST request to the Webhook subscription''s url.
To find status and details of a background-api operation, GET .. v1/background/{id}. To get the response payload of a background-api operation, if any, GET .. v1/background/{id}/content'
schema:
type: string
responses:
'200':
description: OK
content:
application/json:
schema:
$ref: '#/components/schemas/CustomerContractDetailsDto'
text/json:
schema:
$ref: '#/components/schemas/CustomerContractDetailsDto'
application/xml:
schema:
$ref: '#/components/schemas/CustomerContractDetailsDto'
text/xml:
schema:
$ref: '#/components/schemas/CustomerContractDetailsDto'
'202':
description: Server accepted and queued the request for background execution.
content:
application/json:
schema:
$ref: '#/components/schemas/BackgroundApiAcceptedDto'
text/json:
schema:
$ref: '#/components/schemas/BackgroundApiAcceptedDto'
application/xml:
schema:
$ref: '#/components/schemas/BackgroundApiAcceptedDto'
text/xml:
schema:
$ref: '#/components/schemas/BackgroundApiAcceptedDto'
security:
- interactiveapi: []
/v1/customerContract/{contractId}/recurringSummary:
get:
tags:
- Customer Contract
summary: Get a specific Customer Contract Recurring Summary
operationId: CustomerContract_GetCustomerContractRecurringSummaryBycontractId
parameters:
- name: contractId
in: path
description: Identifies the customer contract
required: true
schema:
type: string
- name: erp-api-background
in: header
description: 'Accepts the request and queues it to be executed in the background by our least busy worker. Responds with 202 Accepted and a document containing a JobId reference and details state location.
Supported values:
* a URL: when the background operation is finished, a notification will be posted to the URL with a document containing a reference id, status code and a details state location.
* "none" (without quotes): Fire and forget; no notification will be sent when background operation is finished.
* "subscription[:<name_1>=<value_1>,..,<name_n>=<value_n>]" (without quotes): when the background operation is finsihed, a notification is posted to the Webhook subscription set up in Developer Portal for your integration client.
Optionally a set of name-value pairs can be added. These will be sent as headers in the POST request to the Webhook subscription''s url.
To find status and details of a background-api operation, GET .. v1/background/{id}. To get the response payload of a background-api operation, if any, GET .. v1/background/{id}/content'
schema:
type: string
responses:
'200':
description: OK
content:
application/json:
schema:
$ref: '#/components/schemas/CustomerContractRecurringSummaryDto'
text/json:
schema:
$ref: '#/components/schemas/CustomerContractRecurringSummaryDto'
application/xml:
schema:
$ref: '#/components/schemas/CustomerContractRecurringSummaryDto'
text/xml:
schema:
$ref: '#/components/schemas/CustomerContractRecurringSummaryDto'
'202':
description: Server accepted and queued the request for background execution.
content:
application/json:
schema:
$ref: '#/components/schemas/BackgroundApiAcceptedDto'
text/json:
schema:
$ref: '#/components/schemas/BackgroundApiAcceptedDto'
application/xml:
schema:
$ref: '#/components/schemas/BackgroundApiAcceptedDto'
text/xml:
schema:
$ref: '#/components/schemas/BackgroundApiAcceptedDto'
security:
- interactiveapi: []
/v1/customerContract/{contractId}/action/setupContract:
post:
tags:
- Customer Contract
summary: Setup contract operation
description: 'Response Message has StatusCode BadRequest or InternalServerError if POST operation failed
In this endpoint, If-Match can be checked against resource current version when calling with ''erp-api-background'' HTTP header.'
operationId: CustomerContract_SetupContractBycontractId
parameters:
- name: contractId
in: path
description: Reference number of the customer contract to be set up
required: true
schema:
type: string
- name: setupDate
in: query
description: Optional Setup Date
schema:
type: string
format: date-time
- name: erp-api-background
in: header
description: 'Accepts the request and queues it to be executed in the background by our least busy worker. Responds with 202 Accepted and a document containing a JobId reference and details state location.
Supported values:
* a URL: when the background operation is finished, a notification will be posted to the URL with a document containing a reference id, status code and a details state location.
* "none" (without quotes): Fire and forget; no notification will be sent when background operation is finished.
* "subscription[:<name_1>=<value_1>,..,<name_n>=<value_n>]" (without quotes): when the background operation is finsihed, a notification is posted to the Webhook subscription set up in Developer Portal for your integration client.
Optionally a set of name-value pairs can be added. These will be sent as headers in the POST request to the Webhook subscription''s url.
To find status and details of a background-api operation, GET .. v1/background/{id}. To get the response payload of a background-api operation, if any, GET .. v1/background/{id}/content'
schema:
type: string
- name: If-Match
in: header
description: 'The If-Match HTTP header allows clients to update a resource only if its current version matches a specific ETag. This mechanism helps prevent conflicts when multiple clients attempt to modify the same resource simultaneously.
The If-Match header should be included in the request headers using the following syntax: If-Match: "etag_value"
* If the POST operation is successful, the server responds with 200 OK and includes the new ETag value in the response headers.
* If the ETag on the server does not match the value provided in the If-Match header, the server responds with 412 Precondition Failed.'
schema:
type: string
responses:
'412':
description: Customer contract version does not match with If-Match header
content:
application/json: {}
text/json: {}
'202':
description: Server accepted and queued the request for background execution.
content:
application/json:
schema:
$ref: '#/components/schemas/BackgroundApiAcceptedDto'
text/json:
schema:
$ref: '#/components/schemas/BackgroundApiAcceptedDto'
security:
- interactiveapi: []
/v1/customerContract/{contractId}/action/activateContract:
post:
tags:
- Customer Contract
summary: Activate contract operation
description: 'Response Message has StatusCode BadRequest or InternalServerError if POST operation failed
In this endpoint, If-Match can be checked against resource current version when calling with ''erp-api-background'' HTTP header.'
operationId: CustomerContract_ActivateContractBycontractId
parameters:
- name: contractId
in: path
description: Reference number of the customer contract to be activated
required: true
schema:
type: string
- name: activationDate
in: query
description: Optional Activation Date
schema:
type: string
format: date-time
- name: erp-api-background
in: header
description: 'Accepts the request and queues it to be executed in the background by our least busy worker. Responds with 202 Accepted and a document containing a JobId reference and details state location.
Supported values:
* a URL: when the background operation is finished, a notification will be posted to the URL with a document containing a reference id, status code and a details state location.
* "none" (without quotes): Fire and forget; no notification will be sent when background operation is finished.
* "subscription[:<name_1>=<value_1>,..,<name_n>=<value_n>]" (without quotes): when the background operation is finsihed, a notification is posted to the Webhook subscription set up in Developer Portal for your integration client.
Optionally a set of name-value pairs can be added. These will be sent as headers in the POST request to the Webhook subscription''s url.
To find status and details of a background-api operation, GET .. v1/background/{id}. To get the response payload of a background-api operation, if any, GET .. v1/background/{id}/content'
schema:
type: string
- name: If-Match
in: header
description: 'The If-Match HTTP header allows clients to update a resource only if its current version matches a specific ETag. This mechanism helps prevent conflicts when multiple clients attempt to modify the same resource simultaneously.
The If-Match header should be included in the request headers using the following syntax: If-Match: "etag_value"
* If the POST operation is successful, the server responds with 200 OK and includes the new ETag value in the response headers.
* If the ETag on the server does not match the value provided in the If-Match header, the server responds with 412 Precondition Failed.'
schema:
type: string
responses:
'412':
description: Customer contract version does not match with If-Match header
content:
application/json: {}
text/json: {}
'202':
description: Server accepted and queued the request for background execution.
content:
application/json:
schema:
$ref: '#/components/schemas/BackgroundApiAcceptedDto'
text/json:
schema:
$ref: '#/components/schemas/BackgroundApiAcceptedDto'
security:
- interactiveapi: []
/v1/customerContract/{contractId}/action/setupAndActivateContract:
post:
tags:
- Customer Contract
summary: Setup and Activate contract operation
description: 'Response Message has StatusCode BadRequest or InternalServerError if POST operation failed
In this endpoint, If-Match can be checked against resource current version when calling with ''erp-api-background'' HTTP header'
operationId: CustomerContract_SetupAndActivateContractBycontractId
parameters:
- name: contractId
in: path
description: Reference number of the customer contract to be setup and activated
required: true
schema:
type: string
- name: activationDate
in: query
description: Optional Activation Date
schema:
type: string
format: date-time
- name: erp-api-background
in: header
description: 'Accepts the request and queues it to be executed in the background by our least busy worker. Responds with 202 Accepted and a document containing a JobId reference and details state location.
Supported values:
* a URL: when the background operation is finished, a notification will be posted to the URL with a document containing a reference id, status code and a details state location.
* "none" (without quotes): Fire and forget; no notification will be sent when background operation is finished.
* "subscription[:<name_1>=<value_1>,..,<name_n>=<value_n>]" (without quotes): when the background operation is finsihed, a notification is posted to the Webhook subscription set up in Developer Portal for your integration client.
Optionally a set of name-value pairs can be added. These will be sent as headers in the POST request to the Webhook subscription''s url.
To find status and details of a background-api operation, GET .. v1/background/{id}. To get the response payload of a background-api operation, if any, GET .. v1/background/{id}/content'
schema:
type: string
- name: If-Match
in: header
description: 'The If-Match HTTP header allows clients to update a resource only if its current version matches a specific ETag. This mechanism helps prevent conflicts when multiple clients attempt to modify the same resource simultaneously.
The If-Match header should be included in the request headers using the following syntax: If-Match: "etag_value"
* If the POST operation is successful, the server responds with 200 OK and includes the new ETag value in the response headers.
* If the ETag on the server does not match the value provided in the If-Match header, the server responds with 412 Precondition Failed.'
schema:
type: string
responses:
'412':
description: Customer contract version does not match with If-Match header
content:
application/json: {}
text/json: {}
'202':
description: Server accepted and queued the request for background execution.
content:
application/json:
schema:
$ref: '#/components/schemas/BackgroundApiAcceptedDto'
text/json:
schema:
$ref: '#/components/schemas/BackgroundApiAcceptedDto'
security:
- interactiveapi: []
/v1/customerContract/{contractId}/action/terminateContract:
post:
tags:
- Customer Contract
summary: Terminate contract operation
description: 'Response Message has StatusCode BadRequest or InternalServerError if POST oper
# --- truncated at 32 KB (64 KB total) ---
# Full source: https://raw.githubusercontent.com/api-evangelist/visma/refs/heads/main/openapi/visma-customer-contract-api-openapi.yml