- 18 Sep 2024
- 8 Minutes to read
- Print
- DarkLight
Update a person
- Updated on 18 Sep 2024
- 8 Minutes to read
- Print
- DarkLight
Update an existing person. This will fully overwrite the person with the data from the request.
Description
Update an existing person. This will fully overwrite the person with the data from the request. Both the 'reference' and the 'externalIdentifier' can be used to identify the person which needs to be overwritten. Preferably only the reference is used. If this is not available, the externalIdentifier can be used. If both properties are used it is important that both are correct and match with the same entity (person). If this is not the case, the request will return with an error code and the person will not be overwritten.
A person is a standalone entity and pertains to an enhancement of organisation. This could be a contact person within an organisation. Several users utilize this to enter their own employees into the system.
Use Case
The Bloxs user has added a person with multiple incorrect properties. Therefore the user wants to change several properties simultaneously rather than making several requests and changing one property at a time.
Field | Description |
---|---|
reference | The relationship number within Bloxs. This is unique (per client specific environment) for all relationships (EstateAgents, Organisations, Owners, Persons, Suppliers). The relationship number is generated by the Bloxs system . |
externalIdentifier | The unique identifier within the system of the requesting party. This identifier is not generated by the Bloxs system. |
phoneNumber | Phone number of the relation. |
mobileNumber | Mobile phone number of the relation. |
cocNumber | Chamber of Commerce number. |
cocDescription | Additional information about the Chamber of Commerce number. Termed as KVK description in the Bloxs system. Extra information can be entered here regarding the Chamber of Commerce number. |
vatNumber | VAT (BTW) number of the relation. |
correspondenceMethod | The default method of correspondence. This field is an integer with 2 options: 1 = Email 2 = Post If the correspondenceMethod is set to Email, then the primaryEmailAddresses field is mandatory. If the CorrespondenceMethod is set to Post, then the Address field is mandatory. |
remarks | General comments. Please note: Avoid including sensitive information here, such as passwords or sensitive personal data. |
languageISOCode | ISO language code. Use the 2-letter code from the ISO 639-1 Code list. |
address | The address of the relation. |
street | The street of the relation. |
houseNumber | The house number of the relation. |
postalCode | The postal code of the relation. |
city | The place of residence of the relation. |
addres.countryISOCode | ISO country code. Use the 2-letter code from the ISO 639-1 Code list. |
invoiceAddress | The billing address of the relation. In case this field is empty, the data from 'address' will be used. This is mainly relevant for certain templates. |
postalAddress | The postal address of the relation. In case this field is empty, the data from 'address' will be used. This is mainly relevant for certain templates. |
primaryEmailAddresses | Primary email address used by the relation. If other email addresses are left empty, this email address will be used for correspondence. |
invoicesEmailAddresses | The email address used to send invoices. |
paymentRemindersEmailAddresses | The email address used to send reminders regarding payments. |
indexationsEmailAddresses | The email address to which the annual rent increase (indexation) is sent. |
serviceTicketsEmailAddresses | The email address to which all maintenance notifications are sent. This may differ from the general email address. For instance, in the case of a shared office space where all communication is centralized through one central desk instead of being handled separately by individual tenants. |
purchaseOrdersEmailAddresses | All communication specifically related to procurement is conducted through this email address. This is primarily applicable to large parties where procurement processes are managed through separate email accounts. |
portalsEmailAddresses | Within Bloxs, a portal account for customers or tenants can be opened. Through this field, you can provide multiple email addresses that need to be granted access. |
otherEmailAddresses | Other email addresses. |
relationTypeName | Category of the person. The available categories are pre-defined in the system but can be configured by the user. If this data point contains a value that is not present in the available categories, a validation error will be received. To retrieve the list of available options the following endpoint can be used: GET RelationTypes. |
communicationFormName | Gender/Salutation. It's a standard list in the system and can be configured by the user in the Bloxs system. Male/Female/Unknown are the default values. These are configurable. Based on this value, other standard expressions are generated in the correspondence, such as the salutation. To retrieve the list of available options the following endpoint can be used: GET CommunicationForms. |
initials | The initials of the person. The initials will be displayed in the Bloxs application and therefore in documentation as well, the exact way in which the data was entered through this property. Therefore, it is recommended to enter the initials as capital letters seperated with a '.' For example: The initials of Antonius Gerald Butler would be entered as 'A.G.' Diacritic symbols are accepted by the system in accordance with the UTF-8 standard |
firstName | The first name of the person. The first name will be displayed in the Bloxs application and therefore in documentation as well, the exact way in which the data was entered through this property. Therefore, it is recommended to enter the first name starting with a capital. For example: The first name of Gerald Butler would be entered as 'Gerald'. Diacritic symbols are accepted by the system in accordance with the UTF-8 standard. |
lastName | The surname of the person. The surname will be displayed in the Bloxs application and therefore in documentation as well, the exact way in which the data was entered through this property. Therefore, it is recommended to enter the surname starting with a capital. For example: The surname of Gerald Butler would be entered as 'Butler'. Diacritic symbols are accepted by the system in accordance with the UTF-8 standard. |
lastNamePrefix | The name prefix of the person. The name prefix will be displayed in the Bloxs application and therefore in documentation as well, the exact way in which the data was entered through this property. Therefore, it is recommended to enter the name prefix as it should be shown in the application and communication. For example: The name prefix of Gerald van Butler would be entered as 'van'. Diacritic symbols are accepted by the system in accordance with the UTF-8 standard. |
dateOfBirth | The Date of birth of the person. This data needs to be entered in accordance with the ISO-8601 format. For example, somebody born on 25th of august 1980 should be entered as: 1980-08-25. |
jobTitle | The job title of the person. |
identificationTypeItemName | Type ID. This is a standard list but can be configured by the user. Default values: Passport, Driver's License & Identity Card. The string is validated against the list available in the Bloxs system. |
identificationNumber | The ID number. |
reference | The relationship number within Bloxs. This is unique (per client specific environment) for all relationships (EstateAgents, Organisations, Owners, Persons, Suppliers). The relationship number is generated by the Bloxs system. |
Please enter a valid token
1 = Email
2 = Post
The person was updated
1 = Email
2 = Post
The person data has validation issues