Migrate Pricing Best Practices page from docs.beamable.com to help.beamable.com

[allister-beamable]

Background

The legacy docs site docs.beamable.com has a Pricing Best Practices page at https://docs.beamable.com/docs/best-practices that gives customers strategic guidance on minimizing API usage costs (don't poll, subscribe narrowly, batch APIs, monolithic microservice, etc.). It also lists the billable endpoints and gives a rough efficiency target ("<1,500 API calls per MAU").

There is no equivalent page in the new docs (help.beamable.com / this repo). A recent customer support thread surfaced confusion that the existing page would not have fully resolved either, so this is both a migration task and an expansion opportunity.

What to migrate

Port the existing content from https://docs.beamable.com/docs/best-practices, then add the following sections to address the gaps observed in support:

1. SDK-implicit calls fired during BeamContext initialization

Customers reading the dashboard often see traffic against services they never call from their own code (notably mail, commerce, notification). These calls fire automatically on BeamContext startup or on the first access to common UI components, not because the game requested them. Document:

• Which calls happen on init (with the SDK source as reference): notably GET /basic/notification/, GET /basic/commerce/skus, BeamableApi.Customer GetClientDefaults, accounts GET me, content GET manifest/public, social GET my, BeamableApi.Presence GetOnlineStatuses.
• The 1:1-with-login ratio so customers can sanity-check their own dashboard.
• For each implicit call, what (if anything) the customer can do today to suppress it:
  • commerce - drop IBeamablePurchaser registration or leave SKUs unconfigured
  • mail - mail/search is application-driven; locate MailSubscription / MailService.GetCurrent usage in the project
  • notification - cannot be opted out; it underpins the entire subscription system (inventory, events, content, stats, etc.). Document this explicitly to head off "can I just turn notification off" requests.

2. Reading the API-usage dashboard

• session POST heartbeat dominating the chart is normal: heartbeat runs roughly every 30s per active session.
• BeamableApi.PlayerPresence Heartbeat is often the single largest line. Document that it is non-billable — it is the only API-hit metric excluded from billing calculations. Customers panic about it without this disclosure.
• What ratios between heartbeat and login indicate (typical session length).

3. Cost math

Show how to estimate cost from the dashboard, given the current rate ($100 per 10M billable calls). Worked example: "X sessions/month -> Y init-time calls per session -> $Z/month from this subsystem."

4. Tighten the existing strategic advice

• "Subscribe only to specific subsets of notifications" - clarify that this means narrowing inventory/event/content scopes, not turning the notification system itself off.
• "Targeted store subscriptions" - link this to the concrete commerce opt-out above.

Acceptance

• New page exists in this repo, surfaced in both Unity and Core docs navigation (and any other product variants where relevant).
• Old docs.beamable.com page either redirects to the new page or is deprecated in place.
• Page is reviewed against the SDK source for the supported version range (currently Unity 5.0.x / 5.1.x and Core 7.x) so call-site references stay accurate.

Source material

• https://docs.beamable.com/docs/best-practices (legacy page to migrate)