Competitor API Naming Pattern Analysis
1. Casing Conventions
| Competitor | Casing | Confidence |
|---|
| HypeAuditor | snake_case | HIGH |
| Modash (Discovery API) | camelCase | MED |
| Modash (Raw API) | snake_case | MED |
| Phyllo | snake_case | MED |
| CreatorDB | camelCase | — |
2. Follower/Subscriber Terminology
| Competitor | Instagram/TikTok | YouTube |
|---|
| HypeAuditor | followers_count | subscribers_count |
| Phyllo | follower_count | subscriber_count |
| Modash | followers | followers (same term for all) |
| CreatorDB | totalFollowers | totalSubscribers |
followers universally.
Assessment: CreatorDB’s approach of using totalFollowers (IG) and totalSubscribers (YT) aligns with the majority pattern. The total prefix is unique to CreatorDB but provides clarity that this is a cumulative count.
Recommendation: Keep the current platform-specific terms. This is already documented as an intentional cross-platform difference.
3. Display Name vs. Username vs. Full Name
| Competitor | Display Name Field | Handle Field |
|---|
| HypeAuditor | full_name | username |
| Phyllo | full_name | platform_username |
| Modash | (n/a) | userId |
| CreatorDB (YT) | displayName | uniqueId |
| CreatorDB (IG) | username (confusing) | userId |
username for the display name concept, which is the opposite of industry convention where username means “handle.” This is the most confusing naming inconsistency in the current API.
Recommendation: See creatordb-naming-recommendations.md for detailed recommendation.
4. Nesting Depth
| Competitor | Style | Example |
|---|
| HypeAuditor | Deep nesting | audience_geography.countries[].code (3 levels) |
| HypeAuditor | Deep nesting | subscribers_growth_prc.performance.7d.value (4 levels) |
| Modash | Flat | audienceGeo (1 level) |
| CreatorDB | Moderate | audienceLocations[].country (2 levels) |
| CreatorDB | Moderate | videosPerformanceRecent.likes.avg (3 levels) |
videosPerformanceRecent.likes.avg) have 3 levels, which is manageable. The audience objects (audienceLocations[].country) use 2 levels, which is clean.
Recommendation: No change to nesting depth. Current approach balances readability with structure.
5. Time Bucket Naming
| Competitor | Pattern | Example |
|---|
| HypeAuditor | Explicit day suffix | performance.7d.value, performance.30d.value |
| CreatorDB | Abbreviated object keys | subscriberGrowth.g7, subscriberGrowth.g30 |
7d/30d/90d (more readable). CreatorDB uses g7/g30/g90 (shorter, established internal convention).
Assessment: The g prefix stands for “growth” and is already an established abbreviation in the CreatorDB codebase. Changing it would be a breaking change. The 7d/30d format is more self-documenting, but g7/g30 is adequate once the convention is learned.
Recommendation: Keep g7/g30/g90. Document the convention clearly. This is established and a breaking change is not worth the marginal readability improvement.
6. Engagement Rate Naming
| Competitor | Term | Notes |
|---|
| HypeAuditor | er / er.avg | Extremely abbreviated |
| Modash | engagementRate | Full camelCase |
| Phyllo | engagement_rate | Full snake_case |
| CreatorDB (aggregate) | avgEngagementRate | Prefix distinguishes from per-content |
| CreatorDB (per-content) | engagementRate | Used in content arrays |
avg prefix. HypeAuditor abbreviates to er (poor practice). Modash and Phyllo use the full term.
Assessment: CreatorDB’s dual naming (engagementRate for per-content, avgEngagementRate for aggregate) is more precise than competitors. However, it is unique in the market. The precision is valuable because CreatorDB exposes both per-content and aggregate rates in the same API, unlike most competitors.
Recommendation: Keep the dual convention. It prevents ambiguity that competitors avoid by not exposing per-content rates alongside aggregates.
| Competitor | Term | Structure |
|---|
| HypeAuditor | advertising_data.brand_mentions[] | Flat brand list |
| CreatorDB (IG) | sponsorList[] | Grouped by brand with nested content |
| CreatorDB (YT pricing ref) | sponsoredContent[] | Same structure, different name |
sponsorList (IG) vs. sponsoredContent (YT pricing ref). This needs resolution regardless of what competitors do.
Recommendation: See creatordb-naming-recommendations.md for detailed recommendation.
8. Per-Follower / Per-Subscriber Metrics
| Competitor | Term | Example |
|---|
| HypeAuditor | Not exposed at field level | (uses er as aggregate) |
| CreatorDB (YT) | likesPerSubscriber | Under engagement object |
| CreatorDB (IG) | likesPerFollower | Under engagement object |
PerSubscriber for YT, PerFollower for IG) is the right approach — it mirrors the totalSubscribers/totalFollowers convention.
Recommendation: Keep platform-specific terms. This is consistent with the established totalSubscribers/totalFollowers pattern.
Summary of Key Patterns
| Decision Area | Industry Consensus | CreatorDB Alignment | Action |
|---|
| Casing | Mixed (leans snake_case) | camelCase (defensible) | No change |
| Follower/subscriber terms | Platform-specific | Aligned | No change |
| Display name | full_name | displayName (YT) / username (IG — WRONG) | Fix IG |
| Handle | username | uniqueId (YT) / userId (IG) | Document as intentional |
| Nesting depth | No consensus | Moderate (good) | No change |
| Time buckets | 7d/30d | g7/g30 (established) | No change |
| Engagement rate | Single term | Dual (more precise) | No change |
| Sponsorship arrays | No consensus | Internally inconsistent | Fix cross-platform |
| Per-follower metrics | Not offered by others | Platform-specific | No change |
Last modified on March 25, 2026
