Skip to main content
GOL separates who is calling the API from who has authorized money to move. That distinction shapes every integration.

​
Your project and API key

A project groups developer resources and credentials. Its test and live environments are separate. A scoped API key identifies your server and limits which API operations it may request. Store the key on your server, never in browser code or a public repository. An API key cannot create an owner’s mandate, widen its limits, sign for the owner, or move funds by itself. The current whoami endpoint lets you check the key’s project, environment, and scopes.

​
The owner’s account and mandate

GOL is designed to work with a user-provided compatible account. GOL does not create an account for the owner or hold the owner’s private key. A mandate is an owner-approved envelope of authority for a named agent. The intended bounded mode restricts actions through explicit rules; a separate full-control mode requires explicit owner approval and still reserves ownership and authority administration to the owner. For an agent action that affects value, the security-critical rules must be enforced on-chain as part of that action. A platform check can improve the experience, but it is not the final authority boundary. The owner must be able to pause or revoke future agent actions without the agent’s cooperation.

​
A future payment flow

Once GOL publishes an Active compatibility profile and the public API and SDK for execution, the flow will be:
  1. The owner uses a supported account configuration and approves a specific mandate.
  2. A developer’s server requests an action using its own credential.
  3. The mandate integration evaluates the agent’s authority on-chain.
  4. GOL reports the result and makes independent verification possible.
This is the product model, not an available payment tutorial. For the currently usable workflow, create a test project.