Creator accounts & legacy API fields
How Fangate describes accounts publicly, and which user-profile fields are legacy or internal—so you do not build client logic on outdated values.
Public positioning
Fangate should be described as supporting creator accounts: people who sell digital content and services through one-click links. Marketing and integrations should not hinge on historical labels such as “business-only” vs “private-only” signup.
type and related fields (legacy / internal)
The API and database may still expose a type field on the user object (e.g. values such as business or private). These come from an older setup when Stripe Connect was used in a more prominent way for registered businesses (including sole proprietors), and when private was introduced for natural persons.
Today:
privateis the value actually in use for current creator-facing flows.- Values such as
businessmay still appear on older records or in examples generated from legacy data.
Integrators should:
- Not build product UX or branching logic on
typeunless a future API document explicitly defines supported values and behavior for your use case. - Treat
typeas legacy/internal metadata that may evolve.
Stripe Connect (stripe_url, stripe_account_id)
Fields such as stripe_url (Connect onboarding link) or stored Stripe Connect account IDs reflect legacy or internal payout/KYC plumbing. They are not a stable contract for third-party clients to depend on for feature flags or UI.
Do not assume every creator has a non-null stripe_url, and do not use it to decide “business vs private” in new integrations.
Summary
| Item | Guidance |
|---|---|
| Creator positioning | Describe creator accounts for Fangate. |
type | Legacy/internal; private is what current clients use; do not branch on business without explicit docs. |
| Stripe Connect fields | Legacy/internal; do not drive frontend logic from them. |