Skip to main content

verify_user_bind

Completes a user authorization started by request_user_bind: auth_type=sms verifies with bind_id + the verification code; auth_type=h5 polls the authorization status via request_id. On success, it mints and returns the consent_grant_id used by subsequent business tools. This is the closing step of the binding flow and needs only the Agent identity (connection-layer Authorization: Bearer clw_); it does not take a consent_grant_id parameter.
Binding flow (the closing step): request_user_bind → get bind_id (sms) or request_id (h5) → user receives the code / opens the link to authorize → verify_user_bind → exchange for consent_grant_id → call business tools with that consent_grant_id.
Re-authorization rotates the grant: every successful binding for the same user mints a new consent_grant_id, and the old one stops working. The plaintext consent_grant_id is returned only once in this response (only its hash is stored); save it carefully.

Parameters

The parameters required differ depending on auth_type.
Field requirements are conditional on auth_type: missing bind_id or code in sms mode, or missing request_id in h5 mode, returns an error. These IDs must be passed back from request_user_bind as-is — do not fabricate them.

Returns

Success (authorized):
Not yet authorized when polling in H5 mode: while the user has not finished authorizing in the link, this tool returns a pending state rather than an error. Clients should retry later per next_action, and must not treat the pending state as a failure.
H5 pending / expired:

Error Codes

See Error Handling for the full list.

Call Example

SMS mode:
H5 mode: