Partially update a signatory

Merge semantics: only non-null fields in the body override the latest downstream signatory state.

Access and authorization

  • The caller's partner identifier must be present (SIG_PARTNERID_REQUIRED if missing).
  • The customer must exist (SIG_CUSTOMER_NOTFOUND) and be allowed for the token (SIG_CUSTOMERACCESS_DENIED).
  • The signatory must belong to the requested customer; otherwise the call fails (e.g. access denied or signatory not found, depending on downstream behavior).

Validation

  • At least one body property must be present; an empty JSON object is rejected (SIG_VALIDATION_ERROR).
  • Email: if emailAddress is sent, it must be a valid format and satisfy uniqueness rules where the platform applies them.
  • Phone: after merge, the effective phone number is validated with validate-phone (SIG_PHONE_INVALID if invalid)—this applies even when the number was not changed in the patch but remains the current value.
  • Approval limit: when provided, must be non-negative and within digit/scale limits.

Phone is validated against the merged signatory state, not only newly sent fields.

SecurityoAuth2
Request
path Parameters
customerId
required
integer <int64> >= 1

Customer (legal entity) identifier used on the public Open Banking surface.

signatoryId
required
integer <int64> >= 1

Signatory identifier (from create response or list items).

Request Body schema: application/json
required
non-empty
fullName
string
emailAddress
string <email>
title
string
approvalLimit
number
phoneNumber
string
Responses
200

Signatory updated

400

HTTP 400 — Bad Request

This response is returned when the request is invalid or cannot be processed.

The response includes a list of errors, where each error contains:

  • code: A unique identifier for the error
  • message: A description of the issue

Possible reasons include:

  • Missing or invalid input values
  • Incorrect request format
  • Invalid email or phone number
  • Invalid approval limit values
  • Missing required identifiers
  • Customer not found or access not allowed
  • Issues while processing the request

Common error codes: SIG_FULLNAME_REQUIRED, SIG_EMAIL_REQUIRED, SIG_EMAIL_INVALID, SIG_PHONE_REQUIRED, SIG_PHONE_INVALID, SIG_APPROVALLIMIT_MIN, SIG_APPROVALLIMIT_INVALID, SIG_PARTNERID_REQUIRED, SIG_CUSTOMER_NOTFOUND, SIG_CUSTOMERACCESS_DENIED, SIG_VALIDATION_ERROR, SIG_SERVICECALL_FAILED, SIG_SIGNATORYNOTFOUND, PHONE_SERVICECALL_FAILED

Note:

  • Some scenarios such as "not found" or "access denied" may still return HTTP 400.
401

HTTP 401 — Unauthorized

This response is returned when authentication is missing or invalid.

The response includes:

  • code: A standard error identifier
  • message: A message indicating that authorization is required
403

HTTP 403 — Forbidden

This response is returned when the request is understood but not allowed.

The response includes:

  • code: A standard error identifier
  • message: A message indicating that access is denied

Note:

  • This is different from request validation errors, which return HTTP 400.
500

HTTP 500 — Internal Server Error

This response is returned when an unexpected error occurs while processing the request.

The response includes:

  • code: A standard error identifier
  • message: A general message describing the failure

Note:

  • Errors related to invalid input or request data will return HTTP 400, not 500.
patch/v1/customers/{customerId}/signatories/{signatoryId}
Request samples
application/json
{
  • "fullName": "string",
  • "emailAddress": "user@example.com",
  • "title": "string",
  • "approvalLimit": 0,
  • "phoneNumber": "string"
}
Response samples
application/json
{
  • "id": 0,
  • "status": "string",
  • "message": "Signatory updated successfully."
}