Before you start
You need:- An account-creation API key and its secret supplied by the operator for this sandbox.
- A new username, an email address you control, and an account password.
- A separate password for the signing key you will create.
- A reachable HTTPS URL identifying your application, sent as
Refereron every request. A public project page can serve this purpose.
sandbox.neuro-tech.io, without the scheme or a path. This is a shared development environment; other Neurons have their own hosts and credentials.
The sandbox has public account enablement and automatic identity approval. An
approved sandbox identity does not mean its claims were verified.
Understand the sequence
The API secret authorizes account creation. The account password authorizes login and later signed requests. The signing-key password authorizes use of that key. Keep all three secrets in your backend.1. Create an account with your API key
Generate a fresh nonce from 32 random bytes, encoded as Base64. DefineHMAC(secret, message) as HMAC-SHA-256 over the UTF-8 message, using the UTF-8 secret as the key, with a standard Base64 result.
For this example without a phone number, calculate:
: in that exact order, without added spaces or line breaks. Sign these values, not the JSON body. If you supply a phone number, use the phone-inclusive signature.
Send the following request, replacing every placeholder:
created, enabled, jwt, and expires. A new account can be disabled; continue with sandbox enablement before relying on the returned session. Keep the username and password you chose. See Create account for the full response.
2. Enable the sandbox account
The sandbox provides this public helper so you can enable the account before logging in:already_enabled becomes true. An unknown account returns 404. This helper enables the account; it does not verify ownership of its email address or phone number.
3. Sign in and check the account
Generate a new nonce and calculate:jwt in memory. Send it as Authorization: Bearer <JWT> on the remaining /Agent/ requests. Confirm the account with:
4. Select an algorithm and create a signing key
CallPOST /Agent/Crypto/GetAlgorithms with {} and the same authenticated headers. Choose a signing algorithm from Algorithms that is marked safe, and retain its exact localName and namespace.
Choose a new key identifier, such as sandbox-identity-key, and a separate key password. The key identifier belongs to your account; it is unrelated to your account-creation API key.
Using a fresh nonce, calculate:
created and updated. Retain the id you submitted as your keyId, together with the algorithm’s localName and namespace. Use a fresh key ID for a new key; do not overwrite an existing key unintentionally.
5. Apply for a test Legal Identity
For this sandbox example, use fictional first and last names:FN is Alex and LN is Sandbox.
The sandbox review does not verify the truth of identity claims or photos. Retrieve application requirements with {} and the authenticated headers before choosing properties and evidence. Other providers can require additional fields and documents.
Keep the same key message from step 4, generate a fresh nonce, and append each property’s name and value in the same order as the Properties array:
https://your-app.example/ with your reachable application URL: identity application validates Referer. The response contains Identity; retain its id as your legalId. The identity’s status is nested under Identity.status, not a top-level account state.
6. Upload the required attachments
In the sandbox, the identity may be approved automatically as soon as it is created, before attachments orReadyForApproval. Check Identity.status.state using GetIdentity. If it is already Approved, skip steps 6 and 7 and continue with the approved identity. Attachments cannot be added after approval; contact the sandbox operator if you need to test an application with evidence uploads.
Before submitting for review, add the photos or documents required by the selected review method. Use test evidence for this sandbox exercise. If no attachments are required, continue to step 7.
Follow Prepare, sign, and upload an identity attachment for the complete AddIdAttachment request. It sends Base64 file bytes, the filename, and the content type in signed JSON. Use the legalId from step 5 and the same signing key. Upload each file while the identity is Created and wait for all uploads to succeed.
7. Submit the application for automatic review
Check the current identity state before sending this request. If the sandbox has already set it toApproved, ReadyForApproval is not needed. Continue to step 8.
If the identity is still Created, call ReadyForApproval after the required uploads, even when no attachments are needed. This starts the normal review process.
Use the same key message as step 4, and generate a fresh nonce:
Identity. Check its identifier and current state, then observe the review result.
8. Confirm automatic approval
Retrieve your identity to check whether the sandbox approved it automatically or to observe the result afterReadyForApproval:
Identity.status.state to become Approved. A response can initially show Created while approval is pending. Poll with a bounded interval, such as every two seconds for up to 30 seconds; that is a client timeout choice, not an approval-time guarantee.
If approval remains pending, check that ReadyForApproval succeeded and contact the sandbox operator with your legalId. Do not create another identity or use a direct approval helper to skip submission and review.
If ReadyForApproval reports that the identity is no longer Created, retrieve it again. Sandbox approval may have completed between your state check and the request; an Approved identity needs no further readiness call.
Keep the result and continue building
Continue with contract authoring or a token with a state machine and Script. Those workflows can require additional parties and provider signatures.
The request signing and sequence are checked with local tests. The sandbox host and public helper reference have been checked; this complete account-to-identity run still requires testing with operator-issued credentials.