Create and test an application

Sandbox supports application development and testing. Use your own account in the Developer Console for the current deployment environment. An account without an enterprise gets a personal space automatically, and the Application creator becomes its owner.

After saving, the platform checks the application, OAuth identity, API access grants and Webhook and enables them without human review. Correct reported errors and retry. Contact support to recover historical applications without a responsible owner.

One independent product uses one Application, with application identity, user identity, or both. Each has separate OAuth client and API permission configuration. The Application Owner can reveal or rotate the application Secret according to the current credentials page. User identity uses PKCE and requires no Client Secret.

For login only, create the Application, enter its callback and copy configuration, then verify login. See Application integration workflow. APIs, events and commerce are optional; unselected capabilities do not block login. The platform resolves the user and customer space, with no fixed customer organization ID; the contract must be enabled in the target environment.

Sandbox is an Application environment, distinct from a GoodVision deployment environment. Successful configuration does not replace organization membership, user consent, resource ACLs, payer eligibility, or webhook endpoint security checks. Retrying does not create duplicates; resources with incomplete configuration are not shown as active.

Prepare the configuration you need

Creating an application requires only a name. Complete other settings when you use the relevant feature. Do not enter secrets, tokens, private keys or customer data in ordinary forms.

Field	Example	Requirement
Application name	Acme Workflow Connector	Stable, human-readable name
Application code	Generated automatically	Optional; expand advanced settings to customize using lowercase letters, numbers and hyphens
Runtime scope	Test (sandbox)	New applications default to testing; production uses separate resources
Application identity permissions	Required / not required	For server jobs and backend API calls
User identity permissions	Required / not required	For actions after user sign-in; exact callback URLs are required
API Product	Published product in the Console	Select when using business APIs
Scopes	Least-privilege set	Configure per Application and environment when using business APIs
Webhook endpoint	https://sandbox.example.com/goodvision/events	Required only for HTTPS reception or synchronous callbacks; long connection needs no public URL
Event types	oem.subscription.expired.v1	Select only types you consume when using events
Contacts	Technical, security, support	Used for incidents, rotations, and deprecations

Create and test the application

1. Open the Developer Console for the current deployment environment with your own account.
2. Check the enterprise or personal space. Retry unavailable initialization; revoked access never silently selects another enterprise.
3. Enter a name to create a Sandbox Application. The platform generates its code and grants the creator ownership. Retain its Application ID.
4. If business APIs are needed, configure permissions for application identity or user identity.
5. Start events with the long connection and server example. Verify an endpoint only for HTTPS reception or synchronous callbacks.
6. When application identity is self_service / “Available for self-service,” retrieve its Client Secret from Credentials and basic information. If the page says delivery is pending, wait for the approved channel. Reveal and rotation require dedicated permissions. User identity explicitly requires no Secret.
7. After actual testing, review applicable tests in Sandbox and launch and confirm once. You may add up to 10 non-sensitive evidence references. Configuration changes require testing and confirmation again.
8. Prepare production configuration, then create a version and submit it for launch review in Versions and publishing. Test confirmation and production configuration can proceed separately. Publish explicitly after approval; approval does not launch the application.

If creation is unavailable, contact the enterprise owner through Enterprise team. If API Products are absent, check the environment catalog. Retry dependency failures as shown; do not use another person's account or request unrelated business privileges first.

Configure identities and API permissions in Developer Console; the platform creates and updates Clients automatically. Integration requires no platform administration or dynamic registration APIs.

Prepare test enterprises and members

“Application → Test environment and members” restricts Sandbox user access. The policy is disabled by default and preserves existing access. When enabled, it allows only currently valid listed members. It does not grant OAuth scopes, consent or product access, and leaves Production and application identity authorization unchanged.

1. Select an available enterprise. Enter a name to create an enterprise for independent testing; its code is generated.
2. Save any list draft before selecting Prepare selected enterprise members. Explicitly confirm the enterprise switch, invite real users in Enterprise team and have them accept personally.
3. Return to the original Application and reread active members. Enable restrictions, select 1–100 testers and save. The operation reason is optional and defaults to a configuration description.
4. Configure user identity, exact callback and required scopes. Have testers sign in to your actual application and call it; verify allowed access, denial after removal and failure recovery.

The enterprise is persistent, not a temporary virtual tenant. Invitations establish enterprise membership without Application collaboration or commercial entitlements. Saving a list does not prove login or API testing. A failed return never restores old Application access.

If you cannot create an enterprise, continue with an existing one and refresh your accessible enterprises. A creation denial clears only the new-enterprise form; selected testers and unsaved settings remain. Test settings are authorized separately for the current Application. If test management access is revoked, the page clears the list and stops related operations. When sign-in expires, sign in again as prompted, recheck current access, and explicitly submit the operation you still need.

Confirm applicable tests

Test	Result to verify
Identity and token handling	Unauthorized or expired identities cannot continue
Implemented writes	Original-request recovery does not repeat business effects
Configured events	Duplicates, ordering, delays and disconnects preserve correct state
Service credentials in use	Rotation preserves connectivity without logging sensitive values
Intended use cases	Testers complete the selected integration in your actual application

The page requires only applicable tests; one confirmation records your declaration of completion. Configuration validation does not test your application. Login-only Applications need no unused APIs, events or service credentials. Recover the original unknown confirmation, reread configuration after a conflict, or correct definite input errors and confirm again. Production requires independent resources and testing.

Get integration configuration

Deliverable	Purpose
Application ID	Identifies the application in API requests and diagnostics
OAuth Client ID	Identifies the Application and environment
Application-identity Client Secret or certificate	Provided only when application identity is enabled; use it only for the approved flow
API product call configuration	Provides Base URL, audience, scopes, schemas, quota, and support information
Webhook secret	Verifies HMAC signatures for one Webhook Subscription

Support tickets never return a secret. Application identity with the required permission can temporarily reveal it from the credentials page. Rotate it when exposure cannot be ruled out; the old Secret becomes invalid immediately after rotation.

Common states

State	Meaning	Next action
configuration_required	Configuration is incomplete	Complete the settings indicated by the current page
active	Configured and enabled	Start testing with the current application’s API configuration
self_service	OAuth client issued; the Secret is available through the credentials page	Temporarily reveal or rotate it from the credentials page
pending_delivery	OAuth client issued; service credential delivery is not yet confirmed	Wait for the approved channel; never request the original value in a ticket
sandbox_ready	Applicable tests for the current configuration are confirmed	Check production configuration and create a launch version
suspended / paused	Temporarily unavailable	Review the reason and follow the recovery process
revoked	Permanently revoked	Create a new application to continue development; do not reuse old credentials