Getting started with Akuiteo's APIs
Akuiteo provides many APIs for managing the different aspects of your company: workforce, CRM, sales, purchase, accounting and more. Our APIs enable you to use the many features of the Akuiteo softwares outside of the application or service. Therefore, you must understand how Akuiteo works to be able to use our APIs.
Note
All our APIs are in the version 2.0. This version is the only one available and is accessed by default.

API stands for Application Programming Interface. It is a set of rules that enables programs to talk to each other, in order to manage data and access features across the Internet in a consistent format. An API is a technology that links two systems together.
REST stands for Representational State Transfer. REST APIs are a type of web APIs that are based on requests and responses:
- You make a request to a resource on a server.
- The server responds with the requested information.
The request consists of an HTTP verb which translates an action (create, modify, search…), a specific URL to access the resource and a set of parameters.
Responses use the generic JSON content type.

Each request is made with specific parameters and the API is accessed at a predefined set of URLs. These URLs represent various resources, that is to say any information or content accessed at that location.
In the context of Akuiteo, a resource represents a management object or an item: an employee, a sales invoice, a project, a project task, and so on.
Following the Domain-Driven-Development approach, our APIs are categorized by domains that represent the different modules in Akuiteo.
The following table lists all our API domains:
Accounting | The Accounting domain enables you to manage chart of accounts and fiscal years. |
Administration | The Administration domain contains APIs used for server administration, comparable to the features available in the Administration Console. |
Approval process | The Approval process domain enables you to manage the different types of approvals available: quotes and quotations, sales and purchase orders, purchase invoices, expense reports, and others. |
Customer Relationship | The Customer Relationship domain enables you to manage events, opportunities, customers and prospects. |
Document Management | The Document Management domain enables you to manage documents, publishing templates and document links. |
Legacy | The Legacy domain regroups all our legacy APIs, which are SOAP web services. |
Messaging | The Messaging domain enables you to manage subscriptions and webhooks. |
Mobile | The Mobile domain gives you access to specific APIs for the Akuiteo Mobile Application that works off line. These are synchronization APIs that enable you to retrieve details about expense reports, leave requests, timesheets and so on, and also to send back the data to be saved. |
Project management | The Project management domain enables you to manage projects, phases, sub-phases and project tasks. |
Purchase | The Purchase domain enables you to manage quotes, orders, invoices, receptions and suppliers. |
Sales | The Sales domain enables you to manage quotations, orders, invoices, billing tables and time-based billing. |
Security | The Security domain enables you to manage everything regarding security, users and rights (DMFs). |
Service integration | The Service integration domain enables you to send emails and messages. |
Settings | The Settings domain gives you access to many setup options: triggers, translations, web portals, preferences, currencies and so on. |
Support | The Support domain enables you to manage helpdesk issues and tasks, contacts, contracts, tags, products, sprints, timesheets and provides many search APIs. |
Workforce | The Workforce domain enables you to manage employees, timesheets and schedules, expense reports, leave requests, custom requests and project events. |

Note
We recommend that you use technical users to make calls to our APIs.
A user must be created and set up from the Application Desktop to be able to connect to and use the different applications: the Application Desktop, the web portals, the mobile application. Technical users can also be created from the Desktop specifically to access APIs. A technical user will not be able to use its login and password to access the Akuiteo applications.
Whether it is a standard or a technical user, setting up the user from the Desktop will enable you to authenticate yourself, that is to say to prove your correct identity. The authenticated user will appear in the history of a management object for creation and modification actions. For more information, refer to Authentication.
However, you must also manage user rights in order to manage authorizations, that is to say the actions allowed for that user. An API might authenticate you but not authorize you to make a certain request.
User rights are assigned to each user. In Akuiteo, these rights are called DMFs (for Domain-Module-Function) and enable users to access specific modules or functions of our applications. There are two types of DMFs:
- Functional DMFs that apply to modules and features in the applications.
- API DMFs that grant permissions to call APIs. These DMFs can only be assigned to technical users.

Warning
If SAML is active on your environment, a non-SAML authenticated, technical user must be used. SAML-authenticated users will receive 401 error responses to any API request.
Three types of authentication are available for our APIs:

For the basic authentication, you send your username and password alongside every API call. This login/password must be the login information of an Akuiteo user (technical or standard).
An Authorization header must be added alongside any request:
Example using curl
--header 'Authorization: Basic dXNlcjpwYXNzd29yZA=='
The string Basic
indicates you are using the basic authentication.
The string dXNlcjpwYXNzd29yZA==
is the login/password encoded in base64.
Note
When using the basic authentication, you must use /rest
as the security selector in the Resource path URL.

For the OAuth authentication, you must first request an access token in order to authenticate yourself. Then you can start to perform API calls, but only for a limited period of time before it needs to refresh that token. With this type of authentication, you do not have to share login information on each API calls.
To be able to use the OAuth authentication:
1 | From Akuiteo's Administration Console, go to Security > Oauth2 and create a New client with the following information: |
Field | Description |
---|---|
Client ID | Client ID used for the Oauth authentication. |
Duration (s) | The duration indicates the number of seconds that the access token will be valid. |
Reload duration (s) |
A refresh token makes it possible to request a new access token without having to enter the login information again. The reload duration indicates the number of seconds that the refresh token can be used to request a new access token. |
Scope | Fill in read_write. Since authorizations are based on DMFs, you can give access to the read_write scope to read, modify and delete resources. |
Once created, Akuiteo provides you with a Client Secret.
2 | To retrieve the access token, make an API call using the request: POST /oauth/token with 'application/x-www-form-urlencoded' as 'Content-Type'. |
curl --location --request POST 'https://akuiteo.mon-server.fr/akuiteo/oauth/token' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'grant_type=password' \
--data-urlencode 'client_id={your_client_id}' \
--data-urlencode 'client_secret={your_secret}' \
--data-urlencode 'scope=read_write' \
--data-urlencode 'username={your_username}' \
--data-urlencode 'password={your_password}'
Note
When needed, use the refresh token to get a new access token.
Once you get the access token, an Authorization header must be added alongside any request:
Example using curl
--header 'Authorization: Bearer {access_token}'
The string Bearer
indicates you are using the OAuth authentication.
The string {access_token}
must be replaced with the access token retrieved.
Note
When using the OAuth authentication, you must use /RS
as the security selector in the Resource path URL.

Akuiteo version | From 4.6 onwards |
For the JWT authentication, you must first request a jwt token in order to authenticate yourself, then you can start to perform API calls. With this type of authentication, you do not have to share login information on each API calls.
To retrieve the JWT token, make an API call using the request: GET /jwt/login.html
curl --location --request GET 'https://akuiteo.mon-server.fr/akuiteo/jwt/login.html?username={your_username}&password={your_password}'
Once you get the JWT token, an Authorization header must be added alongside any request:
Example using curl
--header 'Authorization: Bearer {jwt_token}'
The string Bearer
indicates you are using the JWT authentication.
The string {jwt_token}
must be replaced with the JWT token retrieved.
Note
When using the JWT authentication, you must use /rest
as the security selector in the Resource path URL, just like the basic authentication.

The Akuiteo APIs follow the same principles as any REST APIs. Each operation is done via an HTTPS call to a specific URL, potentially accompanied with some parameters or with a request body.
Request bodies and responses use the generic JSON content type.
Note
API calls are made on resources from the default company of the user making the request. If you want to change the company targeted with your API calls, add the following line to the header alongside any request:
--header 'X-Company-Code: {company_code}'

The HTTP verbs are at the core of the APIs. To make a request, you need an HTTP verb which represents an action (create, modify, search…) made on one or multiple resources.
The method used depends on the API you want to call. You must read the API documentation to identify the resource path required for each API:
The following standard methods are used in our APIs:
GET |
Retrieves the targeted resource or all the items in a collection. The response does not display any sub-objects, it only displays ids. Use this method to show the details of the targeted resource. Example If you want to retrieve the details of an employee, the method will be:
|
POST |
Updates the targeted resource or all the items in a collection. This method is also used for functional operations and for Akuiteo-specific APIs. Example If you want to modify an event (task, appointment or note), the method will be:
|
PUT |
Creates a resource. Example If you want to create a new quotation, the method will be:
|
DELETE |
Deletes the targeted resource or all the items in a collection. Example If you want to delete an issue, the method will be:
|
PATCH |
Updates specific parameters in the targeted resource and not the whole resource. This method follows the RFC 6902. Example If you want to update specific parameters in an expense report, the method will be:
|
Actions that do not correspond to standard HTTP methods and are specific to Akuiteo are collected under a sub-resource. For more information, refer to Akuiteo's API specifics.

The path URL to access the resource and make a request using our APIs follows the structure:
Let us dissect this URL:
Protocol | Always use the HTTPS protocol when making requests to our APIs. |
Server URL | Address of your Akuiteo server, for example akuiteo.com or CustomerA-akuiteo.com. |
Akuiteo Application Path | Name of your Akuiteo application, for example akuiteo or akuiteo-test. |
Security selector |
If you are using the basic authentication, use If you are using the OAuth authentication, use |
Domain Path |
Name of the domain targeted by the request. Our APIs are categorized by domains that represent the different modules in Akuiteo. Refer to the API documentation to know more about each domain. Tip In the API documentation (HTML or PDF), the chapter 1.4 URI scheme of each domain displays the BasePath for each domain.
In this example:
|
Resource path |
The resource path depends on the API you want to call. You must read the API documentation to identify the resource path required for each API:
Depending on the API, there can be a number of elements in the resource path:
|

Our APIs follow the same principles as REST services: each operation is made via an HTTPS call to a specific URL, potentially with parameters or a request body included.
When a body is required, it must be written in JSON format (same format as all API responses), with an "application/json" ContentType.
The parameters and/or request body required depend on the API you want to call. You must read the API documentation to identify what is required for each API:
Note
If there is a link in the Schema column for a parameter or a body, click on the link to know more about the type of data required.
When making a request, the data specified as parameters or in the request body must follow the typical REST conventions:
- Objects are surrounded by brackets { and }.
- Object properties are names in camelCase.
- Collections are surrounded by square brackets [ and ].
- Data types of a schema can be:
string | Any chain of characters. |
string (date-time) |
The date-time notation as defined by RFC 3339 (yyyy-MM-dd’T’HH:mm:ss.SSSXXX) and expressed in UTC. Example: 2020-01-01T00:00:01Z means January 1st, 2020 at midnight and 1 second. Dates are in the ISO8601 format in order to describe a date and time while avoiding any mistake, particularly regarding time zones and daylight saving time. This format includes a "+hhmm" at the end of the date to set the time difference (in hours and minutes) with the Universal Coordinated Time (UTC). For example:
Both examples describe the same date and time: 3:13 PM on July 11,2019. When an API client makes a call, the date is formatted according to its own time zone (for example the browser's time zone). However, the API will return a date formatted in UTC since the server ignores the client context. This will never be an issue since the date can be easily interpreted to be displayed in the correct local format. |
number | Any number. You must not use any separator for thousands, millions, and so on. |
number (double) |
Floating-point numbers with more precision. The full stop (ascii 0x2E) must be used as the separator for decimal values. Example: 10.8 |
number (float) |
Floating-point numbers. The full stop (ascii 0x2E) must be used as the separator for decimal values. Example: 10.8 |
integer (int64) |
Signed 64-bit integers (long type). Example: 10 |
boolean |
Represents two values: true and false. Values such as 0, 1 or null are not considered boolean values. |

Akuiteo uses conventional HTTP response codes to indicate the success or failure of an API request.
- If the status code starts with 2xx, it means the request has succeeded.
- If the status code starts with 4xx, it means the request has failed because of a client error (data format, unknown resource, etc.).
- If the status code starts with 5xx, it means the request has failed because of a server problem.
The following response status codes are used for our APIs:
Code | Type | Description |
---|---|---|
200 | OK | Standard success code. The request has succeeded. |
201 | Created | The resource has been created (usually for PUT or POST requests). |
204 | No Content | The request has succeeded but there is no content to retrieve. |
206 | Partial Content | The response is partial. |
400 | Bad Request | Standard failure code. This code is used when no other specific code applies. |
401 | Unauthorized | No valid API key provided. |
402 | Request Failed | The parameters were valid but the request failed. |
403 | Forbidden | The user does not have permissions to perform the request. |
404 | Not Found | The requested resource does not exist. |
405 | Method Not Allowed |
The HTTP method requested on the resource is not supported, for example if you make a POST request on a resource where POST does not make sense or is not implemented. |
409 | Conflict | The request conflicts with another request (duplicated data) or the data state is not valid. |
500 | Internal Error | Server errors. The call was successful but something went wrong on Akuiteo's end. |

Some features available in the Akuiteo applications could not be translated in REST APIs using the standard HTTP methods.
For example, you might have to make an action on a resource that will change its state without changing the resource in itself. In the context of a helpdesk issue, when you assign a task to yourself, you change the state of the task without changing the task in itself.
This is why Akuiteo provides specific APIs whenever the standard methods do not apply. These APIs:
- use the POST HTTP verb,
- can be identified because they mostly use a verb (search, read, bill, take, and so on) as a sub-resource in their resource path.
Described below are the main Akuiteo-specific APIs that you will encounter.

/search
APIs
Our /search
APIs are designed to give you extensive search options in order to target the resources you need. When using a /search
API, you can fill in search criteria as parameters in the request body.
Tip
Use the percentage character % as a joker which can replace any chain of characters.
The different search operations available are:
LIKE |
Search for resources with a parameter value that matches the searched value. You want the list of custom requests with an ID that starts with 12. The request body will be: Copy
|
IS |
Search for resources with a parameter value that is the same as the searched value. You want the list of the custom requests from the employee with an ID AAA. The request body will be: Copy
|
IS_NOT |
Search for resources with a parameter value that is not the same as the searched value. You want the list of all custom requests except the ones with the project ID 12345. The request body will be: Copy
|
IN |
Search for resources with a parameter value that matches one of the values specified in the searched value. You want the list of custom requests from the employees with the ID AAA, BBB and CCC. The request body will be: Copy
|
IS_NULL |
Search for resources with a parameter value that is null. You want the list of custom requests that are not linked to a project (projectId null). The request body will be: Copy
|
IS_NOT_NULL |
Search for resources with a parameter value that is not null. You want the list of all custom requests linked to any employee. The request body will be: Copy
|
GREATER_OR_EQUALS |
Search for resources with a parameter value that is greater than or equal to the value specified in the searched value. You want the list of custom requests with an ID that is greater than or equal to 12345. The request body will be: Copy
|
GREATER |
Search for resources with a parameter value that is strictly greater than the value specified in the searched value. You want the list of custom requests with an ID that is greater than 12345. The request body will be: Copy
|
LOWER_OR_EQUALS |
Search for resources with a parameter value that is lower than or equal to the value specified in the searched value. You want the list of custom requests with an ID that is lower than or equal to 12345. The request body will be: Copy
|
LOWER |
Search for resources with a parameter value that is strictly lower than or equal to the value specified in the searched value. You want the list of custom requests with an ID that is lower than 12345. The request body will be: Copy
|

/read
APIs
Our /read
APIs can be used to retrieve all the details of a resource. In one API call, you can get all the information about the targeted resource, including dependencies. Our /read
APIs enable you to retrieve the information that is not displayed when using the standard GET method.
ReadOptions are used in the request body to specify the dependencies that you want to display in the API's response. The ReadOptions available depend on each resource. You must read the API documentation to know more about the ReadOptions available.
Example of a standard GET API
The API GET /invoices/{purchase_invoice_id}
lets you retrieve basic information on a specific purchase invoice.
Request URL GET https://akuiteo.my-server.fr/akuiteo/rest/purchase/invoices/FF2100462
Response
{
"modeReglement": "PR",
"conditionReglement": "00030",
"buyerCode": null,
"id": "FF2100462",
"project": null,
"projectId": "FG",
"phase": null,
"phaseId": "500005899",
"subPhase": null,
"subPhaseId": "500005450",
"type": "PURCHASE_INVOICE",
"number": "FF2100462",
"date": "2021-03-25T00:00:00.000+0100",
"name": "Facture electricité DEC 2020",
"companyCode": "AKSAS",
"afterTaxAmount": 1794.08,
"preTaxAmount": 1501.46,
"projectedApprovalDate": null,
"currencyCode": "EUR",
"currency": null,
"thirdPartyId": "500001720",
"thirdPartyToBillId": null,
"description": null,
"entityCode": "G&A",
"manager": null,
"managerId": null,
"changeTracking": {
"createdTime": "2021-03-25T23:21:15.433+0100",
"createdBy": null,
"createdById": "-1",
"modificationTime": "2021-03-25T23:32:17.743+0100",
"modificationBy": null,
"modificationById": "-1"
},
"text": null,
"comment": null,
"payment": null,
"accountingJournalId": null,
"reference1": "108002809284",
"reference2": null,
"reference3": null,
"supplier": null,
"lines": [],
"supplierDate": "2021-03-25T00:00:00.000+0100",
"dueDate": null,
"invoiceType": "INVOICE"
}
In this example, the lines of the purchase invoice are not displayed.
Example with the /read
API
Now, let's try the API POST /invoices/{purchase_invoice_id}/read
to retrieve more information about the invoice's lines.
Request URL POST https://akuiteo.my-server.fr/akuiteo/rest/purchase/invoices/FF2100462/read
Request body
{
"options" : ["LINE", "LINE_PROJECT", "LINE_ITEM"]
}
Response
{
"modeReglement": "PR",
"conditionReglement": "00030",
.....
"supplier": null,
"lines": [
{
"id": "500053139",
"project": {
"id": "FG",
"name": "AKUITEO : FRAIS GENERAUX",
"companyCode": "AKSAS",
"customerId": "144",
"endCustomerId": "144",
"internal": true,
"leave": false,
"leaveType": null
},
"projectId": "FG",
"phase": null,
"phaseId": "500005899",
"subPhase": null,
"subPhaseId": "500005450",
"businessDocumentId": "FF2100462",
"name": "TOTAL : Conso Electricité",
"complementName": null,
"quantity": 1.0,
"unitPriceCurrency": 1071.05,
"unitPrice": 1071.05,
"amountTotalCurrency": 1071.05,
"amountTotal": 1071.05,
"rankNumber": 100.0,
"generalAccount": null,
"vat1": {
"code": "01",
"rate": 20.0
},
"vat2": null,
.....
},
{
"id": "500053140",
"project": {
"id": "FG",
"name": "AKUITEO : FRAIS GENERAUX",
"companyCode": "AKSAS",
"customerId": "144",
"endCustomerId": "144",
"internal": true,
"leave": false,
"leaveType": null
},
"projectId": "FG",
.....
},
{
"id": "500053137",
"project": {
"id": "FG",
"name": "AKUITEO : FRAIS GENERAUX",
"companyCode": "AKSAS",
"customerId": "144",
"endCustomerId": "144",
"internal": true,
"leave": false,
"leaveType": null
},
"projectId": "FG",
.....
}
],
"supplierDate": "2021-03-25T00:00:00.000+0100",
"dueDate": null,
"invoiceType": "INVOICE"
}

In this tutorial, we will use the following information:
-
URL = https://akuiteo.my-server.fr/akuiteo/rest/...
-
Basic authentication
This tutorial will be using APIs from the Workforce domain. You must refer to the API documentation of this domain to know the URL paths, the parameters and other details about each API.

Let's start by searching for the employees with an employee code that starts with the letter J. We will use the API: POST /employees/search
Request (cURL)
curl --location --request POST 'https://akuiteo.my-server.fr/akuiteo/rest/workforce/employees/search' \
--header 'Authorization: Basic dXNlcjpwYXNzd29yZA==' \
--header 'Content-Type: application/json' \
--header 'Cookie: JSESSIONID=759870920B6FFB1F4B62C4B6CA8E596B' \
--data-raw '{
"code": {
"operator" : "LIKE",
"value": "J%"
}
}'
Response
[
{
"id": "500001430",
"code": "JBE",
[...]
},
{
"id": "500001421",
"code": "JBPN",
[...]
},
{
"id": "500002344",
"code": "JSH",
"name": "Smith",
"firstName": "John",
"action": null,
"title": "M.",
"phone": null,
"mobilePhone": null,
"email": "john.smith@akuiteo.com",
"noTimesDunning": null,
"multiCompany": false,
"modeTimeRecording": 3.0,
"modeInputSchedule": 0.0,
"timeRecordingInputMode": "HOUR_MINUTE",
"scheduleInputMode": "DAY",
"executive": true,
"generic": false,
"candidate": false,
"external": false,
"managerMultiCompany": false,
"employeeFunctions": {
"allFunctions": false,
"allSales": false,
"allPurchases": false,
"allOperational": false,
"projectSalesManager": false,
"projectFinanceManager": false,
"projectProductionManager": false,
"projectAccountManager": false,
"projectAssignment": true,
"projectPhaseManager": false,
"projectSendOnMission": false,
"salesSalesAssistant": false,
"salesOrderAndEstimateTracking": false,
"salesBillingSchedulesTracking": false,
"purchasingBuyer": false,
"timeRecording": true,
"inputOfExpenseReport": true,
"purchasesReceptionTracking": false,
"inputSchedule": true,
"cMMSContractSalesManager": false,
"cMMSContractTechnicalManager": false,
"cMMSMRAndEOManager": true
},
"employeeHistory": [],
"timeRecordingRules": null,
"scheduleRules": null,
"businessCards": [],
"number": "0000000077",
"relations": [],
"employeeAbilities": [],
"jobType": null,
"jobTypeId": "100257",
"address": null,
"addressId": "500020664",
"customFields": null
},
{
"id": "500001331",
"code": "JTL",
[...]
}
]
> We will focus on the employee John Smith for this tutorial, using its id 500002344.

With the 1st API, we retrieved first-level information about the employee John Smith. However, we can see that some parameters are not detailed:
We want to know more about John Smith's employee history and business cards. We will use the API: POST /employees/{employee_id}/read
Request (cURL)
curl --location --request POST 'https://akuiteo.my-server.fr/akuiteo/rest/workforce/employees/500002344/read' \
--header 'Authorization: Basic dXNlcjpwYXNzd29yZA==' \
--header 'Content-Type: application/json' \
--header 'Cookie: JSESSIONID=23CA62EF43C941680939724925E737C0' \
--data-raw '{
"options" : ["EMPLOYEE_HISTORY", "BUSINESS_CARDS"]
}'
Response
{
"id": "500002344",
"code": "JSH",
"name": "Smith",
"firstName": "John",
[...]
"employeeHistory": [
{
"id": null,
"employeeHistoryType": "500000030",
"employeeId": "500002344",
"code": null,
"from": "2020-10-01T00:00:00.000+0200",
"to": null,
"dailyHours": 7.42,
"weekHours": 38.3,
"occupancyRate": 0.0,
"managerId": null,
"companyId": "1",
"directHourlyRate": 0.0,
"standardHourlyRate": 0.0,
"dailyCost": 0.0,
"dailySellingPrice": 0.0,
"entity": "500000040",
"service": "500000058",
"position": "Rédactrice Technique",
"skill": "500000279",
"employeeFamily1": "500000320",
"employeeFamily2": "500000333",
"employeeFamily3": "500000381",
"leave": false,
"modelWeek": null,
"modelWeekId": "500000030",
"salary": 1.0
}
],
"timeRecordingRules": null,
"scheduleRules": null,
"businessCards": [
{
"id": "500000040",
"employeeId": "500002344",
"cardNumber": "xxxxxxxxxxxx4444",
"encryptedCardNumber": "XXXXXXXXXXXXXXXXXXXX",
"name": "Business card",
"type": "BUSINESS_ACCOUNT",
"endDate": null
}
],
[...]
}
> We can see that John Smith has one business card specified in his record sheet, with the id 500000040.

We want to rename John Smith's business card, from "Business card" to "John Smith's business card". We will use the API: POST /employees/{employee_id}/business-cards/{business_card_id}
Request (cURL)
curl --location --request POST 'https://akuiteo.my-server.fr/akuiteo/rest/workforce/employees/500002344/business-cards/500000040' \
--header 'Authorization: Basic dXNlcjpwYXNzd29yZA==' \
--header 'Content-Type: application/json' \
--header 'Cookie: JSESSIONID=8773313A0C06782E338115058C24706A' \
--data-raw '{
"id": "500000040",
"employeeId": "500002344",
"cardNumber": "xxxxxxxxxxxx4444",
"name": "John Smith'\''s business card",
"type": "BUSINESS_ACCOUNT",
"endDate": null
}'
Response
500000040
If we make another call to the 2nd API, here is what we get:
Response
{
"id": "500002344",
"code": "JSH",
"name": "Smith",
"firstName": "John",
[...]
"businessCards": [
{
"id": "500000040",
"employeeId": "500002344",
"cardNumber": "xxxxxxxxxxxx4444",
"encryptedCardNumber": "XXXXXXXXXXXXXXXXXXXX",
"name": "John Smith's business card",
"type": "BUSINESS_ACCOUNT",
"endDate": null
}
],
[...]
}
> The business card's name has been modified.

We now want to create a new business card and add it to John Smith's record sheet. We will use the API: PUT /employees/{employee_id}/business-cards
Request (cURL)
curl --location --request PUT 'https://akuiteo.my-server.fr/akuiteo/rest/workforce/employees/500002344/business-cards' \
--header 'Authorization: Basic dXNlcjpwYXNzd29yZA==' \
--header 'Content-Type: application/json' \
--header 'Cookie: JSESSIONID=91BF7F6C3F9C83E3FBB959BD7AB0A7DB' \
--data-raw '{
"employeeId" : "500002344",
"cardNumber" : "1234123412341234",
"name" : "Main business card",
"type" : "BUSINESS_ACCOUNT"
}'
Response
500000045
If we make another call to the 2nd API, here is what we get:
Response
{
"id": "500002344",
"code": "JSH",
"name": "Smith",
"firstName": "John",
[...]
"businessCards": [
{
"id": "500000040",
"employeeId": "500002344",
"cardNumber": "xxxxxxxxxxxx4444",
"encryptedCardNumber": "XXXXXXXXXXXXXXXXXXXX",
"name": "John Smith's business card",
"type": "BUSINESS_ACCOUNT",
"endDate": null
},
{
"id": "500000045",
"employeeId": "500002344",
"cardNumber": "xxxxxxxxxxxx1234",
"encryptedCardNumber": "XXXXXXXXXXXXXXXXXXXX",
"name": "Main business card",
"type": "BUSINESS_ACCOUNT",
"endDate": null
}
],
[...]
}
> The new business card with the id 500000045 has been added to John Smith's record sheet.

We now want to remove "John Smith's business card" (id 500000040) from the record sheet. We will the API: DELETE /employees/{employee_id}/business-cards/{business_card_id}
Request (cURL)
curl --location --request DELETE 'https://akuiteo.my-server.fr/akuiteo/rest/workforce/employees/500002344/business-cards/500000040' \
--header 'Authorization: Basic dXNlcjpwYXNzd29yZA==' \
--header 'Cookie: JSESSIONID=1E31A6F9012079EB3924361358932CEA'
If we make another call to the 2nd API, here is what we get:
Response
{
"id": "500002344",
"code": "JSH",
"name": "Smith",
"firstName": "John",
[...]
"businessCards": [
{
"id": "500000045",
"employeeId": "500002344",
"cardNumber": "xxxxxxxxxxxx1234",
"encryptedCardNumber": "XXXXXXXXXXXXXXXXXXXX",
"name": "Main business card",
"type": "BUSINESS_ACCOUNT",
"endDate": null
}
],
[...]
}
> The business card "John Smith's business card" has been deleted and John Smith now only has one business card.