Partially update a signatory

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

Access and authorization

  • Appropriate Open Banking access is required (e.g. mCust in the implementation).
  • The caller's partner identifier must be present (SIG_PARTNERID_REQUIRED if missing).
  • The customer must exist (SIG_CUSTOMERNOTFOUND) 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
Request Body schema: application/json
required
fullName
string
emailAddress
string <email>
title
string
approvalLimit
number <double>
phoneNumber
string
Responses
200

Signatory updated

400

Validation or business failure. May include SIG_SIGNATORYNOTFOUND, SIG_CUSTOMERACCESS_DENIED, SIG_PHONE_INVALID, SIG_VALIDATION_ERROR, etc.

401

Not authenticated

403

Forbidden

500

Internal server error

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."
}