Your first HTTP request

This guide runs from your terminal or server. For code running inside Margonem, use the game client API.

Setup

1. Create an API key

Open API Keys in your target environment and sign in with Discord. Create a key with at least one Organization and read-only access. Access to your own data is not needed for this request.

Copy the secret from the confirmation before dismissing it. It is shown only once. Store it as LOOTLOG_API_KEY in your server's environment or secret store. See keys and permissions for scope and rotation rules.

2. Choose an environment

Use the same environment for your key and requests. This guide uses development.

3. Send your first request

With LOOTLOG_API_KEY set, copy and run this command:

export LOOTLOG_API_URL=https://dev-api.lootlog.pl
curl --fail-with-body "$LOOTLOG_API_URL/users/@me/guilds" \
  -H "X-Api-Key: $LOOTLOG_API_KEY"

A successful request returns JSON with your Organizations and their Lootlog access status, limited by the key's scope and your current access. API paths and response fields use guild for the Discord server that anchors an Organization.

If the request is rejected, check the environment, key expiration, and selected Organizations. See errors and limits for the response status.

Operation reference

Open the API Reference, select the main API, and find GET /users/@me/guilds. Enter your key in the X-Api-Key authentication field to try the request and inspect its response. Switch services to explore Activity, Battlelog, and Search.

Scalar displays operations, parameters, and response schemas from the generated OpenAPI specifications. The portal does not persist the key or transfer it from API Keys; requests go directly to the selected Lootlog environment.

Send the key only in the X-Api-Key header. Do not add it to the URL. An invalid key causes access to be denied even if the browser also has an active session.

For typed requests in a server application, continue with the TypeScript SDK. To receive changes over WebSocket, see Realtime.

Writes

A write operation requires a read/write key and the user's current permissions for that operation in the Organization. A key does not grant access to account management, other keys, or internal operations.

Do not automatically retry writes after losing a response. The request may have succeeded; check the operation's result first. See the reference for each operation's idempotency rules.

User settings and Organizations

Access to your own data lets you read and change supported personal settings, but does not expand the key's Organization scope.

• In GET /users/@me/preferences, guildsOrder and hiddenGuildIds contain only Organizations selected for the key that you can still access. Attempting to change these two fields with a key returns 403; editing them requires a user session.
• In GET /users/@me/game-preferences/accounts/{id}, detector rules referring to other Organizations are hidden, and guildIds in notification settings are limited to permitted Organizations. Changing detector.routingRules or notification guildIds with a key returns 403 and requires a session.
• Supported personal settings, such as theme, appearance, and toggles, can still be changed with a read/write key that has access to your own data.

Organization feeds and ready rooms do not require access to your own data merely because their URL starts with /users/@me. Organization scope applies. A shared resource spanning several Organizations is accessible with a key only when all required Organizations are within its current scope.

Generic settings documents under /preferences and operations in the /timer-settings family (read, write, and migration) require a user session. They are not part of the API available to keys. This restriction applies to timer settings, not to reading or writing timers themselves. Typed account preferences and supported sound settings remain available according to the key's scope.