# FAQs > **Last updated:** Apr 23, 2026
> **Summary:** This guide helps brokers quickly integrate with the WEEX OAuth service. --- ## Should the authorization flow be handled by the frontend or the backend? We recommend a "frontend-initiated, backend-driven" approach. The full flow is as follows: 1. **Initiate authorization**: The frontend calls your backend to start the flow. The backend generates the `state`, `code_verifier`, and `code_challenge`, constructs the full authorization URL (including all parameters), and creates an authorization task with an `INIT` status. The backend then returns this URL to the frontend. 2. **Redirect to authorization page**: The frontend redirects the user to the provided URL, where the user completes login and grants permission on the authorization page. 3. **Handle callback**: Upon success, the OAuth server redirects back to your backend with `code` and `state`. The backend validates the `state`, exchanges the code for an access token via the `/token` endpoint, and calls `create-api`. Finally, it saves the binding results and updates the task status to `SUCCESS` or `FAILED`. 4. **Redirect to result page**: Once the backend processing is complete, it redirects the user to your frontend API Key page. 5. **Display result**: The frontend calls your backend to query the binding status and displays the result. --- ## What are the requirements for state? The `state` must be generated by your backend and should be random, unique, and single-use. It must also have a short TTL. When the backend receives the OAuth callback, it must verify that the `state` matches the one stored, hasn't expired, and belongs to a task in a valid state. This is critical for preventing CSRF and replay attacks. --- ## What should I know about PKCE (code_verifier / code_challenge)? The `code_verifier` must be generated and securely stored by your backend. It is required later when exchanging the authorization code for an `access_token`. The `code_challenge` is derived from the `code_verifier`. The `code_challenge_method` is fixed to `S256`. The frontend should never handle or transmit the `code_verifier`. --- ## In what order should the backend process the OAuth callback? Once the backend receives the request containing the `code` and `state`, it should execute the following steps: 1. Retrieve the corresponding task using the `state` and validate its integrity. 2. Update the task status to `PROCESSING`. 3. Exchange the `code and code_verifier` for an `access_token` via the `/token` endpoint. 4. Call the `create-api` interface using the `access_token`. 5. Store the binding result (or failure reason) and update the task status to `SUCCESS` or `FAILED`. 6. Redirect the user to the frontend API Key page. --- ## Can sensitive information like apikey or secret be returned to the frontend via URL? No, this is not recommended. After processing the callback, your backend should redirect the user to a frontend page (such as `/platform/apikey`) and let the frontend retrieve the binding result via an API call. `apikey`, `secret`, `passphrase`, and plaintext error details should never appear in URL parameters, nor should they be recorded in standard application logs. --- ## Broker sub-account API ## How many users can sign up in a single request? Up to 10 users. Exceeding this limit will result in a parameter validation error. --- ## What happens if authorities is omitted when creating an API key? Only the read-only `ACCOUNT_DETAILS` permission is enabled by default. --- ## When is an IP allowlist required? When creating or updating an API key, `ipWhiteList` is required if any permission other than `ACCOUNT_DETAILS` is enabled. --- ## Can the secret be retrieved again? No. The `secret` is returned only once when the API key is created. Store it securely. --- ## Why does the sign-up endpoint return separate success and failure lists? The endpoint supports batch sign-ups. A failed sign-up does not affect other successful sign-ups, so successful and failed users are returned in separate lists. --- ## Why can't I deposit or withdraw? Deposit and withdrawal permissions are required. --- ## How do I determine the asset and network parameters? Call the spot API `GET /api/v3/coins` to get the asset and network configurations. The specified network must be supported for the selected coin, with deposits or withdrawals enabled as applicable. --- ## What values does accountList support for withdrawals and transfers? Supported values are `11` (funding account), `10` (spot account), and `8` (futures account). The list cannot be empty. The server preserves the specified debit order and removes duplicate values. --- ## When is addressTag required? `addressTag` is required if the asset network requires a Memo/Tag. Otherwise, error `-2435` is returned. It can be omitted for networks that do not require a Memo/Tag. --- ## What happens if network is omitted for an internal transfer? The server uses the network marked as default for the asset in `GET /api/v3/coins`. Although internal transfers do not involve on-chain transactions, the withdrawal status and minimum amount are still validated based on the selected network.