api/v1.0 has never been published. help.beamable.com/versions.json lists 20 Mike versions — WebSDK-*, Unreal-*, Unity-*, Toolkit-0.4, Internal, Home, CLI-* — and no API-* at all.
That branch is the only place on the new site documenting signed requests: the server-to-server auth scheme, the X-BEAM-SIGNATURE header, and the exact signature algorithm (Base64(MD5(secret ‖ pid ‖ version ‖ path ‖ body))) with a working BeamableSignedRequester C# reference implementation.
Why this blocks the ReadMe.io sunset
Searched every branch and both SDK repos:
X-BEAM-SIGNATURE appears in exactly one other file site-wide — websdk/v1.0's auto-generated HEADERS.md, as a bare constant name with no explanationBeamableSignedRequester, "one-way hash of five pieces", and the MD5-then-Base64 procedure appear nowhere else on disk — not on any docs branch, not in BeamableProduct, not in UnrealSDK- "Realm secret" appears widely, but only as CLI reference for
beam config secret and beam project generate-env — never explaining what you do with it
So today this content is published only on docs.beamable.com/reference/signed-requests. Turning off the legacy site without publishing a successor removes the only documentation of server-authoritative auth. Same for the 7 basic/notification API-reference routes.
Provenance worth knowing
git log -S 'X-BEAM-SIGNATURE' on api/v1.0 returns one commit: 81db6e4ad, 2025-10-23, message "api temp". That commit created the entire branch — authenticating.md at 172 lines, oapi.md, the 41,005-line OpenAPI spec — while deleting the old flat CLI reference tree. Its author has since left the company, so what "temp" was a placeholder for is not recoverable from anyone's memory.
Two options
- Publish
api/v1.0 as API-1.0. Needs the spec-url bug fixed first (linked), a sdk/version decision for the Deploy Docs Branch workflow inputs, and a card on the home product chooser — otherwise it is reachable only through the version dropdown, which readers read as "pick a version of what I'm looking at", not "pick a product"
- Relocate the Signed requests section to a core branch, where it publishes today as
CLI-7.x. Cheaper, no new lane, no deploy plumbing — but it puts API-level auth documentation under a CLI-versioned lane, which is arguably the wrong shelf
Option 2 is the fast unblock; option 1 is the right end state if API docs are a product lane we intend to keep. These are not mutually exclusive: do 2 now, 1 when the lane question is settled.
The prose on that branch was copyedited in August 2026 (#127), so it is in publishable shape.
api/v1.0has never been published.help.beamable.com/versions.jsonlists 20 Mike versions —WebSDK-*,Unreal-*,Unity-*,Toolkit-0.4,Internal,Home,CLI-*— and noAPI-*at all.That branch is the only place on the new site documenting signed requests: the server-to-server auth scheme, the
X-BEAM-SIGNATUREheader, and the exact signature algorithm (Base64(MD5(secret ‖ pid ‖ version ‖ path ‖ body))) with a workingBeamableSignedRequesterC# reference implementation.Why this blocks the ReadMe.io sunset
Searched every branch and both SDK repos:
X-BEAM-SIGNATUREappears in exactly one other file site-wide —websdk/v1.0's auto-generatedHEADERS.md, as a bare constant name with no explanationBeamableSignedRequester, "one-way hash of five pieces", and the MD5-then-Base64 procedure appear nowhere else on disk — not on any docs branch, not inBeamableProduct, not inUnrealSDKbeam config secretandbeam project generate-env— never explaining what you do with itSo today this content is published only on
docs.beamable.com/reference/signed-requests. Turning off the legacy site without publishing a successor removes the only documentation of server-authoritative auth. Same for the 7basic/notificationAPI-reference routes.Provenance worth knowing
git log -S 'X-BEAM-SIGNATURE'onapi/v1.0returns one commit:81db6e4ad, 2025-10-23, message "api temp". That commit created the entire branch —authenticating.mdat 172 lines,oapi.md, the 41,005-line OpenAPI spec — while deleting the old flat CLI reference tree. Its author has since left the company, so what "temp" was a placeholder for is not recoverable from anyone's memory.Two options
api/v1.0asAPI-1.0. Needs thespec-urlbug fixed first (linked), asdk/versiondecision for theDeploy Docs Branchworkflow inputs, and a card on thehomeproduct chooser — otherwise it is reachable only through the version dropdown, which readers read as "pick a version of what I'm looking at", not "pick a product"CLI-7.x. Cheaper, no new lane, no deploy plumbing — but it puts API-level auth documentation under a CLI-versioned lane, which is arguably the wrong shelfOption 2 is the fast unblock; option 1 is the right end state if API docs are a product lane we intend to keep. These are not mutually exclusive: do 2 now, 1 when the lane question is settled.
The prose on that branch was copyedited in August 2026 (#127), so it is in publishable shape.