Workspace Setup

Use this page when you create a workspace, take over ownership, or prepare a team handoff.

This is the entry point for operators who use Console and the Admin Panel. For app implementation, start with Quickstart and the domain task guides. A completed task guide covers that app task only; before launch, also run the operating checks on Launch Readiness.

Before changing anything, confirm the active workspace in Console. A role in one workspace grants no access to another; a workspace name, cookie, or header does not grant membership.

Select the target workspace before saving workspace access, embedded administration, notification and sender email, sender domain, or market settings. The server rejects a save when no workspace is selected or the target differs from the active workspace. This also applies when you administer both workspaces or have platform administrator access. Select the workspace again, review the settings, and save.

Setup StepsCopy Anchor Link

BrandingCopy Anchor Link

Enter your logos and business details in Console under Settings → Site & branding → Branding · SEO · Business. They are used in these places:

The business name comes from the business details, then the site title, then the workspace name. Email does not show SVG logos, and the customer sign-in page shows only logos on the 01 SOFTWARE media CDN.

Operator screens before a workspace is chosen, such as Console sign-in, password reset, and MFA, show 01 SOFTWARE. The customer sign-in page follows the customer's language preference and shows Korean or English.

Social login app credentialsCopy Anchor Link

Workspace administrators manage Google, Kakao and Naver app credentials in Settings → Integrations → Social login credentials.

1. Select a provider and enter the app's Client ID and Enter or replace client secret.
2. Copy the displayed Callback URL to register in the provider app into the app settings exactly. Its path is /customer-oauth/social/{provider}/callback, under the customer sign-in issuer.
3. Save. Saved secrets cannot be displayed or retrieved.

Enter a new secret and save to replace the secret for the same app. Blank input keeps the existing value. To remove it, select Discard saved secret and save. Replace and discard must be separate saves. Disposal retains Client ID; enter a secret for the same app to configure it again. Client ID cannot change while linked customers exist, including suspended or archived customers. Deleting the configuration cannot bypass this restriction. Changing apps without linked customers also requires replacing or discarding the secret.

Live sign-in uses your workspace app only. With no saved secret, or after disposal, the provider is hidden and new sign-in attempts are refused. The OAuth client's enabled provider selection must also include that provider. You may save that selection before entering credentials; it remains incomplete. Sandbox uses the platform's shared development app, never Live credentials. Sandbox configuration apply does not copy credentials to Live. Replacing a secret invalidates sign-in attempts that started with the previous credentials; start again after replacement. Previously saved Kakao enablement takes effect when credentials are ready. Naver sign-in is not available yet.

Set up Google sign-inCopy Anchor Link

1. In Google Cloud / Google Auth Platform, create or select your workspace's project. Configure Branding, Audience and Data Access for your service, including its support contact.
2. Create an OAuth client of type Web application. Under Authorized redirect URIs, enter the exact Google callback shown in Console, usually https://01.software/customer-oauth/social/google/callback (staging uses its own issuer). This is the provider callback; your storefront's redirect URI belongs on the customer OAuth client.
3. Enter that Google client ID and secret in Social login credentials, save, then enable Google on the workspace's Customer OAuth client.
4. If the Google app is in testing mode, add test users before testing sign-in. Production use must meet Google's current publishing and verification requirements.

Google requests openid email profile. Sign-in requires a nonempty, verified email. The stored customer data is email, name and provider identity; phone, birth date, gender and profile photo are not saved. These requested app scopes and the stored customer fields are different things; there is no scope selector.

Displaying your app name on the consent screen requires Google branding approval. Google may require verified ownership of the callback domain. The hosted callback belongs to 01 SOFTWARE, so a workspace may be unable to complete that domain check. An unapproved app may show a domain or an unverified-app notice instead. App registration, publishing, review and branding approval belong to the workspace.

See Google OAuth setup and Google branding verification.

Set up Kakao sign-inCopy Anchor Link

1. Create an app for your workspace service in Kakao Developers. Add an app icon. As the app owner, use App → General → Business information → Register business information to enter your business details and convert it to a Biz app. Without a business registration number, follow the Individual developer Biz app procedure in the same menu. The workspace handles app registration and additional consent permissions or review.
2. Enable Kakao Login → Usage settings and OpenID Connect. In Consent items, set Kakao Account (email) (account_email) to Required consent and Nickname (profile_nickname) to Optional consent. If required email consent is unavailable, confirm that the Biz app conversion is complete.
3. Under App → Platform Key → REST API key, register the exact Kakao callback shown in Console as a redirect URI. It is normally https://01.software/customer-oauth/social/kakao/callback; staging uses its own issuer. Register your storefront redirect URI separately on the customer OAuth client.
4. Enable Client secret for the same REST API key. In Console Social login credentials, select Kakao, enter the REST API key as Client ID and its client secret as Enter or replace client secret, then save. Use the REST API key rather than an Admin or JavaScript key.
5. Enable Kakao on the Customer OAuth client. Live uses this app. Sandbox uses the shared platform development app when configured.

Sign-in omits scope so Kakao uses the app's consent settings and issues an ID token with OIDC enabled. Keep email required; nickname may be optional or disabled. Declining nickname does not block returning sign-in. If OIDC is disabled, no ID token is issued and sign-in fails.

Accounts with a missing or unverified email create no Customer record. The storefront redirect receives error=provider_missing_claims for missing email or error=provider_email_unverified for unverified email. Check required email consent, verify the Kakao Account email or use another sign-in method.

The stored provider attributes are email, nickname and the provider identifier only. Phone, birth date, gender and profile photos are not stored.

Keep other consent items disabled for this integration. If other consent items are enabled, they also appear on Kakao's consent screen and customers can consent to providing that information. The stored fields stay the same. Reflect both the items displayed on the consent screen and the fields stored by this integration in your service privacy policy.

If you reused an existing service app or changed email from optional to required, first confirm that the app requires email consent. Customers should sign in again and consent to email. After an optional item becomes required, Kakao automatically shows its consent screen at the next sign-in for customers who have not agreed to it. If provider_missing_claims repeats, first check that OIDC is enabled and email consent is required in the app settings.

See Kakao Login settings, Biz apps and consent permissions and OIDC and consent scopes, additional consent for existing users and Kakao staff's explanation of required consent changes.

Enterprise usage billingCopy Anchor Link

Enterprise is not a self-service plan. It is usage-based billing calculated from a contract rate card for each workspace. To start, contact sales at software@01.works.

Review contract terms and register a cardCopy Anchor Link

1. After sales activates a rate card for your workspace, they send a contract-terms link that opens the 01.software subscribe page.
2. Sign in as a tenant-admin of that workspace and open the link. The page shows the contract rate card name, base fee, monthly minimum charge, effective period, charge at card registration, pre-charge notice period, and each meter's unit price, bucket, and included allowance.
3. Review the terms, then register a card. The charge at registration is KRW 0, and registering a card does not charge you.

If the page says the terms cannot be verified, ask sales whether the link is current. If the terms change during registration, registration does not proceed and the latest terms are shown again; review them and register again. The effective period shows the dates recorded on the contract rate card; any price change or price hold across periods follows your contract.

How charges are calculatedCopy Anchor Link

Charges are calculated per calendar month in Korea Standard Time (KST).

billable units per meter                = max(0, ceil(usage ÷ bucket size) − included allowance)
meter amount                            = billable units × unit price
subtotal                                = base fee + sum of meter amounts
amount before adjustments and exemption = max(subtotal, monthly minimum charge)

When service starts or ends mid-month, the base fee and monthly minimum charge are prorated. Service days are the time from service start to end within that month, rounded up to whole 24-hour periods; they are not a count of calendar dates touched. Each amount is multiplied by service days ÷ days in the month and rounded up to the next KRW.

The finalized invoice total is the amount before adjustments and exemption plus any adjustment recorded before the notice (floored at KRW 0); if that result is KRW 1–99, the exemption described in the billing state step above applies. See Check the estimate and finalized invoices.

The rate card has the following six meters, which use the usage snapshot of the closed month.

Storage and documents use the last successful sample taken while that month was current. A decrease during the month is reflected in the next successful sample; a failed sample refresh preserves the previous successful sample. They are not a monthly average, a peak, or a value accumulated over time. Check the per-meter breakdown on the finalized invoice for the quantities actually billed.

Check the estimate and finalized invoicesCopy Anchor Link

A tenant-admin opens the workspace from the 01.software dashboard and uses the Billing tab to check:

• Current usage estimate: a non-final amount calculated from usage recorded so far in the current month and the active rate card. The finalized invoice may differ.
• Usage invoices: finalized invoices for closed months. Each shows status (Finalized, Charged, Failed), total, base fee, usage overage, floor adjustment, notice date, charged date, and a per-meter breakdown (usage, bucket, included, billable units × unit price = amount).

An invoice total can reflect the KRW 1–99 exemption or an adjustment recorded before the notice, so it can differ from the sum of base fee, usage overage, and floor adjustment. A finalized invoice is not changed by later rate card edits or usage recounts.

Settlement and charge timingCopy Anchor Link

• A month's usage has a settlement period through the 5th of the next month (KST). Finalization in scheduled processing after this period depends on current invoice issuance availability. The invoice creation date is not fixed.
• When an invoice is finalized, an email notice of the finalized amount is sent to the workspace tenant-admins. The notice date is recorded once at least one email is sent; delivery to every recipient is not guaranteed, so check the notice date in the Billing tab.
• Charging is attempted in scheduled processing at least 7 days after the notice date. The exact charge date is not fixed; check the charged date for when payment was taken. A KRW 0 invoice is marked charged without a card payment.
• If the card is declined, the invoice shows as failed. Check the status in the Billing tab and contact software@01.works.

Billing questions and refundsCopy Anchor Link

Send questions about invoice amounts or refunds, including refund eligibility and processing time for a usage invoice, to software@01.works. Refund requests follow the refund policy.

Platform super-admin operators review and approve billing-error corrections in the Admin Panel. Workspace administrators have no permission to run corrections and no self-service refund screen. An unclear provider result stays under review and cannot be resent. A correction preserves the original invoice, subscription, and service access, and does not resume new Enterprise billing.

First actions on Console HomeCopy Anchor Link

In an empty workspace, Console Home shows only No activity to show yet and a View diagnostics link. A workspace with ecommerce enabled and no product or order yet also shows this message instead of empty commerce cards. Check setup status in Workspace Diagnostics.

Add teammates with the Invite teammates steps.

Commerce KPIs open screens filtered to the displayed workspace. Orders awaiting processing and Today's orders open the order list for that status or date, Refunds pending opens the returns list, and Low-stock items opens the inventory page with the low-stock filter. Check today's sales in the Today range of the Sales report on the same Console Home. If the sales report cannot load, an error notice with Try again appears in its place, and the KPIs and recent orders remain visible. Normal zero and Capped distinguish an actual aggregate value from a bounded aggregate value.

Operating rhythmCopy Anchor Link

• Weekly, a tenant-admin reviews access, content queues, failed webhooks, and readiness blockers.
• Monthly, the workspace owner reviews plan, billing, quotas, keys, and unused features.
• During an incident, the workspace owner pauses launch or customer exposure when billing, keys, CORS, commerce, or moderation is blocked.

Access RolesCopy Anchor Link

The exact operator roles are listed below. super-admin is a platform role; the other three are assigned per workspace. Customer accounts are separate from operator accounts.

The workspace owner is an ownership relationship, not a fifth role. Ownership controls transfer and deletion; ordinary administration still checks the operator's workspace role. Use individual logins and review access per workspace.

Handoff ChecklistCopy Anchor Link

• workspace owner is current
• at least two trusted admins exist
• temporary access is removed
• billing state is clear
• enabled feature owners are named
• launch support and moderation owners are named

Next ActionsCopy Anchor Link

• Choose enabled areas in Feature Planning.
• Review credentials in Integrations & Keys.
• Run the final check in Launch Readiness.