KYC action request fulfillment

When a reviewer requests changes on a KYC profile version, DALP opens an action request that tells the user what to fix. After the user resubmits the corrected data, the application marks that action request as fulfilled. This endpoint records the fulfillment and clears the profile's pending-update flag once nothing else is outstanding.

Fulfillment closes the loop that KYC reviewer version actions opens with a request for changes. A reviewer's request-update decision creates an open action request against the user's KYC profile; this call resolves it. The operator walkthrough in the Console lives in Provide KYC data.

Prerequisites

• The caller owns the KYC profile the action request belongs to. A user can fulfill only their own action requests.
• The action request is in open status. A request that is already fulfilled cannot be fulfilled again.

Fulfill an action request

Fulfilling moves the action request to fulfilled and records the fulfillment timestamp. DALP then checks whether the user has any other open action requests across their KYC versions. When none remain, it clears the profile's pending-update flag, which is how the profile signals it no longer needs the user's attention.

Call this endpoint when your application drives the change-request loop directly, for example after the user resubmits the corrected version. When a reviewer approves a resubmitted version instead, DALP fulfills the user's open requests as part of the approval, so you do not call this endpoint for that path.

const fulfilled = await client.user.kyc.actionRequest.fulfill({
  params: { requestId: "kycar_01hzt7n4openrequest001" },
});

Direct HTTP integrations call POST /api/v2/kyc-action-requests/{requestId}/fulfillments.

{
  "data": {
    "id": "kycar_01hzt7n4openrequest001",
    "status": "fulfilled",
    "fulfilledAt": "2026-05-24T10:31:08.442Z"
  }
}

The requestId is the action request ID a reviewer's request-update decision returns. Read it from the actionRequest.id field on that response, or from a profile's open requests when you show the user what is outstanding.

State transition

Fulfilling an action request does not move the KYC version itself. The version follows its own submission lifecycle: the user edits the draft DALP created for the change request, then resubmits it for review. See KYC version submission for the create, edit, and submit steps.

CLI equivalent

The DALP CLI exposes the same step for operator scripts. Reach for it when a back-office job is easier to run outside the SDK:

Validation and error handling

Fulfillment returns two classes of error, and your retry logic should treat them differently. A terminal error means the request or its state is wrong, so a blind retry fails the same way. An operational write failure means the call passed validation but an internal write did not complete. These are marked non-retryable, so do not resend the same call automatically.

Terminal request errors

Treat these as terminal unless the response says otherwise. Confirm the request status and ownership before retrying, and store the request ID from the API response when you escalate a repeated platform error.

Operational write failures

This returns HTTP 500 after the call passed validation: DALP confirmed the request is open and belongs to the authenticated user, then the write that marks it fulfilled returned no result. Retry the fulfill request. If the error persists, contact support with the request ID.

Related

• KYC reviewer version actions
• KYC version submission
• Provide KYC data
• Platform API error reference