---
title: "Patch capability request data (S2S only)"
method: PATCH
path: "/v1/internal/requests/{id}"
tags: ["Internal Capability Requests"]
---

# Patch capability request data (S2S only)

`PATCH /v1/internal/requests/{id}`

## Request

- Base URL: `https://api.paymongo.com`
- URL: `https://api.paymongo.com/v1/internal/requests/{id}`
- Auth: HTTP bearer

Updates request KYB data and organization fields without changing request status. Only the fields provided in kyb_overrides will be updated. Returns 400 error if any key in kyb_overrides is not in the allowed list. This endpoint is for internal use only and requires S2S authentication.

## Path parameters

- `id` string, required

## Request body

- InternalPatchRequestReqDTO
  - `actor` string: Email of the person making the change (from JWT)
  - `kyb_overrides` string, required: KybOverrides allows updating specific KYB data values and organization fields Only the fields included in this map will be updated in both: 1. Request KybData (stored in database) 2. Core organization API If nil: No updates will be performed If empty map {}: No updates (returns request as-is) If provided with fields: Updates only those specific fields Accepted keys, per product: E-Wallet / Card, Standard Wallet, Account Update — any key naming a real kyb_data PROFILE field. There is no curated list: a reviewer may correct anything the merchant submitted. A key that names no kyb_data field is rejected (400) rather than silently ignored. Account Activation — account_type, business_type, is_one_person_corporation, business_trade_name, business_legal_name, business_dti_registered_name, business_description. Tax Document — files_tax_exemption, files_tax_sworn_declaration, files_bir_2303. DOCUMENT keys (files_<purpose>) are always gated to the purposes the product collects, even where profile fields are not: asking a merchant for a purpose the product does not accept produces a clarification they cannot satisfy. GET /v1/internal/requests/{id} returns the effective list for a request in allowed_kyb_override_keys. Rejection is all-or-nothing: one invalid key fails the whole payload and nothing is written. Not every accepted key has somewhere to land. ack_sd_requirement has no column in either core-api or accounts-api, and account_type is read-only in Core API. The response reports what was actually written in applied_kyb_override_keys, so an armed key that wrote nothing is visible instead of being reported as a successful save. When the keys reach the merchant's account: E-Wallet / Card, Standard Wallet, Account Activation — immediately, on this call. Account Update — immediately, EXCEPT business_type and is_one_person_corporation, which are applied at approval (POST /process, or /complete when /process was skipped). Writing a business type sets has_selected_business_type and cannot be walked back by a later decline, so it is not applied mid-review. applied_to_account on the response says whether this product writes through at all. Example (e-wallet): {"business_type": "corporation", "business_legal_name": "Acme Corp", "business_website": "https://acme.com"} Example (account activation): {"business_trade_name": "Updated Name", "business_description": "Updated description"} Example (account update, One Person Corporation): {"business_type": "corporation", "is_one_person_corporation": true}

## Response `200`

OK

- object: Standard response containing data and its metadata if any
  - `data` RequestResDTO
    - `account_id` string: AccountID is the account the request belongs to. On create, a merchant key is locked to its own account and any value sent here is ignored; service-to-service callers have no bound account and must supply it.
    - `allowed_kyb_override_keys` string[]: AllowedKybOverrideKeys is the set of kyb_override keys this request's product accepts, sorted. Ops-only, and attached to the internal single-request responses only. It is served rather than documented because the admin dashboard was mirroring it by hand, transcribed out of a rejection message — a mirror that goes stale silently, and did: keys the API accepts stopped being offered, so a reviewer could no longer ask a merchant for certain documents.
    - `applied_kyb_override_keys` string[]: AppliedKybOverrideKeys is the subset of THIS call's kyb_overrides that was written to the merchant's account, sorted. Present on the internal PATCH response only. It exists because a partial save is not uniformly applied: account_update writes the armed profile fields immediately, but defers business_type (one-way — it flips has_selected_business_type, and a later decline could not walk that back) and files_* keys (promotion deletes the documents it supersedes, and the request is still under review). Without this list a reviewer would have to assume an armed key was written, which is the silent-no-op failure the whole contract exists to prevent.
    - `applied_to_account` boolean: AppliedToAccount says whether a kyb_override write on this product reaches the merchant's ACCOUNT, or only stages values on the request for a later approval to apply. Pointer so that false is serialised rather than dropped — false is the whole point of the field. account_update stages; the payment-method and activation flows write through. The caller should not have to hard-code which is which.
    - `assigned_at` string, date-time
    - `assignee_email` string
    - `audit_history` RequestAuditLogResDTO[]: Audit trail - populated when fetching single request details
      - `action_type` string: assigned, unassigned, reassigned, status_changed, field_updated
      - `actor` string: Who performed the action (from JWT admin_id)
      - `created_at` string
      - `field_name` string: Which field was changed
      - `id` string
      - `new_value` string: Value after change (empty for removal)
      - `note` string: Optional human-readable note
      - `previous_value` string: Value before change (empty for initial)
      - `request_id` string
    - `cancelled_at` string, date-time
    - `changes` object: Changes gives an old/new view per submitted kyb_data field for account_update requests: old is the organization's current value (fetched live from Core API), new is the submitted value. Populated on the internal detail endpoint only.
    - `completed_at` string, date-time
    - `created_at` string
    - `declined_at` string, date-time
    - `email_notifications_enabled` boolean: EmailNotificationsEnabled is false when ops have stopped the merchant-facing emails for this request. Webhooks still fire. Ops-only.
    - `id` string: ID is the unique identifier of this request.
    - `internal_note` string
    - `kam_ids` string[]
    - `kyb_data` object: KybData is the KYC/KYB details submitted for this request, as a JSON object.
    - `merchant_note` MerchantNoteDTO
      - `note` string
      - `requested_custom_files` string[]: RequestedCustomFiles are reviewer-typed names for documents outside the purpose list.
      - `requested_fields` string[]: RequestedFields are kyb_data field keys the merchant must resupply.
      - `requested_files` string[]: RequestedFiles are document purposes the merchant must re-upload, without the `files_` prefix.
      - `set_at` string
    - `organization_data` object
    - `pending_clarification_at` string, date-time
    - `processed_at` string, date-time
    - `product_code` 'prd_svc_paymongo_account_activation' | 'prd_svc_paymongo_card_visa_mastercard' | 'prd_svc_paymongo_ewallet_gcash' | 'prd_svc_paymongo_ewallet_grabpay' | 'prd_svc_paymongo_ewallet_maya' | 'prd_svc_paymongo_ewallet_shopeepay' | 'prd_svc_paymongo_std_wallet' | 'prd_svc_paymongo_tax_document' | 'prd_svc_paymongo_account_update': ProductCode identifies the product the request is for: account activation, one of the four e-wallets, card (Visa/Mastercard), Standard Wallet ("Enabled Wallet"), a tax document, or a business-profile update (account_update). All product behaviour keys off this field.
    - `request_type` 'account_update' | 'config_update' | 'onboarding' | 'product_request', required: RequestType classifies the request; it follows from product_code. Nothing branches on it.
    - `requester_id` string, required: RequesterID identifies who initiated the request. Caller-supplied. Required, but not validated for shape and not used for authorization.
    - `status` 'draft' | 'submitted' | 'under_review' | 'pending_clarification' | 'processing' | 'completed' | 'declined' | 'cancelled'
    - `submitted_at` string, date-time
    - `under_review_at` string, date-time
    - `updated_at` string
  - `has_more` boolean

## Other responses

- `400`: Bad Request
- `401`: Unauthorized
- `404`: Not Found
- `500`: Internal Server Error

---

[API](https://skmtc.dev/paymongo/apis/onboarding-api.md) - [All operations](https://skmtc.dev/paymongo/apis/onboarding-api/llms.txt) - [OpenAPI document](https://skmtc.dev/paymongo/apis/onboarding-api/revisions/36885f98768f?raw)