Gaming Engine as a Service

Infraestrutura de jogos para desenvolvedores.

Construa experiências de jogo sem construir o runtime. Axiom é uma API sandbox de créditos virtuais, players e sessões, para o seu produto não precisar inventar essa camada.

Começar sandbox Ler a documentação

O cadastro cria uma organização. GET /api/v1/games lista o catálogo sandbox depois de uma API key válida. Players, a carteira de créditos virtuais, as sessões de Dice e os webhooks estão no ar.

POST /api/v1/sessions

No ar

curl conceitual

curl -X POST https://YOUR_HOST/api/v1/sessions \
  -H "Authorization: Bearer aur_sk_sandbox_YOUR_KEY" \
  -H "Idempotency-Key: 01demo-dice-session" \
  -H "Content-Type: application/json" \
  -d '{"playerId":"PLAYER_ID","game":"dice","gameVersion":"1.0.0","stake":10,"config":{"target":4}}'

Problema

O jogo é fácil. O runtime não é.

Um giro no front-end são poucas linhas. Isolamento de tenant, saldo virtual, estado de sessão, idempotência e um resultado auditável já são um produto à parte. A maioria dos times não deveria começar por aí.

Ledger

Créditos precisam de matemática inteira, histórico e saldo que não fique negativo. Uma coluna chamada balance não é isso.

Sessões

Uma jogada é uma máquina de estados com um resultado que você consulta depois, não uma chamada aleatória descartável.

Integração

Seu backend precisa de um contrato HTTP estável, API keys e erros que ele consiga tratar. Esse é o produto.

Solução

Chame o runtime. Envie a experiência.

Axiom expõe uma API REST versionada. Você autentica com uma chave sandbox, cria um player, inicia uma sessão de Dice e lê o estado dos créditos virtuais. A interface é sua. O contrato de infraestrutura é nosso.

API-first, documentada antes do runtime entrar no ar
Somente créditos virtuais: unidades fictícias, sem valor em dinheiro
API keys sandbox com escopo de organização
Um jogo primeiro: Dice, como um engine em formato de plugin

Como funciona

Uma superfície sandbox curta.

GET /api/v1/games, as rotas de player, a carteira virtual e as sessões de Dice estão no ar no sandbox.

1
GET /api/v1/organization
No ar
2
GET /api/v1/organization/entitlements
No ar
3
GET /api/v1/games
No ar
4
POST /api/v1/players
No ar
5
GET /api/v1/players
No ar
6
GET /api/v1/players/{playerId}
No ar
7
GET /api/v1/wallet
No ar
8
POST /api/v1/wallets
No ar
9
GET /api/v1/wallets/{walletId}
No ar
10
POST /api/v1/wallets/{walletId}/credit
No ar
11
POST /api/v1/sessions
No ar
12
GET /api/v1/sessions/{sessionId}
No ar
13
POST /api/v1/webhooks
No ar
14
GET /api/v1/webhooks
No ar
15
POST /api/v1/webhooks/deliveries/{deliveryId}/retry
No ar
16
GET /api/v1/audit
No ar
17
GET /api/v1/audit/{eventId}
No ar

Experiência do desenvolvedor

Primeiros 5 minutos

O cadastro cria a organização. Você cria uma API key sandbox no dashboard. GET /api/v1/games lista Dice. Você pode criar players, abrir uma carteira de créditos virtuais e iniciar uma sessão de Dice.

01Criar conta
02Organização criada
03API key sandbox
04Ler a documentação
05Consultar o catálogo sandbox
06Criar um player
07Iniciar uma sessão de Dice
08Receber o resultado
09Inspecionar a carteira virtual

No ar agora: cadastro, organização, API keys, o catálogo de jogos, players, wallet, sessões de Dice e webhooks.

Exemplo de API

Catálogo, players, wallet, sessions e webhooks no ar.

GET /api/v1/games devolve Dice depois de uma chave sandbox válida. Rotas de player, wallet, session e webhook funcionam. O stake é em créditos virtuais.

GET /api/v1/games

No ar

GET /api/v1/games

curl https://YOUR_HOST/api/v1/games \
  -H "Authorization: Bearer aur_sk_sandbox_YOUR_KEY"

POST /api/v1/players

No ar

POST /api/v1/players

curl -X POST https://YOUR_HOST/api/v1/players \
  -H "Authorization: Bearer aur_sk_sandbox_YOUR_KEY" \
  -H "Idempotency-Key: 01demo-create-player" \
  -H "Content-Type: application/json" \
  -d '{"externalRef":"customer-123","displayName":"Sandbox Player"}'

GET /api/v1/wallet

No ar

GET /api/v1/wallet

curl "https://YOUR_HOST/api/v1/wallet?playerId=PLAYER_ID" \
  -H "Authorization: Bearer aur_sk_sandbox_YOUR_KEY"

POST /api/v1/sessions

No ar

POST /api/v1/sessions

curl -X POST https://YOUR_HOST/api/v1/sessions \
  -H "Authorization: Bearer aur_sk_sandbox_YOUR_KEY" \
  -H "Idempotency-Key: 01demo-dice-session" \
  -H "Content-Type: application/json" \
  -d '{"playerId":"PLAYER_ID","game":"dice","gameVersion":"1.0.0","stake":10,"config":{"target":4}}'

POST /api/v1/webhooks

No ar

POST /api/v1/webhooks

curl -X POST https://YOUR_HOST/api/v1/webhooks \
  -H "Authorization: Bearer aur_sk_sandbox_YOUR_KEY" \
  -H "Idempotency-Key: 01demo-create-webhook" \
  -H "Content-Type: application/json" \
  -d '{"url":"https://hooks.example.com/aurora","events":["session.completed","session.cancelled"]}'

No ar hoje: GET /openapi.json e GET /api/health.

Sandbox

Sandbox não é dinheiro.

Todo saldo, aposta e pagamento na Axiom é um crédito virtual. Créditos são uma unidade de implementação para testar o runtime. Não podem ser depositados, sacados nem trocados por moeda.

O primeiro ambiente é somente sandbox. Não existe ambiente live/dinheiro real neste produto. Se você precisa de pagamentos, a Axiom é a infraestrutura errada.

O que a Axiom é

Infraestrutura para experiências de jogo.

Uma API B2B para experiências de jogo
Um runtime sandbox com créditos virtuais
Um contrato para players, wallet, sessões e Dice
Infraestrutura que o seu produto chama. A UI continua sua

O que a Axiom não é

Leia isto antes de nos avaliar.

Axiom não é operadora e não movimenta dinheiro. Se um recurso está faltando, ele está faltando. Não está escondido atrás de um demo.

Sem transações com dinheiro real
Sem depósitos
Sem saques
Sem PIX
Sem processamento de cartão
Somente sandbox
Somente créditos virtuais

Comece pelo contrato. Integre quando o runtime existir.

Crie uma conta sandbox, emita uma API key, consulte o catálogo, crie um player, abra uma carteira virtual e inicie uma sessão de Dice. Os créditos são virtuais.

Começar sandbox Ler a documentação