Everything the server knows about the CALLER's own game state. Read-only; writes nothing. Takes no input at all, and that is the security model: with no `did` parameter there is no way to ask about anybody else, so cross-account access is impossible by construction rather than gated by a check that could later be loosened. A PROCEDURE rather than a query for one concrete reason: HappyView enforces authentication on procedures at the transport, so an unauthenticated call gets a 401 and this script never runs, and `caller_did` is therefore guaranteed to be set. A query would receive `caller_did` too — it is `string?` in the query globals — but a Lua script cannot set its own HTTP status (src/error.rs:143 maps every raise to 500), so a query could only answer an anonymous caller with a 200 carrying an error, or a 500. The 401 has to come from the transport. It exists because diagnosing a stuck pet took an admin log, four greps and a chain of inference off two public endpoints. The ledger, the grant and the index are the three things that disagree in practice, and none of them was observable. This reports what each says and lets the reader compare, rather than deciding who is right.
Output
application/jsonconfig
ref#config
Optional
The caps as this instance actually reads them, not as the record on disk says.
did
string
Optional
The caller, echoed back. Always the authenticated DID — there is no way to ask about another account.
error
string
Optional
Reserved. Every failure this script can have is per-store and reported through `unreadable` instead, because a diagnostic that answers nothing is less useful than one that answers what it could reach and names what it could not.
unreadablegrant
ref#grant
Optional
The starter grant row, absent when the player never had one.
message
string
Optional
No description available.
money
ref#money
Optional
No description available.
pets
array
Optional
Every row in the pet ledger for this player, retired ones included, each paired with whether the index has the matching record. A row with indexed=false is the state that made a pet invisible and unrecoverable on 2026-07-30.
rejections
array
Optional
Rejection rows by reason. A stale row here is what put a false accusation in front of a player once, so seeing them matters.
unreadable
array
Optional
Which stores could not be read on this call, by name: pet-ledger, pet-index, grants, wallet-record, highwater, rejections, game-config. NOT cosmetic — every absent value elsewhere in this answer is ambiguous until you have read this. An unreadable pet-index would otherwise make every pet look un-indexed, which is the exact wrong conclusion to hand somebody debugging a missing pet.
wallet
ref#wallet
Optional
No description available.
Try It
Requests are sent directly from your browser. Some servers may block requests due to CORS.
View raw schema
{
"type": "procedure",
"output": {
"schema": {
"type": "object",
"required": [],
"properties": {
"did": {
"type": "string",
"description": "The caller, echoed back. Always the authenticated DID — there is no way to ask about another account."
},
"pets": {
"type": "array",
"items": {
"ref": "#pet",
"type": "ref"
},
"description": "Every row in the pet ledger for this player, retired ones included, each paired with whether the index has the matching record. A row with indexed=false is the state that made a pet invisible and unrecoverable on 2026-07-30."
},
"error": {
"type": "string",
"description": "Reserved. Every failure this script can have is per-store and reported through `unreadable` instead, because a diagnostic that answers nothing is less useful than one that answers what it could reach and names what it could not.",
"knownValues": [
"unreadable"
]
},
"grant": {
"ref": "#grant",
"type": "ref",
"description": "The starter grant row, absent when the player never had one."
},
"money": {
"ref": "#money",
"type": "ref"
},
"config": {
"ref": "#config",
"type": "ref",
"description": "The caps as this instance actually reads them, not as the record on disk says."
},
"wallet": {
"ref": "#wallet",
"type": "ref"
},
"message": {
"type": "string"
},
"rejections": {
"type": "array",
"items": {
"ref": "#reasonCount",
"type": "ref"
},
"description": "Rejection rows by reason. A stale row here is what put a false accusation in front of a player once, so seeing them matters."
},
"unreadable": {
"type": "array",
"items": {
"type": "string"
},
"description": "Which stores could not be read on this call, by name: pet-ledger, pet-index, grants, wallet-record, highwater, rejections, game-config. NOT cosmetic — every absent value elsewhere in this answer is ambiguous until you have read this. An unreadable pet-index would otherwise make every pet look un-indexed, which is the exact wrong conclusion to hand somebody debugging a missing pet."
}
}
},
"encoding": "application/json"
},
"description": "Everything the server knows about the CALLER's own game state. Read-only; writes nothing.\n\nTakes no input at all, and that is the security model: with no `did` parameter there is no way to ask about anybody else, so cross-account access is impossible by construction rather than gated by a check that could later be loosened.\n\nA PROCEDURE rather than a query for one concrete reason: HappyView enforces authentication on procedures at the transport, so an unauthenticated call gets a 401 and this script never runs, and `caller_did` is therefore guaranteed to be set. A query would receive `caller_did` too — it is `string?` in the query globals — but a Lua script cannot set its own HTTP status (src/error.rs:143 maps every raise to 500), so a query could only answer an anonymous caller with a 200 carrying an error, or a 500. The 401 has to come from the transport.\n\nIt exists because diagnosing a stuck pet took an admin log, four greps and a chain of inference off two public endpoints. The ledger, the grant and the index are the three things that disagree in practice, and none of them was observable. This reports what each says and lets the reader compare, rather than deciding who is right."
}