New to Loop? Read How to integrate your app with Loop first. This page is for when you are already building and need the rules and the details.

If you are building against Loop rather than using the wallet, start with the official documentation and treat it as the source of truth for the exact version you are on.

If a method, parameter or endpoint is not in the documentation, please do not assume it exists. We would rather tell you it is unavailable than have you build on something undocumented that changes underneath you.

An ambiguous response does not mean the operation failed. It may have reached the ledger even though you never got a final answer.

Before retrying: check whether a transaction, update or command result already exists. Reuse the same command ID for the same operation within the deduplication window, and keep the operation identical.

Generating a fresh command ID for an uncertain submission is the classic way to execute something twice. A 4xx, by contrast, is a definite rejection: fix the request before retrying.

Build in backoff and retry behaviour, idempotency and command deduplication, explicit user authorisation, transaction-status verification, and logging that never captures secrets.

Respect the documented rate limits and the anti-abuse controls. We will not help anyone design around them, and doing so tends to end the integration rather than scale it.

Show the user the exact message they are signing and explain what it is for. Bind the signature to the intended domain, action or session, and use unique, expiring challenges so a signature cannot be replayed.

A signed message is not a transaction unless it actually submits one. Do not present it as one, and do not use vague wording to obtain an authorisation the user would not knowingly give.

Verify signatures against the corresponding public identity, following the format in the current SDK documentation, and do not claim a signature proves more than it does.

For a straightforward transfer between two parties, use the simplest supported Token Standard transfer flow.

Allocation-based flows exist for coordinated or atomic multi-step activity. They need more setup and more resources, so reach for them only when your use case genuinely requires it.

An allocation or executor permission is not unrestricted ownership of a user's assets. The rights are exactly what the contract and authorisation model grant, no more. Check the current Token Standard documentation and the relevant CIP before you settle on a design.

You can observe authorised ledger activity through the supported Ledger API update streams. What you see depends on the participant, party authorisation and your filters, so do not assume every network activity is visible to you.

Store offsets, handle reconnects and duplicate delivery safely, request only the access you need, and protect your participant credentials.

Being able to automate something does not mean it is allowed. Eligibility depends on product terms, trading and campaign rules, rate limits, anti-abuse protection and, in some cases, jurisdiction.

If you are planning automation, tell us what you are building, which features it uses, whether it trades, transfers, signs or acts for users, and how users authorise it. We will get you a real answer rather than guessing.

One thing we can say now: automated activity is never guaranteed to be eligible for rewards, and it is not exempt from anti-abuse controls.

A legitimate integration never asks a user for their private key, password, passkey or verification code. Users authorise actions through the official Loop interface.

Loop wallets do not use a seed phrase, so any flow that asks a Loop user for recovery words is a scam, whatever it calls itself.

If your design needs to collect or export user wallet credentials, stop and talk to us first. We will not provide implementation guidance for it.

SDK package and exact version. Environment or network. Browser and operating system. The method you are calling. Sanitised request and response. HTTP status code. The exact error. Command ID, transaction hash or update ID if one was generated. Roughly when. Minimal reproduction steps. Whether it is consistent or intermittent.

Please sanitise before you send. No API secrets, access tokens, session cookies, production credentials or user personal data. We do not want them and cannot accept them.

We can help with documented behaviour, error diagnosis and design questions. We cannot certify an integration as secure, compliant or production-ready, and we cannot give legal or regulatory advice on custody or asset classification. Those need the right professionals, not a support conversation.