WuKongIM Docs

Conventions

Addressing, JSON, identifiers, cursors, and retry rules for Product HTTP.

The following rules apply to the currently published Product HTTP operations.

Addressing and format

ConventionBehavior
Base URLLocal example: http://127.0.0.1:5001; all paths start at /
RequestPOST uses UTF-8 JSON; /route, /channel/whitelist, and /user/systemuids use GET query parameters
ResponseJSON; endpoints do not share a universal envelope
UID / Channel IDStrings owned by the product
ChannelIdentified by channel_id plus channel_type
Message sequenceOrdered only within one Channel

Check HTTP status first, then parse the endpoint-specific schema. Do not force responses into a universal {data,error} type.

Identifiers and cursors

  • uid is a product identity, not a nickname, connection ID, or device ID.
  • The client view of a person Channel uses the peer UID.
  • message_seq is a per-Channel uint64 cursor. JavaScript must preserve it with a lossless JSON parser, decimal string, or BigInt. message_idstr mirrors only message_id, cannot replace message_seq, and is absent from /message/send responses.
  • next_cursor is opaque. Echo it unchanged until done=true.

For legacy-client compatibility, request objects ignore unknown JSON fields. Callers should still send only declared fields: a typo will not necessarily fail, and extra fields are not an extension mechanism.

State and execution scope

ScopeMeaning
Cluster-durable stateOther nodes can read it after success, while follow-up derived work may still be running
Current-process cacheAffects only the process handling the request; do not assume it survives load-balancer node changes
Owner-local actionThe request node routes or delays a Session action; the HTTP response does not mean that action has finished
Staged writeRemoval, chunked insertion, and derived-flag refresh are not one transaction; verify desired state after failure

The “Operation boundary” callout on each generated operation page identifies the applicable scope and any success check beyond HTTP 200.

Retries

OperationRule
/routeBack off and retry network failures or temporary 5xx
/user/tokenRetry the same identity intent; do not mint tokens in a loop
/channel/messagesyncRetry with the same cursor and tolerate overlap with realtime delivery
Channel mutationReplay the desired state only while the product intent remains valid; reset, set, and remove-all may partially complete
/conversation/listEcho next_cursor unchanged and stop only at done=true
/conversation/retryRetry only the bounded unresolved keys returned by the API

These operations define no universal Idempotency-Key. See Authentication & Security for security requirements and Error Responses for failure classification.

On this page