Configure 字节云 Application Global Balance Sharing

Configure allow_consume_global. After enabling it, eligible pay-as-you-go Applications can continue using the account's global balance when their own balance is insufficient.

Preparation

export PLATFORM_TOKEN='your account token'
export APPLICATION_ID='your Application ID'

API Overview

Item Content
Method POST
URL https://byte.platform.acedata.cloud/api/v1/applications/{application_id}/update-allow-consume-global/
Authentication Account Token
Body JSON 
curl -X POST \
  "https://byte.platform.acedata.cloud/api/v1/applications/${APPLICATION_ID}/update-allow-consume-global/" \
  -H "Authorization: Bearer ${PLATFORM_TOKEN}" \
  -H 'Content-Type: application/json' \
  -d '{"allow_consume_global": true}'

On success, the updated Application object is returned. Please rely on allow_consume_global in the response, rather than assuming that the requested value was necessarily saved.

Applications of the Period type are not allowed to consume the global balance. Even if true is requested, the server will keep this field as false.

Error Handling

  • 401: The Account Token is invalid or missing.
  • 403: The current account is not the owner of the Application.
  • 404: The Application ID does not exist.

For global balance top-up entry points and available plans, refer to the platform console and the actual plans returned by order creation; do not assume that a Wallet type plan exists.

Applications Authorized for Overdraft

When the read-only field allow_overdraft=true of a pay-as-you-go application is set, the application can continue deducting charges from its own balance even if the balance becomes negative, and it will not switch to the global account due to insufficient balance. Applications without overdraft enabled still follow allow_consume_global; after switching, whether overdraft is allowed depends on the settings of the global Application from which the actual deduction is made.

Trial Account Concurrency Limit

The system uses the read-only user flag has_recharged to record whether a paid top-up has ever been successfully completed or credits have been manually added by an administrator. The flag is updated after the operation succeeds, and historical users will be uniformly backfilled based on orders or explicit credit addition records. For accounts that have neither made a paid top-up nor received credits manually added by an administrator, only one billable request is allowed to execute across the entire account at a time; different API Keys and different services share this single slot. Rewards, redemption cards, and transferred credits are not considered paid top-ups. Accounts that have completed a paid top-up or had credits manually added by an administrator are not subject to this trial concurrency limit, and still follow the original balance and credential quota checks.

When an existing request is executing, a new request returns 429 too_many_requests. Free polling APIs such as task queries can still be called normally. Realtime connection authentication continues to follow the original per-round billing process and does not occupy this ordinary request slot.

When an asynchronous API returns “accepted”, the task is still executing, and you need to wait for the final result before submitting the next generation request. A network disconnection or proxy timeout does not mean that the task has stopped; if the task does not reach a final state for a long time, please provide the trace_id to contact support for investigation.

This limit does not change the APIs available for trial use, nor does it change the original billing rules. Charges are still settled based on actual usage after the request ends.