GROM Bot API

Appearance

Implementation status ​

This page exists because the rest of this site describes an API that does not answer yet.

Everything under Bot API is a specification being built to, not a description of a running service. It is published early so the shape can be reviewed and so migration can be planned — not so you can ship against it this week.

Last verified: 19 July 2026.

What runs ​

SurfaceStateNotes
GROM messenger (app + core)LiveAndroid and Linux builds, and the core API behind them
This documentation siteLiveYou are reading it
code.casinoplaneta.info association fileLivePublished and served as JSON
Deep links opening the appNot workingThe association file is published, but the Android app does not yet claim these links — see below
Bot API gatewayNot implementedEvery /bot<TOKEN>/ path returns 404
Bot creation (@gcore)Not implementedNo way to obtain a token yet
Mini AppsNot implementedSpecified only
Developer portal (my.casinoplaneta.info)Pages onlyNo sign-in; api_id cannot be issued yet
PaymentsNot implementedAnd the currency model itself is undecided — see Payments

Verify it yourself ​

Do not take our word for any of this. The gateway either answers or it does not:

bash
# The core that powers the app — this one is up
curl https://api.casinoplaneta.info/health
# {"ok":true,"postgres":true,"redis":true,"status":"ok","version":"..."}

# The Bot API gateway — this one is not
curl -i https://api.casinoplaneta.info/bot123456:FAKE/getMe
# HTTP/2 404

A 404 there means the gateway is not deployed at all. When it ships, that same call will return a JSON body with "ok": false and a 401 — a wrong token answer rather than a no such service answer. That change is the signal to watch for.

code.casinoplaneta.info/.well-known/assetlinks.json is published with the release signing fingerprint, which is the server half of Android App Links. The client half is missing: the app's manifest does not declare an autoVerify intent filter for this host, so Android has nothing to match and links open in the browser instead.

Both halves are needed. Until the app ships that intent filter, treat every code.* link as a web page that offers a download, not as something that opens the app. The link reference says the same thing on the page itself.

How statuses change here ​

Each method on the Methods page carries a badge:

  • planned — specified, returns 404 today
  • partial — answers, but some parameters or behaviours are missing
  • live — implemented and verified against the running gateway

Those badges come from the API schema, and the build refuses to mark anything live while the gateway is flagged as down. That is a deliberate guard: it makes "we shipped it" a two-step change that someone has to make on purpose, rather than a word that drifts onto a page.

What you can do today ​