cybozu.com vs kintone.com — understanding Kintone domain differences
Look closely at Kintone and you notice two distinct domains: cybozu.com and kintone.com. Same product, different domains — why? And why do plugin selections need to account for which one you're on? This post covers the differences that actually matter in production.
The short version
cybozu.com is the legacy Japan-domestic Kintone domain, running on Japanese data centers. kintone.com is the post-2017 unified domain for new contracts and international expansion. Same product, but differences in contract structure, data residency, and plugin compatibility. When selecting plugins, always verify the vendor tests on both domains.
Historical background
Kintone launched in 2011 for the Japanese domestic market, hosted on the cybozu.com domain — leveraging parent company Cybozu's existing infrastructure and brand.
As Kintone expanded internationally (US, China, Southeast Asia) in the mid-2010s, a dedicated kintone.com domain was established. In overseas markets, the product name "Kintone" carries better than the parent brand "Cybozu."
Today:
your-company.cybozu.com— Many Japanese customers contracted between 2011-2017. Still actively in use.your-company.kintone.com— New contracts post-2017, and the international standard.
Both are the same Kintone product, but with differences in contract period and operating infrastructure.
Technical differences
Data residency
cybozu.com domains run on Japanese data centers only. kintone.com contracts allow region selection (Japan, US, Southeast Asia, China) at contract time.
Japanese financial, healthcare, and public-sector organizations frequently have data-residency audit requirements specifying domestic data storage. cybozu.com satisfies this by default. For kintone.com contracts, the "Japan region" must be explicitly selected in the contract.
Authentication and SSO
SAML SSO, IdP integration, and OAuth configuration provide the same feature set on both domains. But the admin URLs differ, so SSO providers must register both domains as separate applications.
Example: configuring SSO with Okta, you'd register https://your-company.cybozu.com/k/ and https://your-company.kintone.com/k/ as separate applications. Running both domains requires both registrations.
API endpoints
API endpoints also differ by domain:
// cybozu.com domain
https://your-company.cybozu.com/k/v1/records.json
// kintone.com domain
https://your-company.kintone.com/k/v1/records.jsonFor a plugin to work on both domains, it must determine the API endpoint dynamically. The common implementation reads location.hostname at runtime.
Plugin distribution differences
Plugin installation is the same method on both domains (upload .zip file). But if the plugin's internal implementation hard-codes domain-specific logic (API endpoints, CORS, auth headers), it may work on one domain and fail on the other.
This happens in practice regularly: "It works in test (cybozu.com) but breaks in production (kintone.com)" — or the inverse. Vendor QA gap.
Verification checkpoints during plugin evaluation
When evaluating a plugin, explicitly confirm:
- Both-domain verification: ask the vendor directly: "Is this plugin tested on both cybozu.com and kintone.com?" Vague answers = domain-switch risk.
- When test and prod are different domains: run trial on both. Bugs that only manifest on one domain surface during migration.
- Future migration planning: if currently on cybozu.com, may migrate to kintone.com. Plugin portability becomes a requirement.
Common confusion points in practice
"What's your Kintone subdomain?" requests
When a plugin vendor or consultant asks for your Kintone subdomain, include the domain. Just your-company is ambiguous. Provide one of:
your-company.cybozu.comyour-company.kintone.com
URL rewriting doesn't cross domains
You cannot access your-company.cybozu.com by typing your-company.kintone.com in the address bar. The contract locks the domain. Different domain = different Kintone environment, even for the same company. Infrastructure and contract reasons.
IP whitelist environments
In enterprises with IP restrictions, whitelist both *.cybozu.com and *.kintone.com. Missing one risks failures when plugins load resources (e.g., Google Fonts) that go through CDNs sharing infrastructure with the other domain.
kinplug status on both domains
All kinplug plugins are tested on both cybozu.com and kintone.com. API endpoints are dynamically determined from location.hostname. Domain-specific logic branches internally where needed.
In production: 8 customer subdomains, split across both domain types. Including a large financial-group cybozu.com environment (43 apps) and multiple insurance-industry kintone.com environments. Stable operation regardless of domain.
Summary
For most day-to-day operations, the cybozu.com vs kintone.com distinction doesn't matter. But it becomes decisive in specific contexts: plugin selection, SSO configuration, IP-restricted environments, data-residency audits, and international expansion. Choosing vendors that support both domains preserves flexibility for future domain migrations and multi-region deployment.
Related reading
Try kinplug free for 14 days
No credit card. Sign in with Google or Microsoft, enter your Kintone subdomain, and go live in 90 seconds.