{{domainAddress}}/customData/updateMobileUserData
This post will update the customer’s data record.
Headers
Header | Content |
Content Type | application/json |
Authorization | Bearer {{ID token}} |
App-Id | {{API key provided by Mosaic}} |
Device-Id | {{Advertising ID from the initial installation of this app}} |
Request-Date | {{ISO 8601 date and time format in UTC}} |
Body
This function requires the clientId provided by Mosaic for this app to be sent in the request payload.
The userId value is provided in the /users/getUser response
The data object must contain an array for each field ID the custom data configuration requires. The arrays should be named after the configuration input. For example, in our sample configuration file, we require three inputs named “field1”, “field2”, and “field3”.
The posted payload should include an array named for each of those inputs, “field1”, “field2”, and “field3”, as you see in the sample below.
Inside each of those arrays contains an object that represents each instance of the input components. This object is consistent across each type of input and looks like this:
{
"fieldId": "", <-- identifies the field
"subFieldA": "", <-- customer's contents from the first input component
"subFieldB": "" <-- customer's contents from the second input component
}
Sample payload with three input components. “field1” contains one input instance; “field2” and “field3” contain two input instances.
{
"clientId": "{{clientId}}",
"userId": "{{userId}}",
"data": {
"field1": [
{
"fieldId": "field1",
"subFieldA": "Andy 123",
"subFieldB": " "
}
],
"field2": [
{
"fieldId": "field2",
"subFieldA": "Option A:A",
"subFieldB": " "
},
{
"fieldId": "field2",
"subFieldA": "Option B:B",
"subFieldB": " "
}
],
"field3": [
{
"fieldId": "field3",
"subFieldA": "My text",
"subFieldB": "Option3:3"
},
{
"fieldId": "field3",
"subFieldA": "More text",
"subFieldB": "Option4:4"
}
]
}
}
Example
Headers
App-Id: 5***9-d**3-4**8-b**1-b3***dac
Device-Id: a4***cb-d***5-4***f-8***c-84***75
Request-Date: 2024-07-02T19:59:20.815Z
Content-Type: application/json
Authorization: Bearer eyJraWQiO...aLxlc6PCgQ
Body
{
"clientId": "{{clientId}}",
"userId": "{{userId}}",
"data": {
"field1": [
{
"fieldId": "field1",
"subFieldA": "Andy 123",
"subFieldB": " "
}
],
"field2": [
{
"fieldId": "field2",
"subFieldA": "Option A:A",
"subFieldB": " "
},
{
"fieldId": "field2",
"subFieldA": "Option B:B",
"subFieldB": " "
}
],
"field3": [
{
"fieldId": "field3",
"subFieldA": "My text",
"subFieldB": "Option3:3"
},
{
"fieldId": "field3",
"subFieldA": "More text",
"subFieldB": "Option4:4"
}
]
}
}
Response
The response can be ignored unless there is an error returned.
{
"errors": [],
"warnings": [
"Validator: 1 value was removed from the provided request data"
],
"notices": [],
"data": {
"fieldCount": 0,
"affectedRows": 1,
"insertId": 0,
"serverStatus": 2,
"warningCount": 0,
"message": "",
"protocol41": true,
"changedRows": 0
}
}
Error Codes
Important: To determine whether or not to parse the response.data object as a successful response, or an error response, examine the errors
array. If its length is greater than zero, then the data contains an error data structure.
—Authentication Errors
All API functions are subject to possible authentication errors. These are consistent across all function and are described in the Authentication post.
API Response | Cause |
response: { “message”: “Unauthorized” } | Incorrect headers or header contents. Contact Mosaic Developers to resolve this issue. |
response.data:{ “message”: “Access Token has expired”, “code”: “NotAuthorizedException“, “statusCode”: 400, “retryable”: false } | Refresh tokens The access token previously recorded is no longer valid, and must be refreshed. The “message” will explain what went wrong. |