Developer Console
The Developer Console lets you create Applications, configure authentication and API access, receive events and complete integration acceptance. Use your own account; an account with no enterprise gets a personal space automatically. The creator becomes the Application owner. Ordinary members collaborate with current access without preparing business roles first.
Development configuration needs no human review. To launch, create a version, submit it for review and publish after approval.
Manage Applications
The application center supports grid and list views, with search and filters for name, Slug, environment, status, and type. Select an Application, then open the required page from the sidebar.
The Workbench, Commerce, Application and Developer integration workspaces remain, with the sidebar showing only the current workspace. Creating an ordinary Sandbox Application requires a name; its code is generated and advanced fields are optional.
| Page | Main functions |
|---|---|
| Overview | View Application information and integration progress |
| Credentials and basic information | View identifiers and retrieve or rotate application credentials |
| OAuth/OIDC configuration | Configure user identity, callback URLs, and sign-in parameters |
| Billing and fulfillment | Configure pricing, plans and fulfillment when needed |
| APIs and permissions | Configure API access and obtain call configuration and code templates |
| Events and webhooks | Start with long connection; optionally configure HTTPS and synchronous callbacks with separate test results |
| Sandbox and launch | Confirm applicable tests and prepare separate production configuration |
| Versions and publishing | Create a version, submit for review and publish; new drafts preserve the published version |
| Application collaborators and settings | Manage collaborators, translations, ownership and deletion |
| Test environment and members | Prepare real members and Sandbox restrictions |
| Security settings | Restrict OAuth source IP addresses |
| Server logs, quality and client logs | Query seven-day records and full-window metrics |
| Support and feedback | Submit, track and explicitly forward to platform support |
Application development workflow links to guides for creation, development, testing and publishing.
Configure API access
In APIs and permissions, select Application identity or User identity, then choose the API product and scopes. Click Request access to validate and enable access automatically. Each configuration targets one identity.
Product names, descriptions, and scope descriptions support Chinese and English. When a translation is unavailable, the page uses the default description and shows a notice. Scopes, audiences, versions, and paths use the fixed identifiers provided by the product.
GoodVision's managed identity service provides sign-in and tokens, while the platform validates organization and API permissions. Use only the Client, issuer, audience, scopes, and API address shown by the Console; platform administration interfaces are not part of the developer contract.
After saving, the platform automatically validates the configuration and updates OAuth clients and permissions. Developers do not need to register or modify platform credentials through administration APIs.
The page provides copy-ready non-sensitive environment configuration and code templates for service tokens, API calls, and user PKCE sign-in. Templates use placeholders and contain no valid tokens, Client Secrets, or Webhook Secrets. TypeScript/Node.js projects can install the official SDK; other languages can continue with the current API documentation and templates.
Get credentials
When application identity is self_service / “Available for self-service,” you can temporarily reveal or rotate the Secret as shown on the credentials page. The value stays masked by default and is cleared when you leave the page or switch organization or Application. User identity uses PKCE, has no Client Secret, and can edit allowed application URLs on the OAuth/OIDC page. Ordinary pages, documentation, logs, and configuration exports never include the Secret.
View call diagnostics
With current Application log access, use Server logs or Quality overview for records within the last seven days and full-window request count, success rate, errors and P95. URLs show public templates. User OpenID, method and fixed error descriptions are searchable; absent historical fields remain unknown. Client logs show reports separately and do not prove server execution.
Queries include only the current organization and Application. The page does not show request or response bodies, headers, tokens, secrets, cookies, customer data, or free-form error messages.
Related guides: Application integration workflow · Entry points and permissions · Manage application configuration
Expired sign-in can be recovered on the original page. The same person and valid scope can retain ordinary drafts; temporary Secrets and sensitive confirmations are cleared. Verification never automatically replays business actions. See Sign-in and recovery.