Skip to main content
Update Company Configurations API
curl --request PATCH \
  --url https://api.pazy.io/v1.0/company/configurations

​
Authentication

All requests require an API key in the request headers. Headers: 
Authorization: Api-Key YOUR_API_KEY
Content-Type: application/json

​
Request

Content-Type: application/json Update one or more settings by sending their key and new value. The available keys, their input type, and the allowed options are returned by the Company Configurations API.

​
Body Parameters

ParameterTypeRequiredDescription
settingsarrayYesList of settings to update. Must contain at least one item
settings[].keystringYesIdentifier of the setting to update (from the Company Configurations API)
settings[].valueobjectYesNew value, wrapped in an object: { "value": <newValue> }. The inner value type must match the setting’s type (see below)

​
Value Format

The value must be an object whose inner value field matches the setting type:
Setting typeInner value typeExample
TOGGLEboolean{ "value": true }
NUMBERnumber{ "value": 30 }
SELECTstring (one of the setting’s options){ "value": "MULTI" }
TEXTstring{ "value": "Custom text" }
MULTISELECTarray of strings (each from the setting’s options){ "value": ["cost-centre", "department"] }

​
Code Examples

curl -X PATCH https://api.pazy.io/v1.0/company/configurations \
  -H "Authorization: Api-Key YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "settings": [
      { "key": "IS_ROUND_OFF_ENABLED", "value": { "value": true } },
      { "key": "LINE_ITEM_PARSING_MODE", "value": { "value": "MULTI" } }
    ]
  }'

​
Success Response

HTTP Status: 200 OK Valid settings are applied even if some entries in the request fail validation. Settings that fail validation are skipped and reported in misConfigurations — always inspect this array to confirm every setting was applied. Response Fields:
FieldTypeDescription
okbooleanIndicates whether the request was processed
dataobjectContains the update result
data.contextobjectUpdate result metadata
data.context.patchedCountnumberNumber of settings that were successfully updated
data.context.misConfigurationsarraySettings that failed validation and were skipped
data.context.misConfigurations[].keystringKey of the skipped setting
data.context.misConfigurations[].valueobjectThe rejected value
data.context.misConfigurations[].messagestringReason the value was rejected
data.context.misConfigurations[].optionsarrayAllowed option values for the setting, when applicable

​
Response Example

{
  "ok": true,
  "data": {
    "context": {
      "patchedCount": 2,
      "misConfigurations": []
    }
  }
}

​
Response Example (with a skipped setting)

{
  "ok": true,
  "data": {
    "context": {
      "patchedCount": 1,
      "misConfigurations": [
        {
          "key": "LINE_ITEM_PARSING_MODE",
          "value": { "value": "INVALID_OPTION" },
          "message": "Value should be one of this options",
          "options": ["MULTI", "TAX_BASED", "SINGLE"]
        }
      ]
    }
  }
}

​
Error Responses

​
Setting Not Editable / Update Rejected

When a requested setting is read-only, or a value-specific rule fails (for example, an invalid active-currency change), the update is rejected as a whole. This is returned with an HTTP 200 OK status, ok: false, and an errorData object — no settings are updated in this case. HTTP Status: 200 OK 
{
  "ok": false,
  "errorData": {
    "isError": true,
    "error": "Key not editable"
  }
}

​
Validation Error

Returned when the request body is malformed — for example, settings is missing or empty, or an item is missing key or value. HTTP Status: 400 Bad Request 
{
  "ok": false,
  "error": {
    "code": "VALIDATION_ERROR",
    "message": "Validation failed: /body: must have required property 'settings'"
  }
}

​
Access Denied

HTTP Status: 403 Forbidden 
{
  "ok": false,
  "error": {
    "code": "ACCESS_DENIED",
    "message": "Access denied: Resource can be updated only by admins and bookkeepers"
  }
}

​
Authentication Errors

HTTP Status: 401 Unauthorized 
{
  "ok": false,
  "error": {
    "code": "MISSING_CREDENTIALS",
    "message": "Missing Credentials"
  }
}

{
  "ok": false,
  "error": {
    "code": "INVALID_API_KEY",
    "message": "Invalid API Key"
  }
}

​
Permission Errors

HTTP Status: 403 Forbidden 
{
  "ok": false,
  "error": {
    "code": "INSUFFICIENT_PERMISSIONS",
    "message": "Permission check failed - PERMISSION_CHECK_FAILED"
  }
}

​
Internal Error

HTTP Status: 500 Internal Server Error 
{
  "ok": false,
  "error": {
    "code": "INTERNAL_ERROR",
    "message": "Internal error"
  }
}

​
Best Practices

  • Always wrap the new value in an object: { "value": <newValue> } — sending a bare value will fail validation
  • Fetch the Company Configurations API first to get valid key values, the expected type, and the allowed options
  • Check data.context.misConfigurations after each call — valid settings are still applied even when other entries are skipped, so a 200 OK with ok: true does not guarantee every setting changed
  • Treat a 200 OK response with ok: false and an errorData object as a full rejection — no settings were updated
  • Access is limited to users with organization update permission and an admin or bookkeeper role