Manage application details, collaborators and versions

Use the Application workspace to maintain Chinese and English details, collaborators and ownership, and record validated configuration versions. Application collaborators manage the Developer Console; customer product access and commercial subscriptions are configured separately.

Configure each feature

Delivered development and operations features are available in your own application scope after creation. Development opens API and permissions by default. Configure login under OAuth/OIDC or identity settings, APIs under API and permissions, and receivers under Events and Webhooks. Saving each resource automatically associates and validates its configuration; no aggregate form or second enable step is required.

Use Commerce → Billing and fulfillment only for billing methods, one-time products, subscriptions, fulfillment, and product access. Select real authorized resources and save once. You can skip commerce when testing login, APIs, or events.

Save customer information and the entry URL under Application publication. Ordinary draft changes preserve the published version. For production, complete applicable testing, create a version, submit one release review, then explicitly publish after approval. Disabling, suspension, and revocation restrict current operation immediately; reopening does not restore an old approval. Consent, resource access, customer payment eligibility, and entitlements remain separate checks.

Update Chinese and English details

1. Open the current Application → Application → Application settings.
2. Select the default language and enter its Application name. Add a description if needed.
3. Enable the other language when needed, enter its name and description, then save.

Configuration	Requirement	Result after saving
Default language	🔴 Required; zh-CN or en-US	Determines the default Application name
Default-language name	🔴 Required	Updates the Application name
Other-language name	🔴 Conditionally required when that language is enabled	Displays the translation; absent translations fall back to the default name
Descriptions	Optional; may be empty	Displays the description for that language

Changing the Console language only changes presentation and does not save Application details. Applications without translations keep their existing names and are not translated automatically. Removing a nondefault language removes its current translation.

Saving updates development configuration. Production customer details follow the approved published version. Changing a language, name or description changes the Application configuration revision. If the result is unknown, recover the original metadata update. For a revision conflict, read current details, review them, then save again.

Add or revoke collaborators

The current Application owner or administrator can assign duties to active members of the same enterprise from “Application → Application collaborators”. If a member has not joined yet, complete invitation and acceptance through Enterprise team first.

1. Select a member from the current enterprise directory and read their current Application relationship.
2. Choose administrator, developer or operator. The operation reason is optional: leave it empty for an automatic operation note, or add a short explanation.
3. Check the current relationship. Use the same steps to change an existing collaborator's duties. Explicitly confirm revocation before submitting.

Role	Default duties
Owner	All application management; transfer and deletion require separate confirmation
Administrator	Details, collaborators, technical configuration, testing and releases; no ownership transfer or deletion
Developer	Basic details, credentials, APIs, events, security, testing, technical logs and feedback; no production publication or collaborator management
Operator	Read non-sensitive details and members, handle feedback and runtime quality; no credentials, technical configuration or publication

Application duties do not grant enterprise administration, customer data, payment or independent platform review authority. If the member directory is unavailable, contact the enterprise administrator. Existing relationships remain visible according to current access. Revoke inactive collaborators or those who left the enterprise without adding them to the member directory again. You cannot change your own duties or the current owner's relationship. Use ownership transfer to change the owner.

For an unknown result, recover the original request with the same member, note and operation identifier. Read the latest relationship after a revision conflict. An old grant request cannot restore access after revocation.

Transfer ownership

Only the current Application owner can transfer ownership. The recipient must be an active member of the same enterprise; the Application stays in that enterprise.

1. Open “Application → Application settings → Transfer application ownership”.
2. Select the recipient and optionally enter a transfer note. An empty note records an automatic operation description.
3. Review the confirmation dialog and confirm. If identity verification is requested, complete sensitive-action verification, return to the Application, then submit explicitly.

After success, the recipient becomes the owner and the previous owner becomes an Application administrator. The Application, Client ID, customer grants and commercial history remain. Previous owner-only actions are cleared from the page.

If the result is unknown, preserve the original request and check current ownership rather than selecting another recipient or creating a second transfer. If current ownership cannot temporarily be verified, choose “Recheck ownership access”. The original recipient, note, revisions and operation identifier stay unchanged, and rechecking never submits a transfer. After a successful recheck, explicitly recover the original request if you still have transfer permission.

If recovery is explicitly denied because ownership changed, read the current Application; contact its new owner after confirming that you no longer have Application access. Read current relationships and confirm again after a revision conflict.

Review and publish an application version

Development and testing need no approval. Save a configuration snapshot in Application → Versions and publishing. Saving creates an immutable draft; it does not deploy software or update production customer entries.

1. Resolve missing configuration for selected capabilities. Enter a SemVer version, notes and references to tests for this configuration. Unused capabilities are not prerequisites.
2. Save the draft, check its frozen permissions, events, details, availability and resource revisions, then explicitly submit for launch review.
3. An independent reviewer approves or returns the version. Creators and submitters cannot approve their own request. Change configuration and create a new version after rejection; withdraw explicitly when needed.
4. Explicitly publish after approval. Publication rechecks current access and resources before updating production customer entries. Approval alone enables no production scope.
5. To stop production operation, explicitly take the version offline and state why. Revocation, suspension and credential rotation constrain current operation immediately. Historical transactions and fulfillment follow their business rules.

Version numbers are unique per application, use SemVer such as 1.0.1, and have a maximum of 96 bytes. Snapshots contain no credential values or event bodies. New drafts and reviews preserve the currently published version, and publication details remain private drafts until publication.

Situation	Action
Configuration is not ready	Complete the selected capabilities and read current state
Review returns changes	Update configuration, save a new version and submit again
Configuration, version or published state conflicts	Read current state and confirm again using current revisions
A save, submission or publication result is unknown	Explicitly recover the original body, revisions and operation identifier
Sign-in or identity verification expires	Verify current access and explicitly continue; recovery never replays a write

Delete an application

The current owner or an administrator allowed to delete the Application can use the danger area in “Application → Application settings”. Confirm the intent, review the impact and enter the exact full Application name. Additional leading or trailing spaces are rejected. You can cancel before final confirmation.

Disable commercial integration and resolve ongoing orders and subscriptions first. Deletion stops Application access and removes it from the application center; commercial and audit history remain. If historical commercial sources or required read access cannot be verified, resolve the displayed issue before deletion.

Recover the original deletion request when the result is unknown. Read current state after a revision conflict. Verification still requires explicit final confirmation; the Console never deletes automatically.

Next: Application security and credentials · Test environment and members · Call logs and quality