# Content Source: https://docs.neuro-tech.io/api-reference/storage/content /test-api/openapi.yaml post /Agent/Storage/Content Allows the client to upload, share, update and delete content on the server. ## Overview Allows the client to upload, share, update and delete content on the server. The resource accepts GET, PUT, POST and DELETE methods, as well as sub-paths to identify individual content. ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Agreements Source: https://docs.neuro-tech.io/build/agreements/overview Create and sign a smart contract between verified parties An agreement combines an approved template, parameters, identified parties, roles, human-readable text, and signatures. It builds on the account, key, and Legal Identity stages. ## Before you start The two-party Agent API flow requires all of the following: | Requirement | Why it is needed | Get it from | | -------------------------------------- | --------------------------------------------------------------------------------- | ---------------------------------------------------------------------------- | | Neuron host and authenticated accounts | Each participating user acts through the target Neuron. | Neuron operator and [Agent API quickstart](/neuron-api/quickstart) | | Current Legal Identity for each party | The contract binds identified parties to roles. | [Verified identity](/build/verified-identity/overview) | | Signing key for each party | Each party signs under its assigned role. | [Create a cryptographic key](/neuron-api/guides/creating-cryptographic-keys) | | Approved contract template | The instance receives its allowed parameters, roles, and terms from the template. | [Sandbox automatic review or operator approval](#contract-approval) | Use a template ID from the Neuron your application connects to. ## Contract approval In the [Neuro sandbox](https://sandbox.neuro-tech.io/), newly proposed contracts, including templates, enter an automatic review and approval process. Submit your template through the Agent API as usual; you do not need to request manual approval first. The review can approve or reject the proposal. Outside the sandbox, **the Neuron operator is responsible for contract approval**. Contact the operator to arrange review of a new template or obtain an existing approved template. Approval is asynchronous. Retrieve the proposal with [Get Contract](/neuron-api/api-reference/contracts/get-contract) and wait for `Approved` before using it as a template. If it remains `Proposed` or is `Rejected`, contact the operator with its identifier. Automatic approval does not sign the contract for its parties; their review and signatures are still required. ## Start from where you are | What you have now | What to do next | | ------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | No account or Legal Identity | Start with the [identity foundation](/build/verified-identity/overview). | | Accounts but no signing keys | [Create a key for each signing party](/neuron-api/guides/creating-cryptographic-keys). | | Current identities but no approved template | [Author and submit a template](/contracts/from-scratch), then follow the [approval process for your environment](#contract-approval). You can also ask the operator for an existing approved template. | | All prerequisites | Follow the [contract API lifecycle](/neuron-api/guides/contracts-flow). | | A contract ID from an existing workflow | Use the [contract operations](/neuron-api/api-reference/contracts/overview) to retrieve its current state. | ## Follow the agreement lifecycle ```text theme={null} Accounts, keys, and current Legal Identities ↓ Select or propose a contract template ↓ Wait for template approval ↓ Create the instance with parameters, parties, and roles ↓ Sign and send the proposal ↓ Collect the remaining signatures ↓ Retrieve and verify the final Signed state ``` Use the [contract API lifecycle](/neuron-api/guides/contracts-flow) for the ordered create, review, propose, sign, and retrieve steps. Use [Create a contract with the Agent API](/contracts/agent-api-quickstart) for template submission and instance creation. Use [LegalLab](/contracts/legallab-quickstart) to inspect and edit templates. Read [Templates and instances](/contracts/templates-and-instances) when designing the contract model. ## Confirm success The agreement is complete only when every party can retrieve the same contract, its status is `Signed`, and its signatures contain every required role. Persist the template ID, contract ID, party Legal Identities, roles, parameters, signatures, and latest status. Proposal delivery and signatures can be asynchronous, so do not treat the create response as completion. ## Continue to a contract-created asset To create a Neuro-Feature through a contract, follow [Author a token with a state machine and Script](/build/tokenized-assets/from-scratch). # Build an AI application with the Agent API Source: https://docs.neuro-tech.io/build/ai-agents/overview Let an AI application request Neuro actions through your backend For an AI application that consumes MCP tools, start with [MCP](/mcp/overview). This guide covers an AI application using the Agent API through its own backend. Your code controls which operations the model can request and validates their inputs before sending HTTP requests. ## Connect your backend Run the [Agent API quickstart](/neuron-api/quickstart), then [connect your application](/get-started/first-application). Keep credentials, JWTs, and signing-key passwords in your backend. Give the model only the data needed for its task. ## Define application actions Expose a narrow action for each supported task, such as retrieving selected account details or inspecting a known token. Validate identifiers and authorization in code. A model-generated request is not proof that a user authorized it. Show the exact contract and role for review before requesting a signature. Obtain explicit user approval for payments or destructive actions as required by your application. Persist object IDs and [verify completion](/neuron-api/events-and-asynchronous-state). ## Use the same guides and reference Follow [Build](/build/overview) for the underlying workflow and the [API reference](/neuron-api/api-reference/overview) for exact operations. Use [documentation tools](/developer-tools/agent-tools) to help a coding agent find these instructions. # Digital signatures Source: https://docs.neuro-tech.io/build/digital-signatures/overview Create keys, sign data, and request signatures from verified parties Neuro signatures bind data or agreements to cryptographic keys and, where required, Legal Identities. ## Start here * [Create a cryptographic key](/neuron-api/guides/creating-cryptographic-keys). * Read [Keys and signatures](/concepts/keys-and-signatures) before choosing where keys are managed. * Use [Agreements](/build/agreements/overview) for multi-party contract signing. * Check the [cryptography](/neuron-api/api-reference/cryptography/overview) and [contract](/neuron-api/api-reference/contracts/overview) operations. ## Choose the workflow | Outcome | Start with | | --------------------------------- | ----------------------------------------------------------------------------------- | | Create a signing key | [Creating cryptographic keys](/neuron-api/guides/creating-cryptographic-keys) | | Sign application data | [Sign Data](/neuron-api/api-reference/contracts/sign-data) | | Request another party's signature | [Petition Signature](/neuron-api/api-reference/legal-identities/petition-signature) | | Sign a smart contract | [Agreements](/build/agreements/overview) | ## Show users what they sign Show users the exact content they are authorizing before requesting a signature. Save the signature and the key or identity reference needed to verify it. Follow the selected operation's reference for its response fields. # Build with Neuro Source: https://docs.neuro-tech.io/build/overview Choose an application task and complete it through the Agent API Start with the [Agent API quickstart](/neuron-api/quickstart) to create an account and identity, or [sign in with an existing account](/neuron-api/first-request). Then choose the capabilities your application needs. Each guide identifies prerequisites and the result you should verify. ## Choose your application task | I want to | Prerequisites | Start here | | -------------------------------------- | ----------------------------------------------------- | ------------------------------------------------------------- | | Establish a reviewed identity | Account access and an identity review provider | [Verified identity](/build/verified-identity/overview) | | Sign in an existing user | An existing account and a login method | [Sign in with Neuro](/build/sign-in-with-neuro/overview) | | Sign or request signatures | Signing credentials and the required identity | [Digital signatures](/build/digital-signatures/overview) | | Create a signed agreement | Party identities and a template, or XML to author one | [Contract guides](/contracts/quickstart) | | Create or inspect a token | Its creation contract and required participants | [Tokens and digital assets](/build/tokenized-assets/overview) | | Inspect or move value | Wallet access and a supported payment provider | [Payments](/build/payments/overview) | | Send or receive messages | Account privileges and recipient identifiers | [Messaging](/neuron-api/guides/messaging) | | Add Neuro actions to an AI application | A backend that controls credentials and authorization | [AI application guide](/build/ai-agents/overview) | ## Understand the dependencies ```mermaid theme={null} flowchart LR API[Account + Agent API] --> Identity[Key + reviewed identity] Identity --> Contract[Template + signed contract] Contract --> Token[Token + optional state machine] API --> Wallet[Wallet and payment provider] API --> Messages[Messaging] ``` Not every application needs a contract or token. Follow only the prerequisites of the selected task. A successful request can precede review, approval, signatures, or another asynchronous result. ## Find authoring resources For custom contract or token behavior, use the [schema catalog](/resources/schemas), [LegalLab examples](/resources/contract-examples), and [Neuron Script reference](/script/overview). These resources describe what your application submits; the Agent API remains its connection to Neuro. Persist the identifiers named by each guide and [verify the resulting state](/neuron-api/events-and-asynchronous-state). # Integrate a provider purchase of eDaler Source: https://docs.neuro-tech.io/build/payments/buy-edaler Discover a provider, initiate a development purchase, and inspect transaction state through the Agent API Use this sequence to add eDaler to an account's wallet through a supported payment provider. It covers providers that permit direct purchase without a signed contract. The HTTP requests have been checked against the server source; a complete test payment has not been run. Use the test provider and payment method described in the prerequisites. ## Prerequisites * An [Agent API session](/neuron-api/quickstart) and wallet-operation privileges. * An [approved Legal Identity](/neuron-api/guides/getting-your-identity-approved) that includes a country. * A provider enabled for that identity's country and the wallet's currency. * Provider confirmation that the environment uses test value, with a permitted positive amount and test payment method. Send the following requests over HTTPS with your account’s exact host, JWT, and application URL as `Referer`. Replace every placeholder before sending a request. ## 1. Read the starting balance and providers ```http theme={null} POST /Agent/Wallet/GetBalance HTTP/1.1 Host: Referer: https://your-app.example/ Authorization: Bearer Accept: application/json Content-Type: application/json {} ``` ```http theme={null} POST /Agent/Wallet/GetServiceProvidersForBuyingEDaler HTTP/1.1 Host: Referer: https://your-app.example/ Authorization: Bearer Accept: application/json Content-Type: application/json {} ``` The balance response contains `amount`, `reserved`, `currency`, and `timestamp`. Record all four. Do not apply a cents-to-units conversion without the provider's documented value convention. The provider response contains a `Providers` array. Map the selected provider's fields as follows: | Returned field | Request field or action | | -------------------------- | ------------------------------------------------------------------------------------------- | | `id` | Copy to `serviceId`. | | `type` | Copy to `serviceProvider`; the display name is not this identifier. | | `name` | Display to the user. | | `templateId`, when present | Follow the provider's required contract process. This direct-purchase guide does not apply. | An empty provider list means no discovered provider is available to this account in its current context. Ask the operator which provider is available for the account's country and currency. ## 2. Retrieve provider options Send the selected `serviceId` and `serviceProvider`: ```http theme={null} POST /Agent/Wallet/GetPaymentOptionsForBuyingEDaler HTTP/1.1 Host: Referer: https://your-app.example/ Authorization: Bearer Accept: application/json Content-Type: application/json { "serviceId": "", "serviceProvider": "" } ``` This operation starts an options transaction. Record its `id` and use that GUID as `transactionId` to retrieve its current information: ```http theme={null} POST /Agent/Wallet/GetTransactionInformation HTTP/1.1 Host: Referer: https://your-app.example/ Authorization: Bearer Accept: application/json Content-Type: application/json { "transactionId": "" } ``` The information includes `id`, `state`, `started`, `serviceId`, `serviceProvider`, and `options`. Depending on the provider's stage, it can also include `clientUrl` and `ended`. Options can initially be `null`. Treat option fields as provider-defined data. If `clientUrl` requires user interaction, present the trusted provider page using your application's reviewed redirect policy. Complete the provider's required interaction before expecting a final result. ## 3. Review and initiate the purchase Prepare the same provider identifiers, the accepted `currency`, and the approved positive test `amount`. Replace the quoted amount placeholder below with a JSON number. Review the provider, amount, currency, fees, and payment method with the user. Then explicitly initiate: ```http theme={null} POST /Agent/Wallet/InitiateBuyEDaler HTTP/1.1 Host: Referer: https://your-app.example/ Authorization: Bearer Accept: application/json Content-Type: application/json { "serviceId": "", "serviceProvider": "", "amount": "", "currency": "" } ``` This calls [Initiate Buy eDaler](/neuron-api/api-reference/wallet/initiate-buy-edaler). The returned transaction ID is the purchase transaction, separate from the options transaction. Store it with the intended provider, amount, and currency immediately. The server can return before provider processing finishes. A successful HTTP response or browser redirect does not establish payment completion. ## 4. Observe the purchase Use the purchase transaction ID in the same retrieval operation: ```http theme={null} POST /Agent/Wallet/GetTransactionInformation HTTP/1.1 Host: Referer: https://your-app.example/ Authorization: Bearer Accept: application/json Content-Type: application/json { "transactionId": "" } ``` Use the same account that initiated the transaction. The API rejects a lookup belonging to another account. | Transaction state | Application response | | ------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- | | `Created`, `Preparing`, `Prepared`, `Executing`, `Executed`, `Committing` | Keep the purchase pending; follow any required provider interaction and poll within a bounded completion window. | | `Committed` | Record the transaction result and reconcile the wallet and provider result. | | `RollingBack` | Keep observing; do not initiate a replacement while rollback is unresolved. | | `RolledBack` | Record the unsuccessful attempt and the provider's outcome before allowing another attempt. | | `Error` | Preserve the transaction ID and resolve the provider failure. Do not report success. | Confirm when your provider considers the payment settled. A balance change alone cannot identify a specific purchase when other transactions occur at the same time. ## 5. Reconcile and retain evidence ```http theme={null} POST /Agent/Wallet/GetBalance HTTP/1.1 Host: Referer: https://your-app.example/ Authorization: Bearer Accept: application/json Content-Type: application/json {} ``` Compare the new balance and timestamp with the starting snapshot, the purchase's reported amount/currency, and the provider result. Keep the transaction ID, observed states, timestamps, provider identifiers, and your application order ID together. The selected server implementation keeps these transaction objects in a temporary registry configured for one hour. Treat transaction lookup as an operational status endpoint, not a durable accounting archive. A later `404` is not proof that no payment occurred. ## Recover from failures | Problem | Next step | | -------------------------------------- | -------------------------------------------------------------------------------------------------------- | | Missing approved identity or country | Complete the identity prerequisite and re-run provider discovery. | | Provider returns a `templateId` | Obtain that provider's contract process; do not bypass it with direct initiation. | | Invalid amount or unsupported currency | Correct the input using provider constraints, with user review before initiation. | | Initiation times out | Reconcile using a known transaction reference or provider support before resubmitting. | | Transaction lookup returns `404` | Check the exact GUID and environment, then reconcile outside the expired/absent status registry. | | Provider interaction is canceled | Observe and record the resulting transaction/provider state; a closed browser alone is not confirmation. | The optional `transactionId` request field is not a documented idempotency guarantee. Do not automatically retry a purchase initiation when its outcome is unknown. Keep your application's duplicate-submission controls separate from payment status. # Payments Source: https://docs.neuro-tech.io/build/payments/overview Read wallet balances, buy eDaler, and track payment results Use the Agent API to read wallet balances, process eDaler payment URIs, find payment providers, initiate purchases or sales, and track transactions. ## What you can use * [Integrate a provider purchase of eDaler](/build/payments/buy-edaler) for discovery, options, initiation, status, and reconciliation. * Read [Wallets and payments](/concepts/wallets-and-payments) for the transaction model and application responsibilities. * Check the [wallet API reference](/neuron-api/api-reference/wallet/overview) for the operations documented by the Agent API. ## Before moving value For development, use a provider and payment method confirmed to use test funds. Check the currency, amount, fees, and required user interaction before initiating a payment. Keep wallet credentials and bearer tokens in your backend. Do not treat a successful initiation response as a completed payment. Store the transaction identifier and use the state mechanism confirmed by the operator until the transaction succeeds, fails, or expires. # Sign in with Neuro Source: https://docs.neuro-tech.io/build/sign-in-with-neuro/overview Sign an existing Neuro user into your application Use this guide when the user already has a Neuro account or Legal Identity. Do not create a duplicate identity merely to establish an application session. ## Start here * Use [Sign in with an existing account](/neuron-api/first-request) for the complete HTTP login sequence. * Compare the documented options in [Login flows](/neuron-api/guides/login-flows). * Use [Browser-based signup](/neuron-api/guides/browser-based-signup) when a user needs an interactive Neuron form. * Check request fields in the [authentication and sessions reference](/neuron-api/api-reference/authentication-and-sessions/overview). ## Workflow choices | Need | Relevant flow | | ------------------------------------------------------ | ------------------------------------------------------------------------------------------ | | Sign in to the current Neuron with account credentials | [Login flows](/neuron-api/guides/login-flows) | | Use an interactive browser onboarding session | [Browser-based signup](/neuron-api/guides/browser-based-signup) | | Initiate Quick Login | [Quick Login reference](/neuron-api/api-reference/authentication-and-sessions/quick-login) | | Prepare or complete login across Neurons | Prepare Remote Quick Login and Remote Quick Login in the API reference | ## Application responsibilities * Bind the Neuro session to the correct application user. * Let the user select the Legal Identity used for the application workflow. * Keep JWTs and session cookies out of URLs and logs. * Handle rejection, expiry, cancellation, and remote-Neuron failure. * End both the application session and Neuro session as required by the product's logout policy. Test cancellation, expiry, logout, and remote-Neuron failure on the deployment before enabling the flow for users. # Author a token with a state machine and Script Source: https://docs.neuro-tech.io/build/tokenized-assets/from-scratch Define a complete token creation contract, submit it through the Agent API, and check its first owner-note transition Build a token definition whose first owner text note increments a stored counter and ends the machine. The contract, machine, and embedded expression are supplied as complete files. The XML and core calculation have been tested locally with `Waher.Script` 2.15.0. Token creation and the first transition still need to be tested on your development Neuron. ## Prerequisites * Complete [contract authoring and submission](/contracts/from-scratch). * Obtain an approved Creator Legal Identity, its signing key, and access to token and state-machine Agent API operations. * Confirm the provider supports this token creation vocabulary and the [selected schema set](/resources/schemas). * Arrange the TrustProvider role, template approval, any creation charge, and the provider's signing procedure. You cannot sign the provider's role with your Creator key. * Confirm an accepted value, currency, commission percentage, and expiration date. Zero value in the sample request is a placeholder choice, not a guarantee of free creation. ## 1. Start with the complete definition Save the complete definition below as `note-token.xml`, or [download the XML file](/downloads/examples/note-token.xml). ```xml theme={null} 0 Documentation example Records the first owner text note as a single completed step. iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAADUlEQVR4nGNQbnr4HwAE2AKGjcL8KQAAAABJRU5ErkJggg== Creates and initially owns the token. Approves and hosts token creation under its service rules. Initial value accepted by the provider. Currency or value unit accepted by the provider. The provider's required creation commission percentage. Token expiration within the creation contract's valid period. The display name of the demonstration token. The Creator requests one token named and will be its initial owner. The TrustProvider must approve its creation. The initial value is . The creation commission is percent. The token expires at . The machine starts in Waiting with Count equal to zero. The first owner text note runs a calculation and persists Count as one, then enters Complete and ends. If the action fails, it enters Failed and ends. Later notes do not repeat this machine step. No external-note event or payment action is defined by the machine. The creation contract lasts one month, followed by one month of required archival and one month of optional archival. Provider rules and approval apply; this demonstration has not been verified on your service. ``` Three namespaces separate the contract, token creation instruction, and machine definition. Keep them exactly as supplied. | Contract section | Meaning | | --------------------------------------------------- | ---------------------------------------------------------------------------------------- | | `Create/TokenID/Random` | Request a generated token identifier. Do not confuse it with the creation contract ID. | | `Creator` and `Owner` | Both refer to the `Creator` role for this example. | | `TrustProvider` | Refers to the provider's Legal Identity assigned to that role. | | `Value`, `Currency`, `CommissionPercent`, `Expires` | Read the matching contract parameters. | | `Definition/StateMachine` | Define the token's custom automated behavior. | | `FriendlyName`, `Category`, `Description`, `Glyph` | Supply display metadata. The included glyph is a minimal one-pixel PNG. | | Roles and human-readable text | Explain the parties, value, commission, expiration, and machine behavior before signing. | ## 2. Understand the transition ```mermaid theme={null} stateDiagram-v2 [*] --> Waiting Waiting --> Complete: Owner text note; action succeeds Waiting --> Failed: Owner text note; action fails Complete --> [*]: End Failed --> [*]: End ``` The machine initializes `Count` to zero. In `Waiting`, `OnTextNote` invokes `RecordNote`. A successful action enters `Complete`; a failed action enters `Failed`. Both states invoke `End`. ```xml theme={null} ``` This is a fragment inside the machine namespace. `Script` contains raw Neuron Script. The `value` attribute uses braces to evaluate an expression. `NextCount` is a calculation variable; `PersistVariable` records `Count` for subsequent machine state. An ordinary assignment alone does not replace that persistence step. The expected successful result is `Count = 1`. Later notes should not repeat this ended machine's step. This is a design expectation to verify on your provider, not a general duplicate-event guarantee. Read [Script syntax and execution contexts](/script/runtime-functions) when changing the calculation. If you add a less-than comparison in an XML attribute, escape it as `<`. ## 3. Validate before proposing Validate the complete file against the [contract, token, and state-machine schemas](/resources/schemas), following [local validation](/resources/validate-xml). Check that each state and action reference names a definition in the same machine. Expected result: the schema set compiles, the XML validates, and all explicit machine references resolve. The core expression `Count:=0; NextCount:=Count+1; NextCount` returns `1`; see [Script expressions](/script/quickstart). Neither check approves the template or runs the machine in its host context. ## 4. Obtain creation attributes and template approval Send the following requests over HTTPS with your account’s exact host, JWT, and application URL as `Referer`. Replace every placeholder before sending a request. ```http theme={null} POST /Agent/Tokens/GetCreationAttributes HTTP/1.1 Host: Referer: https://your-app.example/ Authorization: Bearer Accept: application/json Content-Type: application/json {} ``` [Get Creation Attributes](/neuron-api/api-reference/tokens/get-creation-attributes) returns `currency`, `commission`, and `trustProvider`. A missing provider identity is a provisioning issue to resolve before creation. Confirm how these values apply to the accepted template and charges. Base64-encode the complete `note-token.xml` file’s UTF-8 bytes and propose it: ```http theme={null} POST /Agent/Legal/ProposeTemplate HTTP/1.1 Host: Referer: https://your-app.example/ Authorization: Bearer Accept: application/json Content-Type: application/json { "templateBase64": "" } ``` Record the returned `Template` identifier and follow the [sandbox automatic review or operator approval process](/build/agreements/overview#contract-approval). Use `Legal/GetContract` with that identifier as `contractId` to observe the template lifecycle. Continue only with an approved, usable template. Template approval does not supply the `TrustProvider` signature required by this creation contract. ## 5. Create and sign the creation contract Prepare the creation request: * Set the approved template ID. * Assign `Creator` to your approved Legal Identity and `TrustProvider` to the provider's approved identity. * Set `Value` and `CommissionPercent` as JSON numbers. Replace the quoted commission placeholder with an actual number. * Set `Currency` to the accepted string and `Expires` to an ISO 8601 date-time accepted by the provider within the creation contract's valid period. * Choose `FriendlyName`, from 1 to 80 characters. ```http theme={null} POST /Agent/Legal/CreateContract HTTP/1.1 Host: Referer: https://your-app.example/ Authorization: Bearer Accept: application/json Content-Type: application/json { "templateId": "", "visibility": "CreatorAndParts", "Parts": [ { "role": "Creator", "legalId": "" }, { "role": "TrustProvider", "legalId": "" } ], "Parameters": [ { "name": "Value", "value": 0 }, { "name": "Currency", "value": "" }, { "name": "CommissionPercent", "value": "" }, { "name": "Expires", "value": "" }, { "name": "FriendlyName", "value": "My first note token" } ] } ``` Record the returned `Contract` ID. Retrieve the instance: ```http theme={null} POST /Agent/Legal/GetContract HTTP/1.1 Host: Referer: https://your-app.example/ Authorization: Bearer Accept: application/json Content-Type: application/json { "contractId": "" } ``` Have the Creator review the complete terms, parameters, and assigned role. After confirmation, calculate the [contract signatures](/neuron-api/guides/contracts-flow#construct-a-contract-signature) using the Creator’s key metadata, key password, account password, and a fresh nonce. Submit: ```http theme={null} POST /Agent/Legal/SignContract HTTP/1.1 Host: Referer: https://your-app.example/ Authorization: Bearer Accept: application/json Content-Type: application/json { "keyId": "", "legalId": "", "contractId": "", "role": "Creator", "nonce": "", "keySignature": "", "requestSignature": "" } ``` Retrieve the instance again with `Legal/GetContract` and the same contract ID. Coordinate the provider's required signature separately. Observe all required signatures and the creation contract's final state. Do not assume your first signature creates the token. ## 6. Find the created token Retrieve tokens associated with the creation contract: ```http theme={null} POST /Agent/Tokens/GetContractTokens HTTP/1.1 Host: Referer: https://your-app.example/ Authorization: Bearer Accept: application/json Content-Type: application/json { "contractId": "", "offset": 0, "maxCount": 20, "references": true } ``` Inspect the returned `Tokens` structure for the token associated with this creation contract. Preserve the exact identifier. An empty list can mean creation is pending or failed; inspect the contract and provider result before submitting another creation request. Use the returned token identifier to retrieve the token and machine state: ```http theme={null} POST /Agent/Tokens/GetToken HTTP/1.1 Host: Referer: https://your-app.example/ Authorization: Bearer Accept: application/json Content-Type: application/json { "tokenId": "" } ``` ```http theme={null} POST /Agent/StateMachines/GetCurrentState HTTP/1.1 Host: Referer: https://your-app.example/ Authorization: Bearer Accept: application/json Content-Type: application/json { "tokenId": "" } ``` Verify the token's owner, creation contract, metadata, and current machine state. The expected starting machine state is `Waiting` with `Count = 0`. The state response contains `CurrentState`; use its returned structure rather than assuming an invented flat `state` field. ## 7. Send an owner note and observe the result Send this request with the account that owns the token, using the same token ID. The request sets `personal` to `false`. ```http theme={null} POST /Agent/Tokens/AddTextNote HTTP/1.1 Host: Referer: https://your-app.example/ Authorization: Bearer Accept: application/json Content-Type: application/json { "tokenId": "", "note": "First owner note", "personal": false } ``` Repeat `StateMachines/GetCurrentState` above, and retrieve the event history: ```http theme={null} POST /Agent/Tokens/GetTokenEvents HTTP/1.1 Host: Referer: https://your-app.example/ Authorization: Bearer Accept: application/json Content-Type: application/json { "tokenId": "" } ``` The note response contains `Note`. A note being accepted is separate from confirming the intended machine outcome. Retrieve the state and event history until the provider's documented completion window, with bounded polling in your application. For this example, verify `Complete`, the persisted `Count = 1`, and the corresponding note/action history. Record actual results and the Neuron build before treating the workflow as tested. If you receive `Failed`, preserve the returned diagnostic/history information and resolve the action failure before adapting the template. ## Diagnose and adapt | Situation | What to do | | --------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | | Provider identity is absent | Resolve provider provisioning before assigning roles. | | No token after signatures | Inspect contract state and provider execution; do not repeat creation blindly. | | Note rejected | Check token ownership or approved external-source permissions. This example listens for an owner note, not an external note. | | State-machine not found | Verify token ID, creation result, definition, and enabled capability. | | Action fails | Inspect the reported Script error, variable types, and persistence result. Local core-expression success does not prove host permission. | | Write times out | Reconcile notes/events and current state before resending; the operation does not document an idempotency guarantee. | When adapting this example, keep role references, parameter names, state IDs, and action references aligned. Update human-readable terms whenever automated behavior changes, validate the new file, and obtain a newly reviewed template when required by your provider. Retain the creation contract ID, token ID, template revision, input values, and observed state/history. Ending this custom machine does not itself destroy the token or delete its contract. Follow the asset's supported expiration and retention rules; transfer and destruction require their own approved behavior. # Tokenized assets Source: https://docs.neuro-tech.io/build/tokenized-assets/overview Create a token definition or inspect an existing asset through the Agent API A Neuro-Feature represents an asset or right created through an approved contract. Its definition can include a state machine and Script expressions that respond to events. Define a creation contract, add a machine and Script, and use the supplied HTTP commands. Retrieve an asset, its creation contract, notes, and event history. ## Prepare the required objects ```mermaid theme={null} flowchart LR Account[Account and API session] --> Identity[Approved Legal Identity and key] Identity --> Template[Approved creation template] Template --> Contract[Signed creation contract] Contract --> Token[Token identifier] Token --> Machine[Custom state and event history] ``` Keep the template ID, creation contract ID, and token ID separate. The template defines the parties, parameters, signatures, and machine behavior. Token creation depends on the provider's approval and execution rules. | What you have | Next step | | ------------------------------------------- | --------------------------------------------------------------------------------------------------------------- | | No API session | [Make your first request](/neuron-api/quickstart). | | An account without an approved identity | [Complete the identity prerequisites](/build/verified-identity/overview). | | An approved identity and a new asset design | [Author the token contract](/build/tokenized-assets/from-scratch). | | An approved creation template | [Create and sign an instance](/contracts/agent-api-quickstart) with that template's exact roles and parameters. | | An existing token ID | [Inspect its data and history](/neuron-api/guides/tokens-flow). | ## Before creating a token Follow the [contract approval process](/build/agreements/overview#contract-approval), arrange the TrustProvider signature, and confirm the creation amount, commission, and token permissions. The [authoring guide](/build/tokenized-assets/from-scratch#prerequisites) lists the requirements for the example. A state machine ending does not transfer or destroy its token. To transfer, donate, or destroy an asset, use the actions defined by its contract and provider. Use the [schema catalog](/resources/schemas), [Script reference](/script/overview), and [LegalLab examples](/resources/contract-examples) when adapting the definition. # Verified identity Source: https://docs.neuro-tech.io/build/verified-identity/overview Create an account, cryptographic key, and reviewed Legal Identity For the Neuro sandbox, follow the [account and identity quickstart](/neuron-api/quickstart), which uses public account enablement and automatic test-identity approval. The guide below covers the general provider-managed process. Create an account, a signing key, and an approved Legal Identity so your user can sign agreements and own assets. ## Start from where you are | What you have now | What to do next | | ------------------------------------------ | ----------------------------------------------------------------------------------------------------------------- | | No Neuron host or provisioning method | Ask the operator for the host, onboarding method, required fields, review provider, and test-data policy. | | Existing account credentials | [Sign in with the existing account](/neuron-api/first-request), then continue with key creation. | | No account and a trusted backend | Follow [User onboarding](/neuron-api/guides/user-onboarding). | | No account and an interactive browser flow | Follow [Browser-based signup](/neuron-api/guides/browser-based-signup). | | A current Legal Identity and signing key | Continue to [Agreements](/build/agreements/overview) or [Digital signatures](/build/digital-signatures/overview). | ## Account and identity stages ```text theme={null} Neuron access ↓ Account and authenticated session ↓ Email and phone verification where required ↓ Cryptographic key ↓ Legal Identity application and attachments ↓ ReadyForApproval ↓ Review and approval ↓ Current Legal Identity ``` An account answers who controls the session. A Legal Identity identifies the person or organization whose information has been reviewed. Logging in does not create or approve a Legal Identity. ## Choose an onboarding method | Application | Method | Credential handling | | ------------------- | --------------------------------------------------------------- | ----------------------------------------------------------- | | Trusted backend | [User onboarding](/neuron-api/guides/user-onboarding) | The backend protects the account-creation secret. | | Browser | [Browser-based signup](/neuron-api/guides/browser-based-signup) | The browser uses the hosted flow; no API secret is exposed. | | Existing Neuro user | [Sign in with Neuro](/build/sign-in-with-neuro/overview) | Reuse the user's existing account and identity. | ## Complete the identity stages 1. [Create and verify an account](/neuron-api/guides/creating-an-account). 2. [Create a cryptographic key](/neuron-api/guides/creating-cryptographic-keys). 3. [Apply for a Legal Identity](/neuron-api/guides/applying-for-a-legal-identity). 4. [Upload each required attachment](/neuron-api/guides/applying-for-a-legal-identity#3-prepare-each-attachment). 5. [Call `ReadyForApproval`](/neuron-api/guides/applying-for-a-legal-identity#5-mark-the-application-ready-for-approval) to start review, unless the sandbox has already approved the identity. 6. [Observe review and approval](/neuron-api/guides/getting-your-identity-approved). Identity review is asynchronous. Persist the application state and do not continue to a dependent workflow until the identity is approved. ## Keep the resulting state | State | Why you need it | | --------------------------- | ------------------------------------------------------------------------- | | Account identifier | Associate the Neuro account with the correct application user. | | Verified contact status | Resume any deployment-required contact verification. | | `keyId` | Select the correct cryptographic key for later actions. | | Identity application state | Resume and display pending review. | | `legalId` | Identify the actor in signatures, contracts, and other trusted workflows. | | Approval or rejection state | Decide whether the next dependent step is allowed. | ## Continue building Use current Legal Identities and signing keys as contract parties. Sign data or request a signature from a trusted party. Return to [Build with Neuro](/build/overview) to choose your next task. # Accounts and Legal Identities Source: https://docs.neuro-tech.io/concepts/accounts-and-identities Distinguish authentication accounts from reviewed identities used in trusted workflows An **Account** establishes access to a Neuron. A **Legal Identity** represents an actor for workflows that require reviewed identity data, signatures, contract participation, or another stronger trust decision. They are related, but they are not interchangeable. | Object | Answers | Typical lifecycle | | -------------------------- | ----------------------------------------------------- | ----------------------------------------------------------------------------------------- | | Account | “Which Neuron principal is authenticated?” | Created, contact details verified where required, authenticated, recovered or transferred | | Legal Identity application | “Which identity is being submitted for review?” | Prepared, submitted with required attributes and attachments, reviewed | | Legal Identity | “Which reviewed actor participates in this workflow?” | Returned with its current status and used according to the relying workflow's policy | ## Why the distinction matters Logging in proves control of account credentials. It does not by itself prove that the account has a current Legal Identity or that a relying application should accept that identity for a particular purpose. An application must state its own requirement explicitly: ```text theme={null} Authenticated account only or Current Legal Identity required or Specific provider, review, role, or contract rule required ``` ## Onboarding paths | Situation | Start with | | ------------------------------------- | --------------------------------------------------------------- | | Trusted backend creates a new account | [User onboarding](/neuron-api/guides/user-onboarding) | | Browser user creates an account | [Browser-based signup](/neuron-api/guides/browser-based-signup) | | Existing Neuro user signs in | [Sign in with Neuro](/build/sign-in-with-neuro/overview) | | Account applies for a Legal Identity | [Verified identity](/build/verified-identity/overview) | ## State applications must retain Persist identifiers and status needed to resume the workflow. Do not use display names or email addresses as substitutes for returned account, application, key, or Legal Identity identifiers. Identity review is asynchronous. The application must handle at least a pending outcome and a terminal approved or rejected outcome using the delivery or query mechanism supported by its Neuron. ## Keep account and identity data separate Never put an account-creation API secret in browser or distributable mobile code. A browser onboarding flow can differ from normal Agent API JSON requests and may use hosted forms, redirects, and a session-token exchange; follow the dedicated guide instead of adapting backend examples. ## Reference * [Accounts and onboarding](/neuron-api/api-reference/accounts-and-onboarding/overview) * [Authentication and sessions](/neuron-api/api-reference/authentication-and-sessions/overview) * [Legal Identities](/neuron-api/api-reference/legal-identities/overview) # Neuro architecture Source: https://docs.neuro-tech.io/concepts/architecture Understand the roles of your application, the Agent API, Neurons, and trust services Your application connects to the **Agent API**, an HTTPS interface exposed by the Neuron that hosts its account. The Neuron coordinates the enabled identity, contract, token, payment, and messaging services. ```mermaid theme={null} flowchart LR UI[Browser or mobile UI] --> Backend[Your backend] Backend --> API[Agent API] Service[Backend service] --> API API --> Neuron[Neuron] Neuron --> Objects[Accounts, identities, contracts, tokens, wallets] Objects --> Ledger[Neuro-Ledger history] Neuron <--> Peers[Other trusted services] ``` ## Application responsibilities Your application manages credentials, requests, user review, returned identifiers, and business logic. The Neuron executes the operations exposed through the API. Its provider controls enabled capabilities and trust relationships. For browser applications, keep privileged credentials in your backend. The [application architecture guide](/get-started/choose-integration) and [application guide](/get-started/first-application) show this arrangement. ## Objects and their dependencies A contract signature relates a Legal Identity to a role in an agreement. A token refers to its creation contract and may have a state machine. A payment has its own transaction outcome. These are related objects with distinct lifecycles. Read the [object model](/concepts/object-model) to decide which identifiers and states to persist. Do not infer completed business activity from HTTP success alone. ## Trust across domains Different participants can belong to different Neurons. Cross-domain interactions depend on the configured trust services and permissions. The [trust and federation concepts](/concepts/trust-and-federation) explain what this means for applications. Continue with [your first API request](/neuron-api/quickstart) or [choose a build task](/build/overview). # Keys and signatures Source: https://docs.neuro-tech.io/concepts/keys-and-signatures Understand Agent API key custody and the identifiers needed for signatures Keys connect authenticated actors to signed identities, agreements, and data. Applications should treat key creation, key identifiers, signing authority, and signature verification as separate concerns. ## How Agent API signing uses keys The Agent API performs supported cryptographic operations with key material stored encrypted by the Neuron. Your application retains the key identifier, algorithm metadata, and the credentials required to authorize its use. Keep key passwords distinct from account passwords. A request must bind the acting account, selected key, intended payload, and signing purpose. The Agent API is the same HTTPS interface for ordinary and AI-enabled applications. ## Key workflow ```text theme={null} Choose a supported algorithm ↓ Create a key in the correct account context ↓ Persist the caller-supplied key identifier ↓ Associate it with the identity or signing workflow ↓ Verify the resulting signature or signed object ``` Do not hard-code an algorithm across a long-lived application unless the supported workflow requires it. Query or follow the algorithm guidance for the Neuron version you target. ## Application rules * Keep passwords, JWTs, key passwords, private keys, and signing secrets out of source control and logs. * Persist the `id` submitted to `CreateKey`; later operations call the same value `keyId`. * Make the actor, key, payload, and intended signing purpose explicit. * Do not claim legal effect or non-repudiation solely because bytes have a valid cryptographic signature; the identity, authorization, contract, policy, and verification context also matter. * Treat retries carefully. A signing operation may have effects that should not be duplicated unless idempotency is explicitly documented. ## Build with signatures * [Create cryptographic keys](/neuron-api/guides/creating-cryptographic-keys) * [Digital signatures](/build/digital-signatures/overview) * [Cryptography reference](/neuron-api/api-reference/cryptography/overview) # Neuro-Features and state machines Source: https://docs.neuro-tech.io/concepts/neuro-features-and-state-machines Learn how contracts create digital features with lifecycle state, ownership, and history A **Neuro-Feature** is a contract-related digital feature that an application can retrieve together with its attributes and event history. A related **state machine** can make allowed lifecycle states and transitions explicit. ## Relationship model ```text theme={null} Approved creation template ↓ Creation contract ↓ Neuro-Feature identifier ├── attributes and description ├── current owner or holder data exposed by the API ├── current state └── notes and event history ``` The exact creation and transfer sequence must come from a verified template and supported Neuron build. The existence of read operations does not prove that a guessed combination of contract and token operations will mint or transfer a feature. ## State-machine reasoning For each stateful workflow, document: | Question | Application requirement | | ------------------------------ | --------------------------------------------------------------------- | | What is the current state? | Read it from the documented operation or event | | Which transitions are allowed? | Follow the approved contract/state-machine definition | | Who can trigger a transition? | Check identity, party, role, and privilege requirements | | Is the transition synchronous? | Handle accepted, pending, final, and failed outcomes as documented | | What evidence remains? | Retain the feature/contract identifier and retrieve its event history | ## Available documentation The [token guide](/neuron-api/guides/tokens-flow) covers inspection. No generic tutorial currently covers creation, state transitions, or ownership transfer; obtain those procedures from the target Neuron's operator. ## Reference * [Tokens](/neuron-api/api-reference/tokens/overview) * [State machines](/neuron-api/api-reference/state-machines/overview) # Neuro object model Source: https://docs.neuro-tech.io/concepts/object-model See how accounts, identities, contracts, assets, states, wallets, and transactions relate Neuro applications work with several long-lived objects. Use this map to decide which identifiers and state your application must store. This diagram explains application concepts; it is not an API schema. Use the generated operation pages for exact request and response fields. ## Relationship map ```text theme={null} Neuron └── hosts Account access and application-facing services Account ├── uses Keys ├── can apply for Legal Identities └── accesses Wallet capabilities Legal Identity ├── identifies a Contract Party └── participates under a Contract Role Smart Contract ├── defines Parties and Roles ├── contains Parameters and human-readable text └── may define a State Machine and Neuro-Feature creation Neuro-Feature ├── is associated with its creation contract ├── may have State Machine state └── has an event and provenance history Wallet └── exposes balances and Transactions ``` ## Objects your application may store | Object | Created by | Identifier to persist | Mutable state | Related workflow | | -------------- | --------------------------------------- | ---------------------------------------------------- | --------------------------------------------- | ----------------------- | | Neuron | Operator | Host/domain | Configuration and installed capabilities | Environment setup | | Account | Onboarding flow or operator | Account identifier or username as defined by the API | Verification, session, privileges | Verified identity | | Key | Account through cryptographic operation | `keyId` when returned | Key lifecycle requires verification | Signatures and identity | | Legal Identity | Account application plus review | `legalId` | Application and approval state | Verified identity | | Smart Contract | Creator from an approved template | Contract ID | Proposal, signing, and lifecycle state | Agreement | | Party and Role | Contract template and instance | Contract-defined identity/role references | Participation and signature state | Agreement | | Neuro-Feature | Approved creation-contract workflow | Token/feature ID | Ownership, notes, events, state-machine state | Product passport | | State Machine | Contract/template definition | Contract or feature association | Current state, variables, reports | Asset lifecycle | | Wallet | Neuron account capability | Confirm with wallet API | Balance and pending transactions | Payments | | Transaction | Wallet/payment workflow | Transaction ID | Provider-specific transaction state | Payments | ## Store returned identifiers and state When an operation creates or retrieves a long-lived object, store the identifier returned by that operation. For asynchronous work, also store the latest returned status and the mechanism used to check for changes. # How Neuro works Source: https://docs.neuro-tech.io/concepts/overview Learn how Neurons, accounts, identities, contracts, assets, and trust services fit together Applications connect to a Neuron to use accounts, identities, contracts, digital assets, payments, messaging, and storage. Start with the object model, then open only the concepts your application uses. ## Start with the object model Read the [Neuro object model](/concepts/object-model) to understand which objects an application creates, owns, references, and persists. ## What you can build with Neuro | Capability | What it contributes | Build with it | | -------------------------------------------------------------------------------- | ----------------------------------------------------------- | -------------------------------------------------------- | | [Accounts and Legal Identities](/concepts/accounts-and-identities) | Actors and reviewed identity | [Verified identity](/build/verified-identity/overview) | | [Keys and signatures](/concepts/keys-and-signatures) | Cryptographic authorization and evidence | [Digital signatures](/build/digital-signatures/overview) | | [Smart contracts](/concepts/smart-contracts) | Human- and machine-readable agreements | [Agreements](/build/agreements/overview) | | [Neuro-Features and state machines](/concepts/neuro-features-and-state-machines) | Assets and auditable lifecycle | [Tokenized assets](/build/tokenized-assets/overview) | | Neuro-Ledger | Distributed audit and history | [Neuro-Ledger](/neuro-ledger/overview) | | [Wallets and payments](/concepts/wallets-and-payments) | Value and transaction workflows | [Payments](/build/payments/overview) | | Neuron | Federated runtime that exposes Neuro integration interfaces | [What is the Neuron?](/overview/what-is-the-neuron) | ## Where to go next Use [Build](/build/overview) for application guides and [API reference](/neuron-api/api-reference/overview) for HTTP request details. Start with [Neuro architecture](/concepts/architecture), then use [Trust and federation](/concepts/trust-and-federation) for cross-domain decisions. # Smart contracts Source: https://docs.neuro-tech.io/concepts/smart-contracts Learn how templates, parties, roles, parameters, and signatures form a contract A Neuro smart contract is a structured agreement. Its machine-readable parts, human-readable text, participating parties, roles, parameters, signatures, and lifecycle rules must describe the same intended agreement. ## Template and instance ```text theme={null} Template ├── allowed parameters ├── roles and parts ├── human-readable rendering └── optional lifecycle or state-machine rules ↓ instantiate Contract instance ├── concrete parameter values ├── identified parties in roles ├── proposal and signature state └── current lifecycle state ``` Template approval and contract signing are different states. An approved template can be instantiated, but an instance is not a completed agreement until its own participation and signature requirements have been satisfied. ## Application responsibilities * Use a template whose approval and compatibility are confirmed for the target Neuron. * Bind Legal Identities to the intended parties and roles. * Validate parameters before presenting human-readable text for signature. * Persist the contract identifier and current proposal/signature state. * Display the same material terms the application submits. * Treat proposal, signature, and finalization as lifecycle states, not one synchronous request. * Retrieve and verify the final contract rather than assuming the last command completed the workflow. ## Learn, build, reference * **Overview:** [Agreements](/build/agreements/overview) * **Quickstart:** [Contracts quickstart](/contracts/quickstart) * **Guides:** [Agent API contract guide](/contracts/agent-api-quickstart) * **Concepts:** [Templates and instances](/contracts/templates-and-instances), [roles and parts](/contracts/roles-and-parts), and [lifecycle](/contracts/lifecycle) * **Reference:** [Contract operations](/neuron-api/api-reference/contracts/overview) # Trust and federation Source: https://docs.neuro-tech.io/concepts/trust-and-federation Decide which operators, providers, domains, and remote Neurons your application trusts Neuro deployments are operator-controlled and can participate in federated workflows. Applications therefore need to ask both **who attests a fact** and **where that attestation is accepted**. ## Separate the trust decisions | Decision | Example question | | ---------------------- | ------------------------------------------------------------------------- | | Authentication | Which account is controlling this session? | | Identity review | Which provider reviewed the identity, under which policy? | | Authorization | Is this account allowed to perform this operation? | | Contract participation | Does this Legal Identity satisfy the party and role requirements? | | Federation | Will the relevant Neurons and domains exchange and accept this operation? | | Application acceptance | Does the relying application accept the returned status and evidence? | A successful HTTP response only answers the operation-level question. It does not automatically answer every policy or cross-domain question above. ## Confirm which Neuron and domain you trust The application connects to an exact Neuron host supplied by its operator. The Neuron's enabled packages, providers, privileges, templates, and federation relationships determine which workflows can complete. Before relying on cross-domain behavior, confirm: * the participating Neurons and identities; * the Trust and Identity Providers involved; * the accepted template or workflow policy; * required privileges and authorization grants; * event or polling behavior for remote state changes; * development, staging, and production federation boundaries. ## Design for asynchronous results Review, approval, proposal, signature, and remote operations can remain pending after the initiating request. Persist the returned identifier and state, then use the documented event, callback, XMPP, or polling mechanism for that deployment. Do not translate “request accepted” into “business workflow complete.” ## Apply the trust model * [Security and transport](/neuron-api/security-and-transport) * [Messaging](/neuron-api/guides/messaging) * [Events and webhooks](/neuron-api/guides/webhooks) # Wallets and payments Source: https://docs.neuro-tech.io/concepts/wallets-and-payments Separate balances, payment initiation, provider flows, and transaction lifecycle state Wallet and payment integrations combine account authorization, value semantics, provider selection, initiation, and asynchronous transaction state. A balance read and a completed payment are different workflows. ## Transaction model ```text theme={null} Authorized account ↓ Confirm environment and value semantics ↓ Read balance and supported provider/options ↓ Initiate an operator-approved payment flow ↓ Persist transaction identifier ↓ Observe pending → finalized or failed ↓ Reconcile balance and audit information ``` ## Protect credentials and value * Confirm whether the environment contains test value or real value. * Confirm the supported wallet/payment product and provider before initiating anything. * Do not infer financial harmlessness from a hostname containing words such as `dev`, `test`, or `sandbox`. * Require explicit human approval before an AI application performs a value-moving tool call unless a separately approved policy defines a safe autonomous boundary. * Keep credentials and bearer tokens out of browser code and logs. * Do not retry initiation blindly; use documented idempotency and transaction-state behavior. ## Product availability Agent API wallet operations and Neuro-Pay are separate interfaces. Ask the Neuron operator which product and provider are supported before implementing a payment flow. ## Build a payment integration * [Build a payment integration](/build/payments/overview) * [Wallet reference](/neuron-api/api-reference/wallet/overview) # Create a contract with the Agent API Source: https://docs.neuro-tech.io/contracts/agent-api-quickstart Propose a template and create a contract instance over HTTP Set `NEURON_REFERER` to your application's HTTPS URL. Include this header on every request, including backend calls. See [required request headers](/neuron-api/api-basics#required-referer-header). Use the Agent API when a web or backend application needs to work with contracts. The API does not require access to the Neuron source code. This page covers template proposal and contract creation. Continue with the [contract lifecycle](/neuron-api/guides/contracts-flow) for proposal delivery and both signatures. ## Before you start You need: * the Neuron host; * an Agent API account and JWT from the [Agent API quickstart](/neuron-api/quickstart); * a current approved Legal Identity for operations that require one; * valid template XML from [the authoring guide](/contracts/from-scratch) or [the example library](/resources/contract-examples). Set the examples' placeholders without committing credentials: ```bash theme={null} export NEURON_HOST="neuron.example.com" export NEURON_JWT="" ``` ## Path A: propose your template Base64-encode the complete UTF-8 XML file as one string: ```bash theme={null} TEMPLATE_BASE64=$(base64 < MyTemplate.xml | tr -d '\n') ``` Submit it: ```bash theme={null} curl --fail-with-body \ -X POST "https://${NEURON_HOST}/Agent/Legal/ProposeTemplate" \ -H "Referer: ${NEURON_REFERER}" \ -H "Authorization: Bearer ${NEURON_JWT}" \ -H "Content-Type: application/json" \ -d "{\"templateBase64\":\"${TEMPLATE_BASE64}\"}" ``` The response contains `Template`; record its `id`. A proposed template must be approved before it can create instances. The [sandbox reviews proposals automatically; other Neurons require operator approval](/build/agreements/overview#contract-approval). Retrieve the template and confirm `Approved` before continuing. ## Path B: create from an approved template If the provider has already supplied an approved template ID, you can begin here: ```bash theme={null} curl --fail-with-body \ -X POST "https://${NEURON_HOST}/Agent/Legal/CreateContract" \ -H "Referer: ${NEURON_REFERER}" \ -H "Authorization: Bearer ${NEURON_JWT}" \ -H "Content-Type: application/json" \ -d '{ "templateId": "", "visibility": "CreatorAndParts", "Parts": [], "Parameters": [] }' ``` Replace `Parts` and `Parameters` with the names and value types defined by that template. The response contains the created `Contract`. An empty `Parts` or `Parameters` array works only when the selected template does not require those values. The template—not this endpoint—defines what must be supplied. ## Continue after creation * Retrieve the returned contract with `POST /Agent/Legal/GetContract`. * Present the exact returned human-readable text before signing. * Use `POST /Agent/Legal/SignContract` only after the signer has reviewed the exact contract and role. The [lifecycle guide](/neuron-api/guides/contracts-flow) defines the signature messages. * Send proposals through `POST /Agent/Xmpp/SendXmlMessage`; `AgentAPI.Legal.SendProposal` is a JavaScript helper, not an HTTP endpoint. See the [contract API reference](/neuron-api/api-reference/contracts/overview) for request fields and responses. # Contract data model Source: https://docs.neuro-tech.io/contracts/data-model See how machine semantics, human text, roles, parameters, and attestations form a signed contract The standard smart-contract namespace used by current clients is: ```text theme={null} urn:nf:iot:leg:sc:1.0 ``` ## Core fields | Field | Purpose | | --------------------------- | ----------------------------------------------------- | | Contract ID | Stable server-assigned identifier | | Template ID | Approved template used to create the instance, if any | | Provider | Trust Provider responsible for the contract | | State | Proposed through Deleted lifecycle state | | Visibility | Who can retrieve or search the contract | | From / To | Optional absolute validity interval | | Duration | Relative contract duration | | Archive required / optional | Retention expectations | | Parts mode | Open, template-only, or explicitly defined signers | | Roles | Signer categories and cardinality | | Parts | Legal Identity and role assignments | | Parameters | Typed instance values and validation | | For machines | Domain XML element | | For humans | Localized structured text | | Client signatures | Legal-identity-backed signer attestations | | Server signature | Trust Provider attestation over validated content | ## Machine-readable section `ForMachines` contains one XML root element. Its qualified name—local name plus namespace—defines the contract's machine semantics. A server can retrieve the corresponding XML schema and validate that the element is well formed. Choose a namespace you control, version it, publish an XSD, and keep backwards compatibility explicit. Do not infer semantics from a local name alone. The [custom schema guide](/resources/custom-schemas) provides a complete example and distinguishes local namespace mapping from provider resolution and executable behavior. ## Human-readable section `ForHumans` is an array of structured, language-tagged documents. The client selects the requested language and can render Markdown, plain text, or HTML. Every material machine rule must have an accurate human explanation. Approval should reject a template when the two sections conflict. ## Signed boundaries Contract normalization produces a deterministic XML representation for signing. A signature is valid only for the exact normalized content and the signer's legal identity key. Transient parameter values are deliberately kept out of the signed/persisted clear-text boundary; encrypted values are signed in protected form. Never reformat contract XML with a general-purpose serializer before verifying a signature. Use the contract library's normalization and validation methods. # Author a contract from scratch Source: https://docs.neuro-tech.io/contracts/from-scratch Build a complete acknowledgement template, validate it, and submit and sign it through the Agent API Create a template with one participant and one text parameter. The complete example records an acknowledgement; its machine-readable instruction performs no payment or token creation. The XML passes the documented local schema checks. Template approval and signing still need verification on your development service. Arrange that service access before running the submission steps. ## Prerequisites * Complete [your first Agent API call](/neuron-api/first-request). * Have an [approved Legal Identity](/neuron-api/guides/getting-your-identity-approved) and its signing key metadata and password. * Confirm your provider accepts the `urn:nf:iot:leg:sc:1.0` contract schema and the payment instruction namespace used below. * Use the [sandbox automatic approval process or arrange operator review](/build/agreements/overview#contract-approval). Submitting a template does not mean it is already approved. * Use an XML editor or validator that supports XSD validation; follow [local XML validation](/resources/validate-xml). ## 1. Define the contract Download [acknowledgement.xml](/downloads/examples/acknowledgement.xml). The complete file is shown below; you can also start with an empty file and add its sections in this order. | Section | Purpose | What you can adapt | | --------------------- | -------------------------------------------------------------------- | ------------------------------------------------------------------------ | | `contract` attributes | Set visibility, template eligibility, duration, and archival periods | Review these periods and visibility with your provider and participants. | | `Nop` | Supply a schema-defined machine-readable instruction | Replace it only with a supported instruction and its exact schema. | | `role` | Require one `Participant` | Keep this name aligned with the API's `Parts` entry. | | `parts` | Mark the document as a template | The instance receives actual Legal Identity identifiers. | | `parameters` | Require `Subject`, between 1 and 120 characters | Keep the API parameter name and human text reference aligned. | | `humanReadableText` | Explain the acknowledgement and retention terms | Present the resulting instance text before requesting a signature. | ```xml theme={null} The participant acknowledging the stated subject. The subject the participant will review. The participant acknowledges reviewing: . This demonstration records an acknowledgement. It instructs no payment and creates no token. The instance lasts one month, followed by one month of required archival and one month of optional archival. ``` ## 2. Validate the file Load the [contract schema set](/resources/schemas) in your XML validator and validate the complete `acknowledgement.xml` file using [these steps](/resources/validate-xml). Expected result: the schema set compiles and the contract has no XML validation errors. Correct invalid namespaces, missing required fields, or element ordering before submission. If you introduce a custom machine-readable element, also create its XSD, load it in the local namespace map, and confirm the provider's schema resolution requirements. An arbitrary XML payload is not a verified provider-supported instruction. ## 3. Propose the template Send the following requests over HTTPS with your account’s exact host, JWT, and application URL as `Referer`. Replace every placeholder before sending a request. Base64-encode the complete file’s UTF-8 bytes, then send: ```http theme={null} POST /Agent/Legal/ProposeTemplate HTTP/1.1 Host: Referer: https://your-app.example/ Authorization: Bearer Accept: application/json Content-Type: application/json { "templateBase64": "" } ``` The `templateBase64` field contains that encoded XML. [Propose Template](/neuron-api/api-reference/contracts/propose-contract-template) returns `Template`. Record its identifier. In the sandbox, the submitted template enters automatic review. On other Neurons, give the identifier to the operator to arrange approval. See [Contract approval](/build/agreements/overview#contract-approval). Retrieve it with `Legal/GetContract` using the request shown below and the template identifier to observe its lifecycle. Continue only when its state is `Approved`. If it remains `Proposed` or is `Rejected`, contact the operator before creating an instance. ## 4. Create an instance Send the approved template identifier and the participant's approved Legal Identity to `Legal/CreateContract`: ```http theme={null} POST /Agent/Legal/CreateContract HTTP/1.1 Host: Referer: https://your-app.example/ Authorization: Bearer Accept: application/json Content-Type: application/json { "templateId": "", "visibility": "CreatorAndParts", "Parts": [{ "role": "Participant", "legalId": "" }], "Parameters": [{ "name": "Subject", "value": "A demonstration subject for review" }] } ``` Record the returned `Contract` identifier separately from the template identifier. The role and parameter names are case-sensitive names from the template. Do not send empty arrays for this example. ## 5. Review and sign the instance Retrieve the created instance using its identifier: ```http theme={null} POST /Agent/Legal/GetContract HTTP/1.1 Host: Referer: https://your-app.example/ Authorization: Bearer Accept: application/json Content-Type: application/json { "contractId": "" } ``` Present its human-readable text, parameters, participant identity, and `Participant` role to the signer. If any value is wrong, stop before signing. Use the participant's existing key and its password. Calculate `keySignature` and `requestSignature` from the [contract signature formulas](/neuron-api/guides/contracts-flow#construct-a-contract-signature), using the key's `keyId`, `localName`, and `namespace`, the account password, and a fresh nonce. Bind the signature to the reviewed `contractId`, `legalId`, and role `Participant`. The key namespace is algorithm metadata retained during [key creation](/neuron-api/guides/creating-cryptographic-keys). It is not the contract XML namespace. After the signer confirms the exact contract and role, submit the signature explicitly: ```http theme={null} POST /Agent/Legal/SignContract HTTP/1.1 Host: Referer: https://your-app.example/ Authorization: Bearer Accept: application/json Content-Type: application/json { "keyId": "", "legalId": "", "contractId": "", "role": "Participant", "nonce": "", "keySignature": "", "requestSignature": "" } ``` Retrieve the instance again with `Legal/GetContract` and the same `contractId`. Check the returned participant signature and contract lifecycle state. A successful signature request alone does not establish that every provider requirement is satisfied. For multiple parties, repeat review and signing in each party's authorized application session using the [contract lifecycle guide](/neuron-api/guides/contracts-flow). ## Recover and retain the result | Failure | Next action | | -------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | | Template still proposed or rejected | Retrieve its status and resolve the provider review. Do not repeatedly create instances. | | Missing participant or invalid subject | Correct the `Parts` or `Parameters` values against the approved template. | | Signature rejected | Check approved identity, assigned role, exact host, key metadata, and the two distinct passwords. Generate a fresh nonce. | | Request times out after submission | Retrieve the known object or reconcile with the provider before retrying a write. These operations do not document an idempotency guarantee. | Retain the template ID, instance ID, reviewed parameters, participant identity, and observed signature/lifecycle result. The example defines duration and archival periods; deleting your local files does not delete a signed contract. Follow the provider's supported lifecycle and retention rules. Continue with [a token and state machine](/build/tokenized-assets/from-scratch), or adapt a [LegalLab example](/resources/contract-examples) to a different agreement. # Human-readable contract text Source: https://docs.neuro-tech.io/contracts/human-readable-text Create localized agreement text that stays bound to machine-readable parameters Human-readable text is structured content, not an unrelated PDF attachment. It can reference roles and parameter values so the document a signer reads is generated from the same contract object the client signs. ## Language selection Provide one `HumanReadableText` document per supported language. Clients select an exact language match and otherwise fall back to the first available document. Put the primary/legal fallback first. ## Bind values into text Use the contract human-readable element model for: * paragraphs and sections; * lists and tables; * emphasis and links; * parameter values; * role names and role-reference values; * conditional content supported by the schema. Do not paste calculated values as fixed prose. A parameter reference ensures the rendered value follows the signed instance. ## Rendering Render through a contract-aware tool so parameter formatting, language choice, and supported elements remain consistent. Do not build the signing view from a separate prose copy. Use [LegalLab](/contracts/legallab-quickstart) to load the contract XML and preview its human-readable languages while authoring a template. ## Approval checklist Before proposing a template: 1. Render every language. 2. Substitute boundary values for every parameter. 3. Confirm required roles, counts, dates, fees, units, and termination rules agree with the machine section. 4. Confirm links and attachments are durable and authorized. 5. Confirm no unsupported language silently falls back to misleading text. 6. Have the Trust Provider review both sections together. A translation can change legal meaning. Machine translation is a drafting aid; each production language version requires appropriate review. # Try a contract in LegalLab Source: https://docs.neuro-tech.io/contracts/legallab-quickstart Clone and build LegalLab, edit an example contract, and submit the XML through the Agent API LegalLab is a Windows desktop application for editing Legal Identities, contracts, and Neuro-Features. Build it from source, open an example from the repository, and save your own contract XML. ## Before you start You need Windows, Git, the .NET 8 SDK, and Internet access to restore the project's packages. LegalLab targets `net8.0-windows` and uses WPF. You can edit a contract locally before connecting an account. Submitting it later requires the [Agent API access](/get-started/api-access) and provider review described in the authoring guide. ## 1. Clone both repositories Run these commands from the parent directory where you keep your projects: ```bash theme={null} git clone https://github.com/Trust-Anchor-Group/LegalLab.git git clone https://github.com/Trust-Anchor-Group/MicrosoftInterop.git ``` Keep the folders side by side: ```text theme={null} YourProjects/ LegalLab/ LegalLab/LegalLab.csproj ExampleContracts/ MicrosoftInterop/ TAG.Content.Microsoft/TAG.Content.Microsoft.csproj ``` LegalLab references the `TAG.Content.Microsoft` project using this relative layout. That library provides Word-to-Markdown conversion. See the [LegalLab source project](https://github.com/Trust-Anchor-Group/LegalLab/blob/main/LegalLab/LegalLab.csproj). ## 2. Build and start LegalLab From the parent directory used above, enter the LegalLab clone and build it: ```bash theme={null} cd LegalLab dotnet build LegalLab/LegalLab.csproj --configuration Release dotnet run --project LegalLab/LegalLab.csproj --configuration Release --no-build ``` The build restores the required packages. The run command opens the desktop application. ## 3. Open an example from your clone In **Design**, select **Load** and choose a file under `ExampleContracts`: | Example | What to learn | | -------------------------------------- | ------------------------------------------- | | `Syntax/ParameterTypes.xml` | Parameter types and constraints. | | `Syntax/CalculatedParameters.xml` | Expressions that calculate contract values. | | `Tokens/Create/Specific/DemoToken.xml` | A token creation contract. | Start with `ParameterTypes.xml`. The [LegalLab example catalog](/resources/contract-examples) explains the roles, parameters, and schema dependencies of the other examples. ## 4. Edit and save a copy Inspect **General Information**, **Roles**, **Parameters**, and the human-readable text. Change one label or default parameter value, then select **Save** and choose a new filename. Load your saved file again and confirm the change is present. [Validate the complete XML](/resources/validate-xml) before submitting it. ## 5. Submit through the Agent API Use your saved XML in [Propose the template](/contracts/from-scratch#3-propose-the-template). That guide continues through provider approval, instance creation, review, and signing. ## If the build or load fails | Problem | What to check | | ---------------------------------- | ----------------------------------------------------------------------------------------------------- | | Referenced project missing | Both repositories must be sibling directories named exactly as shown above. | | Windows desktop target unavailable | Build on Windows with the .NET 8 SDK installed. | | Package restore fails | Check access to the package sources used by the projects and the reported package error. | | XML fails to load | Confirm the complete file and its schema dependencies using the example catalog and validation guide. | # Contract lifecycle Source: https://docs.neuro-tech.io/contracts/lifecycle Handle proposal, approval, signing, failure, obsoletion, and deletion states ## States | State | Meaning | Normal next states | | ------------- | --------------------------------------------------------------- | ----------------------------- | | `Proposed` | Awaiting review and approval | Approved, Rejected | | `Rejected` | Incomplete, inconsistent, or faulty | Proposed after creator update | | `Approved` | Reviewed; can act as a template or begin signing | BeingSigned | | `BeingSigned` | At least one signature exists but required roles are incomplete | Signed, Failed | | `Signed` | All required role counts are satisfied; legally binding | Failed, Obsoleted | | `Failed` | Obligations failed or provider marked it failed | Terminal by policy | | `Obsoleted` | Explicitly superseded/retired | Terminal | | `Deleted` | Deleted by owner/provider under allowed rules | Terminal | The server owns lifecycle enforcement. A client must treat a successful API response and the returned state as authoritative rather than updating local state optimistically. The [sandbox processes new proposals automatically; operators are responsible for approval on other Neurons](/build/agreements/overview#contract-approval). Approval and party signatures remain separate lifecycle steps. ## Typical flow ```mermaid theme={null} stateDiagram-v2 [*] --> Proposed Proposed --> Rejected: review fails Rejected --> Proposed: creator updates Proposed --> Approved: review succeeds Approved --> BeingSigned: first valid signature BeingSigned --> Signed: required roles complete BeingSigned --> Failed Signed --> Failed Approved --> Obsoleted Signed --> Obsoleted Proposed --> Deleted Rejected --> Deleted ``` ## Event handling Persist the contract ID, state, update timestamp, and last processed event ID. Notifications can be duplicated or arrive after a reconnect, so handlers must be idempotent and should re-fetch the contract before taking an irreversible action. ## Visibility | Visibility | Retrieval/search behavior | | ------------------ | --------------------------------------------------- | | `CreatorAndParts` | Creator and named parts only | | `DomainAndParts` | Creator, parts, and accounts on the provider domain | | `Public` | Anyone with the ID can retrieve; not searchable | | `PublicSearchable` | Public retrieval and search | Visibility is not a substitute for parameter protection. Do not put secrets in a public contract. # Contract structure Source: https://docs.neuro-tech.io/contracts/overview Learn how machine-readable XML, human text, roles, parameters, and signatures form a contract A Neuron contract is a signed, machine-readable agreement with human-readable text. It is not program code deployed to a blockchain. A contract defines: * the machine-readable XML payload; * the text each signer sees; * roles and required signatures; * typed parameters and validation; * visibility, validity, and lifecycle rules. Use the [contract quickstart](/contracts/quickstart) to choose LegalLab or the Agent API. Return here when you need to understand the format those tools read and write. ## Templates and instances A template defines the roles and parameters that can be filled later. It must be proposed and approved before an application can create contract instances from it. ```text theme={null} contract XML → proposed template → approved template → contract instance → signatures ``` Start with [Templates and instances](/contracts/templates-and-instances) when this distinction is unfamiliar. ## MCP's role The built-in Neuron MCP servers do not currently propose templates, create contracts, or sign contracts. An MCP-capable development client can still help edit XML, inspect files, retrieve reference content, or query events. Use LegalLab or the Agent API for the contract operation itself. Choose a tool and make a controlled change to an example contract. # Contract parameters Source: https://docs.neuro-tech.io/contracts/parameters Define typed values, constraints, validation expressions, and confidentiality Parameters turn an approved structure into a reusable template. The contract library supports these parameter families: * boolean; * string; * numerical; * date, date-time, time, and duration; * geographic coordinate; * attachment; * calculated value; * role/identity property reference; * contract reference. ## Common fields Every parameter has a stable `Name`, localized description, optional guide text, optional validation `Expression`, and a `Protection` level. Range types add minimum/maximum values and inclusive/exclusive bounds; strings can add length or pattern constraints. ## Validation expressions The `Expression` is evaluated with contract parameters exposed as Script variables. Return `false` to reject the value: ```text theme={null} Quantity>0 AND UnitPrice>=0 ``` Keep expressions deterministic. Do not depend on wall-clock time, mutable external services, or server-local state unless the contract protocol explicitly defines that dependency. The server remains the final validator. ## Protection levels | Level | Storage/signature behavior | Use | | ----------- | ------------------------------------------------------------------------------ | ---------------------------------------- | | `Normal` | Clear value is serialized | Public contract data | | `Encrypted` | Creator encrypts the value; protected bytes are serialized | Data shared only with authorized parties | | `Transient` | Clear value is not persisted; a generated GUID is used in the signed structure | Data needed only in transit | For encrypted parameters, the creator creates encryption/decryption keys and shares them with parties over end-to-end encrypted communication. A nonce and parameter position/name/type contribute to protection. ## Template rules * Give each parameter a unique, stable name. * Put units in a typed unit/field or description, never only in a UI label. * Validate relationships between parameters in addition to individual ranges. * Explain every parameter in the human-readable text using parameter-value elements. * Treat changing a parameter's meaning as a new template version. * Do not place secrets in normal parameters of a public/searchable contract. Use [LegalLab](/contracts/legallab-quickstart) to edit parameter definitions, test values, and inspect the resulting human-readable text before proposing a template. # Choose a contract task Source: https://docs.neuro-tech.io/contracts/quickstart Create from an approved template, author a complete contract, or adapt a LegalLab example through the Agent API Create contract instances through the Agent API. Start from an approved template when it already expresses your agreement, or author XML when you need a new template. Supply the template's roles and parameters, then create and review the instance. Define a complete acknowledgement, validate its XML, and submit it through the Agent API. Choose original XML by use case and check its dependencies before editing. Combine a creation contract, state machine, and embedded Script. ## Prepare access for the chosen task | Task | Requirement | | ------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | | Author and validate XML locally | A text editor and the [schema tools](/resources/validate-xml); LegalLab is optional. | | Propose a template | Agent API access, an approved Legal Identity, and [sandbox automatic review or operator approval](/build/agreements/overview#contract-approval). | | Create an instance | A usable approved template, correct roles and parameters, and account privileges. | | Deliver a proposal | The recipient identifier and the [Agent API message operation](/neuron-api/api-reference/contracts/send-proposal). | | Sign as a party | Explicit review of the instance and role, an approved Legal Identity, and its signing key. | Local XML validation, provider approval, signatures, and completed execution are separate checks. Each task guide states which have been verified and what your development provider must supply. Use the [contract concepts](/concepts/smart-contracts) to understand templates and instances, or the optional [LegalLab editor](/contracts/legallab-quickstart) to inspect files visually. # Roles and signing parts Source: https://docs.neuro-tech.io/contracts/roles-and-parts Model signer categories, cardinality, revocation, and explicit parties A **role** defines a category of signer. A **part** binds a Legal Identity to one role in a contract instance. ## Role fields | Field | Meaning | | ------------ | ---------------------------------------------------------------- | | `Name` | Stable role identifier used by parts, parameters, and signatures | | `MinCount` | Minimum valid signatures required for the role | | `MaxCount` | Maximum parties/signatures permitted for the role | | `CanRevoke` | Whether a signer in the role can revoke after signing | | Descriptions | Localized explanation of the role | Role names are contract API identifiers. Do not translate them; translate their descriptions. ## Parts modes | Mode | Behavior | | ------------------- | ----------------------------------------------- | | `Open` | Anyone who satisfies the role rules can sign | | `TemplateOnly` | The document is a template and cannot be signed | | `ExplicitlyDefined` | Only listed Legal Identities can sign | ## Example design For a bilateral service agreement: | Role | Min | Max | Revoke | | ---------- | --: | --: | ------ | | `Provider` | 1 | 1 | No | | `Customer` | 1 | 1 | No | The instance lists one provider Legal ID and one customer Legal ID as parts. The contract becomes `Signed` only after both valid signatures exist. ## Role-reference parameters A role parameter copies an approved Legal Identity property into a parameter slot when that role signs. This can bind contract text to facts such as organization name, country, or another identity property without manual re-entry. If a required property is missing from the identity, role-parameter population fails. Clear populated role parameters before reassigning a part. ## Design guidance * Use the minimum number of roles that expresses the legal relationship. * Set bounded `MaxCount`; an unbounded role can change signature semantics. * Explain revocation consequences in the human-readable section. * Do not use an XMPP JID where a Legal Identity ID is required. * Decide whether parties are fixed before proposal or selected when instantiating a template. Use [LegalLab](/contracts/legallab-quickstart) to inspect role definitions and party assignments together with the rendered agreement before proposing a template. # Sign and validate contracts Source: https://docs.neuro-tech.io/contracts/signing-and-validation Verify structure, identity, normalization, signatures, state, and server attestation Signing proves that a Legal Identity key accepted a specific normalized contract in a specific role. Validation must check more than the signature bytes. ## Before signing 1. Fetch the current contract from its provider. 2. Verify the provider/domain and contract ID. 3. Validate the XML and parameter rules. 4. Render the selected human-readable language. 5. Confirm machine and human sections agree. 6. Confirm the signer's Legal Identity is approved and assigned/eligible for the role. 7. Confirm validity dates and current state permit signing. ## Key selection The contract library supports: | `SignWith` | Key source | | ------------------------------- | ----------------------------------------------------------- | | `CurrentKeys` | Current endpoint keys | | `LatestApprovedId` | Keys from the latest approved Legal Identity | | `LatestApprovedIdOrCurrentKeys` | Legal Identity keys when available, otherwise endpoint keys | Legally binding contract signatures should use the approved Legal Identity keys required by the workflow. ## Validate a received contract Check: * recognized smart-contract namespace and schema; * deterministic normalization; * parameter types, ranges, expressions, and protected forms; * each client signature against the referenced Legal Identity and signed role; * role `MinCount`/`MaxCount` and explicit part rules; * legal identity state and trust chain; * server signature/attestation; * lifecycle state, timestamps, and visibility; * attachment hashes/signatures where used. Validation that depends on current identities, schemas, or provider state requires a connected client. Offline validation can cover local structure and rendering, but it cannot establish current network state. Use [LegalLab](/contracts/legallab-quickstart) to load, render, and inspect a contract before proposing or signing it. The Neuron and Trust Provider remain authoritative for identity, approval, and contract state. ## Replay and race safety Re-fetch immediately before signing, and submit the signature against the exact version you reviewed. If the contract changed, discard the signature and render the new version. Store the returned contract state and signature identity for audit. # Token state machines Source: https://docs.neuro-tech.io/contracts/state-machines Define auditable token workflows with states, events, actions, and persisted variables A Neuro-Feature creation contract can embed a state-machine definition in the token's machine-readable `Definition`. The machine is optional. When present, the Trust Provider creates it as the token batch is created and links it to the creation contract and the first token in the batch. Use a state machine when a token must react predictably to time, payments, contract signatures, notes, transfers, destruction, or persistent-data events. The XML fragments illustrate individual features. Validate your complete definition and test its transitions on a development Neuron before using it with real assets. Use the [schema catalog](/resources/schemas), [XML validator](/resources/validate-xml), and [Script reference](/script/overview) when authoring a complete definition. ## Definition namespace The root element uses the following schema namespace: ```text theme={null} https://paiwise.tagroot.io/Schema/StateMachines.xsd ``` The smallest useful definition has a required `startState`, at least one `State`, and any referenced `Action` elements: ```xml theme={null} OwnerJid PT1H ``` This fragment belongs inside the Neuro-Feature `Create` element of a smart contract; it is not a complete contract by itself. ISO 8601 duration `PT1H` means one hour. ## Evaluation model The machine follows this sequence: 1. Resolve initial variables from constants, token properties, token tags, or Script expressions. 2. Enter `startState` and execute its `OnEnter` action references. 3. Register the active state's event handlers. 4. When an event matches, evaluate `beforeActionScript`, run `actionRef`, and move to `newState`. 5. Run the old state's `OnLeave` actions and the new state's `OnEnter` actions. 6. Sample the state and persisted variables unless sampling is explicitly suppressed. An `OnEvent` may set `failureState` for action failures and `suppressSample` when a transition should not create the normal audit sample. Treat both as advanced controls: hiding samples weakens the history available to reviewers. ## Variables and values Top-level `Variable` elements initialize machine context. Their values can be: * A token tag through `TagReference` * A built-in token property through `TokenProperty` * Typed literals: `String`, `Number`, `Boolean`, `Uri`, `Binary`, `Date`, `DateTime`, `Time`, or `Duration` * A Script expression through `Calc` Common token properties include `TokenId`, `CreatorJid`, `OwnerJid`, `TrustProviderJid`, `Value`, `Currency`, `Created`, `Updated`, `Expires`, `CreationContract`, `OwnershipContract`, `FriendlyName`, `Ordinal`, and `BatchSize`. Variables changed while an action runs are ephemeral unless the action uses `PersistVariable`. Persisted variables are sampled for audit and survive subsequent actions: ```xml theme={null} ``` The braces in `value` mark a Script expression. Without them, a scriptable attribute is treated as a literal. Set `suppressSample` only when a separate operation deliberately controls sampling. ## Event types Events can be declared inline under `OnEvent`, or declared once as an `Event` and reused through `EventReference`. | Family | Event elements | Use | | ------------------- | ----------------------------------------------------------------------- | --------------------------------------------------------------------------------------- | | Conditions and time | `OnCondition`, `OnDuration`, `OnTime`, `OnDateTime` | Evaluate a condition or wake the machine at a duration/time | | Payments | `OnPaymentReceived`, `OnPaymentSent` | React to ledger payments and capture parties, amount, currency, reference, or condition | | Notes | `OnTextNote`, `OnXmlNote`, `OnExternalTextNote`, `OnExternalXmlNote` | Treat token notes as commands or external signals | | Contracts | `OnContractSignature`, `OnContractSigned`, `OnContractTemplateApproved` | React to legal workflow milestones and capture contract context | | Token lifecycle | `OnTransferred`, `OnDestroyed` | React to ownership or terminal token events | | Persistence | `OnEntryAdded`, `OnEntryUpdated`, `OnEntryDeleted` | React to changes in a selected collection and type | XML-note and contract events can filter on `localName` and `namespace`. External-note events can also require a `privilege`; use that instead of accepting arbitrary external senders. `OnTime` and `OnDateTime` accept time coordinates such as `Local`, `UTC`, or a quarter-hour UTC offset. Prefer `UTC` for workflows that cross legal or geographic boundaries. ## Action types An `Action` is an ordered sequence. The schema supports: * Payments: `Payment`, `ReserveAmount`, `ReleaseAmount`, `BuyEDaler`, and `SellEDaler` * Notes and authorization: `TextNote`, `XmlNote`, `AuthorizeSource`, and `UnauthorizeSource` * Communication: `HttpPost`, `XmppMessage`, `XmppIqGet`, `XmppIqSet`, and `MailMessage` * Runtime data: `PersistVariable`, `CreateEntry`, `PersistHash`, and `LogEvent` * Control flow: `If`, `IfHash`, `Switch`, `For`, `ForEach`, `While`, `Do`, and `Try`/`Catch`/`Finally` * Composition and lifecycle: `Script`, `CallAction`, `ScheduleAction`, `End`, `Destroy`, and `Fail` Values can be supplied as attributes when simple, or as typed child elements when they are calculated. Response-producing actions such as `HttpPost` and XMPP IQ can store their result in a named variable. State-machine actions can transfer value, disclose data, call remote systems, and destroy tokens. Review every transition as production code. In particular, constrain external-note sources, validate remote responses, and make retry behavior safe. ## Singleton machines and token batches One creation contract can produce a batch of tokens. The embedded definition creates one state-machine for that batch, not one independent machine per token. Use `SingletonMachineId` with a tag reference when multiple token creations must resolve to the same logical machine identifier. Token properties such as `Ordinal` and `BatchSize` let actions reason about the current token in a batch. ## Note commands `NoteCommand` describes a client-facing command that generates a token note. It can provide localized `Title`, `ToolTip`, `Confirmation`, `Success`, and `Failure` text; typed parameters; a context Script; and a note-generation Script. The flags determine where the generated note may be used: * `ownerNote`: add the note as the token owner. * `externalNote`: submit it from an authorized external source. * `personal`: mark the note as personal rather than generally visible. The resulting text or XML note can trigger a matching note event in the machine. Validate generated XML against its namespace schema before exposing the command to users. ## Reports and inspection Use the Agent API to inspect a running machine: * [Get current state](/neuron-api/api-reference/state-machines/get-current-state) returns its current state. * [Create report](/neuron-api/api-reference/state-machines/create-report) produces present-state, history, diagram, or profiling output. Definitions can also include `ReportPresent` and `ReportHistory` Script templates to control human-readable report content. ## Implementation checklist * Validate the complete contract and embedded machine against their XML schemas. * Confirm every `startState`, `newState`, `failureState`, `actionRef`, and `eventRef` resolves. * Use explicit namespaces for XML and contract event filters. * Persist only values required across actions; name audit-relevant values clearly. * Decide how every remote call behaves on timeout, rejection, and retry. * Generate present, history, state-diagram, and profiling reports in a staging environment. * Exercise payment, signature, note, transfer, and terminal paths before signing the creation contract. # Templates and contract instances Source: https://docs.neuro-tech.io/contracts/templates-and-instances Propose an approved reusable template, then create safe instances A template is an approved contract in `TemplateOnly` parts mode. It defines the machine schema, human text, roles, parameter definitions, and policy that instances inherit. ## Propose a template 1. Define a versioned machine-readable root namespace. 2. Provide the schema needed to validate it. 3. Define roles and signature cardinality. 4. Define parameters, validation, and protection. 5. Write and render each human language. 6. Set validity, archive, and visibility rules. 7. Submit the template through the Agent API for [sandbox automatic review or operator approval](/build/agreements/overview#contract-approval). 8. Resolve review feedback and resubmit if it is `Rejected`. Only an `Approved` template should be used to create instances. ## Create an instance Provide: * approved template ID; * part assignments when explicitly defined; * all required parameter values; * intended visibility; * optional validity interval/duration allowed by the template. Then fetch the returned contract and verify its state and resolved values before presenting it for signature. ## Versioning Do not mutate an approved template in a way that changes existing agreement meaning. Propose a new template version when you change: * machine namespace/schema; * role names or counts; * parameter type or meaning; * protection level; * human legal terms; * signing, duration, or archival policy. Existing instances retain their original template ID and content. ## Tooling LegalLab can load XML templates, edit roles and parameters, render content, propose templates, and create instances. Treat it as an authoring client; the Neuron/Trust Provider remains authoritative for approval and state. For an HTTP workflow, use [Create contract](/neuron-api/api-reference/contracts/create-contract) and [Propose contract template](/neuron-api/api-reference/contracts/propose-contract-template). Begin with a complete example rather than assembling the enclosing XML from these conceptual pages. See the [contract quickstart](/contracts/quickstart). # Use Neuro documentation with coding agents Source: https://docs.neuro-tech.io/developer-tools/agent-tools Give coding agents current Neuro context through skill.md, llms.txt, or the documentation MCP server Neuro publishes its documentation in formats that coding agents can search and retrieve. These documentation tools are separate from the **Agent API**, Neuro's main HTTP API. ## Choose a documentation interface | Need | Use | | ---------------------------------------------------------- | ----------------------------------------------------------- | | Install reusable Neuro instructions into a coding agent | [`skill.md`](https://docs.neuro-tech.io/skill.md) | | Discover documentation pages and their descriptions | [`llms.txt`](https://docs.neuro-tech.io/llms.txt) | | Retrieve the complete documentation corpus | [`llms-full.txt`](https://docs.neuro-tech.io/llms-full.txt) | | Let an AI tool search and retrieve current pages on demand | [Documentation MCP](https://docs.neuro-tech.io/mcp) | ## Install the Neuro skills Run the skills CLI from the project where you want to use Neuro: ```bash theme={null} npx skills add https://docs.neuro-tech.io ``` The published skill index includes only instructions that pass the repository's documentation checks. Other capabilities remain available as regular documentation. ## Give an agent a task State the intended outcome, runtime, and environment. For example: ```text theme={null} Use the Neuro documentation skill to add a server-side health check that logs in through the Agent API and reads the account information. Use the existing backend language and the development Neuron. Include the application Referer on every request. Keep credentials and the returned JWT out of logs. ``` Review the generated change against the selected guide and API reference. Do not let a coding agent infer missing endpoints or fields from similar operations. ## Distinguish coding agents from the Agent API The **Agent API** is Neuro's HTTP interface. A caller acts through a Neuron's Agent endpoint rather than connecting directly through XMPP and managing the account's private keys. The term is unrelated to artificial intelligence. Use **AI agent** or **coding agent** only when referring to artificial intelligence. The documentation MCP server retrieves documentation; it does not execute application operations. For tools that work with Neuro accounts, contracts, and payments, use [Neuron MCP servers](/mcp/overview). ## Next * [Application architecture](/get-started/choose-integration) * [Agent API quickstart](/neuron-api/quickstart) * [Authoring resources](/resources/overview) # Get access to the Agent API Source: https://docs.neuro-tech.io/get-started/api-access Connect using an API key and secret to create an account, or existing account credentials to sign in To get started with the Agent API, you need the **exact HTTPS host** supplied by your service provider and **one of these two options**: | What you have | Next step | | ------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | | **An API key and its secret** | [Create an account](/neuron-api/guides/creating-an-account) from your backend, then sign in with that account's username and password. | | **Existing account credentials: username and password** | [Sign in and make your first API request](/neuron-api/first-request). You do not need an account-creation API key. | If you have neither, ask your organization, event organizer, or service provider for an API key and secret or an existing account. The API key and secret authorize account creation. Signing in with account credentials returns a JWT, which you use for subsequent authenticated requests. ## Use the Neuro sandbox The development sandbox is available at **[https://sandbox.neuro-tech.io](https://sandbox.neuro-tech.io)**. Its broker/Neuron operator supplies the account-creation API key and secret. Follow the [sandbox quickstart](/neuron-api/quickstart) to create an account, enable it through the public sandbox helper, and obtain an automatically approved test identity. These shortcuts are specific to the sandbox. ## Confirm your service details Ask your service provider for the details below. | Detail | Why you need it | | ---------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- | | Exact HTTPS host, including a non-default port | Requests and login signatures must use the same host. | | Your application's HTTPS URL | Send it as [`Referer`](/neuron-api/api-basics#required-referer-header) on every Agent API call, including backend requests. | | Enabled capabilities and privileges | Authentication does not grant every operation. | | Development data and value policy | Know whether identities, agreements, and wallet values are test data. | | Supported Neuron build | Match schemas and behavior to the service you will use. | Neuro does not use one shared API host. Use the address supplied for your account: ```text theme={null} https:///Agent/... ``` ## Keep credentials in your backend Keep the account-creation API secret, account credentials, and returned JWT in your backend. For signup from a browser application, follow [browser signup](/neuron-api/guides/browser-based-signup). ## Add capabilities when needed Contract participation needs an approved Legal Identity and the appropriate signing key. Creating instances needs an approved template. Token creation can also require provider-specific attributes and signatures. Each [Build guide](/build/overview) explains those prerequisites before you submit a request. If login succeeds but an operation is rejected, check [authorization and privileges](/neuron-api/authorization-and-privileges) with your service provider. # Design your Agent API application Source: https://docs.neuro-tech.io/get-started/choose-integration Connect a backend, browser, or mobile application to Neuro over HTTPS Use the **Agent API** for your Neuro application. A standard HTTP client is enough; the examples do not require a Neuro SDK or an XMPP connection. ## Backend services Your backend signs a login request, receives a JWT, and calls the required HTTP operations. Keep passwords, signing credentials, and JWTs in protected server-side storage. Use the [first-call example](/neuron-api/first-request) to verify access. ## Browser and mobile applications Route privileged operations through your application backend: ```text theme={null} Browser or mobile application → Your backend → HTTPS Agent API → Neuron ``` The backend exposes only the data and actions needed by the UI. Do not place an account-creation secret, account password, signing-key password, or privileged JWT in browser code or a distributable app. Follow [Add Neuro to your application](/get-started/first-application) to connect your interface and track API results. For supported user-interactive signup, follow [browser signup](/neuron-api/guides/browser-based-signup), including its session handoff. ## Contracts and tokens Author contract XML locally and validate it with the [schema resources](/resources/schemas). Your application submits templates, creates instances, and retrieves results through the Agent API. [LegalLab](/contracts/legallab-quickstart) can help edit XML; it is optional for application integration. A [state machine](/contracts/state-machines) or embedded [Neuron Script](/script/overview) defines behavior inside the token creation contract. It does not change how your application connects. ## Messages and asynchronous results Paths such as `/Agent/Xmpp/SendXmlMessage` are HTTP endpoints. Use the exact message format in [contract proposal delivery](/neuron-api/api-reference/contracts/send-proposal). Your application does not need to manage the underlying transport connection. Persist returned identifiers and [observe completion](/neuron-api/events-and-asynchronous-state). Successful submission can precede identity review, template approval, signatures, or token creation. # Add Neuro to your application Source: https://docs.neuro-tech.io/get-started/first-application Connect your application, choose its first capability, and track the result Connect your application to the Agent API using your existing backend language and HTTP client. Start with account access, then add the identity, contract, token, or payment flow your product needs. ## 1. Connect an account Choose the flow matching your credentials: | What you have | Start here | Result | | ------------------------------------- | --------------------------------------------------------------- | ---------------------------------------------------------------------------------------- | | An operator-issued API key and secret | [Create a sandbox account and identity](/neuron-api/quickstart) | Enabled test account, JWT, signing key, and approved test identity. | | Existing account credentials | [Sign in with an existing account](/neuron-api/first-request) | JWT and account information. Add identity onboarding if your next operation requires it. | Use the exact host for that account. Send your application's HTTPS URL as `Referer` on every Agent API call, including requests from a backend. ## 2. Connect your interface to the API flow For a web or mobile product, let your backend coordinate the Agent API requests: ```mermaid theme={null} sequenceDiagram participant User participant App as Your interface participant Backend as Your backend participant API as Agent API User->>App: Request an action App->>Backend: Submit the user's input Backend->>Backend: Check the application session and permitted action Backend->>API: HTTPS request with Referer and authentication API-->>Backend: Result or identifier for pending work Backend-->>App: Application result and progress App-->>User: Show the outcome or next required action ``` Map each application user to the Neuro account and objects they may use. Keep account passwords, API secrets, signing-key passwords, and JWTs in protected backend storage. Return the fields your interface needs to display the outcome. For user-interactive account onboarding, the [browser signup flow](/neuron-api/guides/browser-based-signup) describes the supported form and session handoff. ## 3. Add your first capability Each guide shows the requests, prerequisites, and result to check: | Your application needs to… | Follow | Retain | | --------------------------------------- | ------------------------------------------------------------------------------ | ----------------------------------------------------------------- | | Identify a participant | [Apply for a Legal Identity](/neuron-api/guides/applying-for-a-legal-identity) | Key metadata, Legal Identity ID, and observed approval status. | | Create an agreement | [Author a contract from scratch](/contracts/from-scratch) | Template ID, contract ID, assigned parties, and signature status. | | Create an asset with automated behavior | [Create a token with a state machine](/build/tokenized-assets/from-scratch) | Creation contract ID, token ID, and observed machine state. | | Add funds through a payment provider | [Integrate an eDaler purchase](/build/payments/buy-edaler) | Provider identifiers, transaction ID, and payment outcome. | Present the exact contract and role before signing, and the provider, amount, and currency before initiating a payment. Submit the action after the user confirms those details. ## 4. Track completion Store each returned identifier with the corresponding application record and Neuron host. Some requests start work that completes later: an identity can await approval, a contract can await signatures, and a payment can remain pending. Use the retrieval operation named in the capability guide to update your interface. Apply bounded polling and show a pending state until the required result is observed. See [asynchronous state](/neuron-api/events-and-asynchronous-state). If a write times out, retrieve the known object or reconcile with the provider before submitting it again. An absent response does not prove the operation failed. ## 5. Verify the application flow Check that your interface shows the intended account and object, handles expired sessions, and distinguishes pending work from success or failure. Exercise a rejected request and an unavailable service as well as the successful sequence. Your first integration is complete when a user can perform the chosen action, see its confirmed result, and return later to the same object. # What can I build with Neuro? Source: https://docs.neuro-tech.io/get-started/what-can-i-build Connect application ideas to identity, agreements, tokens, payments, and audit history Neuro provides building blocks for applications that need to know who acted, what they agreed to, what an asset represents, and how its state changed. Your application connects through the Agent API. ## Match your idea to a capability | Application need | Relevant capabilities | Guide | | ------------------------------------------ | -------------------------------------------------------- | -------------------------------------------------------- | | Reviewed customer or organization identity | Accounts, keys, Legal Identities | [Verify an identity](/build/verified-identity/overview) | | User sign-in | Existing account and supported session flow | [Sign in with Neuro](/build/sign-in-with-neuro/overview) | | Agreement between participants | Human-readable terms, roles, parameters, signatures | [Create an agreement](/contracts/quickstart) | | Digital certificate or asset record | Token creation contract and identity-backed participants | [Build with tokens](/build/tokenized-assets/overview) | | Asset behavior triggered by events | Token state machine, actions, Script, and history | [State machines](/contracts/state-machines) | | Value and transaction status | Wallets and supported payment services | [Payments](/build/payments/overview) | | Messages between participants | Agent API messaging and observable results | [Send messages](/neuron-api/guides/messaging) | ## Get a first result [Make your first API request](/neuron-api/first-request) using an existing account. If you need credentials, start with [API access](/get-started/api-access). The [Build task index](/build/overview) then connects each outcome to its prerequisites. Custom contracts and tokens can require XML and Script. The [Resources tab](/resources/overview) provides the schemas, examples, and language reference as you need them. # Neuro developer overview Source: https://docs.neuro-tech.io/index Understand Neuro and build applications with the Agent API Neuro gives applications reviewed identities, signed agreements, digital assets, payments, and auditable history. Your application uses the **Agent API over HTTPS** on an existing Neuron. “Agent API” is the product name; it does not mean an API only for artificial intelligence. Use an API key to create an account and an automatically approved test identity over HTTPS. Start with [API access](/get-started/api-access) if you need an endpoint and credentials. You can make the first request before learning contracts, tokens, or payments. ## Understand how Neuro fits together ```mermaid theme={null} flowchart LR User[Your user] --> App[Your application] App --> Backend[Application backend] Backend --> API[HTTPS Agent API] API --> Neuron[Neuron] Neuron --> Services[Identity, contracts, tokens, payments] Services --> History[Auditable history] ``` A **Neuron** is the service your account belongs to. It exposes the Agent API and communicates with the trust services enabled for that environment. Your provider supplies its address and supported capabilities. | Concept | What it means for your application | | -------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- | | [Account and Legal Identity](/concepts/accounts-and-identities) | An account provides access; a reviewed identity connects actions to a person or organization. | | [Keys and signatures](/concepts/keys-and-signatures) | Cryptographic evidence authorizes actions and identifies signers. | | [Smart contract](/concepts/smart-contracts) | Human-readable terms, machine-readable XML, parameters, roles, and signatures describe an agreement. | | [Token / Neuro-Feature](/concepts/neuro-features-and-state-machines) | A contract-created asset or right, optionally with an executable state machine. | | [Wallets and payments](/concepts/wallets-and-payments) | Value and transaction workflows available through the configured provider. | | [Neuro-Ledger](/neuro-ledger/overview) | Auditable records of selected object changes. | Each application uses only the capabilities it needs. A first account request does not require a Legal Identity. Creating a token requires a creation contract and its required participants. Learn how identities, agreements, assets, and trust relate. Find the capabilities and prerequisites for your application. ## Build with the Agent API Use [Build](/build/overview) for complete application tasks and [Agent API reference](/neuron-api/api-reference/overview) for exact request fields. The [Resources](/resources/overview) tab provides schemas, Script reference, and LegalLab examples when your application needs custom contract or token behavior. # Agent Things API availability Source: https://docs.neuro-tech.io/iot/agent-things-api Check the application-facing device operations supported by your Neuron Device integration requires more than successful account authentication. Your provider must expose the relevant device capabilities and authorize the application to use them. The current HTTP reference does not yet define a complete device readout workflow with verified request and response shapes. Confirm that workflow with your provider before treating an existing device helper or protocol example as a runnable Agent API integration. ## Prepare the device context Record the device identifier and, for a concentrator node, its source ID, node ID, and optional partition. Determine the fields, units, timestamps, and quality flags your application needs. For asynchronous data, confirm how your application receives fragments, detects completion, handles errors, and cancels abandoned requests. Do not infer those behaviors from a generic account or messaging response. Start with [IoT concepts](/iot/overview), [the device model](/iot/device-model), and [harmonized interfaces](/iot/harmonized-interfaces). Use only exact HTTP operations your provider documents for the selected build. # IoT device model Source: https://docs.neuro-tech.io/iot/device-model Map things, identities, sources, nodes, sensors, actuators, and operations ## Concepts | Concept | Meaning | | ------------------- | ---------------------------------------------------------------------- | | Thing/entity | A physical device, virtual device, service, or application | | Network identity | Address used to communicate, normally an XMPP JID | | Conceptual identity | Persistent identity of the thing independent of a connection | | Data source | A named source tree exposed by a concentrator | | Node | A physical or virtual item inside a data source | | Partition | Optional discriminator when node IDs are reused in separate partitions | | Sensor | Exposes read-only fields over time | | Actuator | Exposes writable, typed control parameters/actions | | Concentrator | One network identity that contains many sources/nodes | A standalone device uses its JID as the address for sensor/control operations. A concentrator operation adds source ID, node ID, and optional partition. ## Capability discovery Query capabilities before calling an interface. A concentrator can expose sensor data, control, node management, commands, queries, events, and troubleshooting features independently. ## Extended addressing Use this tuple as a stable node address inside a concentrator: ```text theme={null} (Concentrator JID, Source ID, Node ID, optional Partition) ``` Node display names and positions are not identifiers. Persist the full tuple and be prepared for a node-moved event. ## Harmonized interfaces Basic sensor and control models enable human UIs. Harmonized interfaces add agreed machine semantics for a use case. A device advertises the qualified interface identifiers it supports, allowing cross-vendor applications to interpret data without model-specific code. ## Bridge pattern A protocol bridge maps Modbus, MQTT, HTTP, GPIO, files, or another local technology into this model: ```text theme={null} Protocol device -> bridge node -> sensor/control interface -> XMPP federation ``` Keep protocol-specific identifiers as metadata, while exposing stable Neuro source/node IDs to clients. # Harmonized interfaces Source: https://docs.neuro-tech.io/iot/harmonized-interfaces Understand shared meanings for device fields and control parameters A harmonized interface defines what a set of device values means. It lets applications interpret a capability consistently across different device implementations. ## Interface identity An interface has a versioned URI. Applications must compare the exact identifier and supported version instead of guessing from a model name. A temperature interface, for example, identifies a shared interpretation of temperature fields and their required metadata. A device can implement a base interface and optional extensions. Aggregate interfaces add shared behavior, such as statistical values, to a base capability. Support for an interface does not by itself grant permission to read or control the device. ## Application responsibilities * Check the interfaces and versions available through the provider's supported API. * Retain units, timestamps, quality information, and node identity with values. * Require the base capability before using one of its extensions. * Handle unknown interface identifiers without interpreting them as a familiar version. Use the [device model](/iot/device-model) for addressing concepts and [Agent Things API availability](/iot/agent-things-api) before implementing a device workflow. # IoT application concepts Source: https://docs.neuro-tech.io/iot/overview Understand devices, sensor data, control, and permissions in a Neuro application Neuro's IoT model describes devices, their sensor data, and the actions applications can request. Shared representations help applications interpret data across different device implementations. Start with the [device model](/iot/device-model), [units](/iot/units), and [harmonized interfaces](/iot/harmonized-interfaces). Access to device data or control remains subject to the device's ownership and authorization rules. Applications use the [Agent Things API](/iot/agent-things-api) where that capability is available on their Neuron. Confirm its exact operations and permissions with your provider before writing integration code. The main Agent API quickstart alone does not establish device access. # Units and conversion Source: https://docs.neuro-tech.io/iot/units Represent measurable quantities and convert compatible base, derived, and compound units The unit model makes sensor values readable by people and convertible by software, including linear, non-linear, derived, and compound units. | Item | Value | | ---------------- | --------------------------------------------------------------------- | | Namespace | `urn:nfi:iot:u:1.0` | | Definition model | Unit categories with one reference unit and zero or more alternatives | ## Model A **unit category** groups compatible units representing the same measurable quantity. It has exactly one reference unit—normally an SI unit or a unit with a derivation to SI. A regular **unit** defines reversible Reverse Polish Notation (RPN) operations that map its value to the category reference unit. A **compound unit** is a numeric factor multiplied by unit factors raised to integer exponents. Units without conversion operations are equivalent to their category reference unit. ```mermaid theme={null} flowchart LR V[Input value + unit] --> P[Apply input prefix] P --> R[Convert to category reference] R --> T[Convert reference to target] T --> O[Choose output prefix and precision] ``` ## Conversion algorithm 1. Look up both units and verify that their reduced dimensions/categories are compatible. 2. Apply any source prefix before evaluating unit operations. 3. Push the source value on the stack and evaluate its RPN operations top-to-bottom to reach the reference unit. 4. Evaluate the target operations in reverse, using the inverse of each operation, to leave the reference unit. 5. Apply a suitable target prefix and rounding policy. The operation set includes constants and reversible arithmetic such as number, π, add, subtract, multiply, divide, power, logarithm, and negation. An implementation must reject an invalid stack program, a non-invertible conversion, or incompatible dimensions. ## Compound units Reduce each factor recursively into a numeric multiplier and base-unit exponent map. Compatible compound units have the same normalized exponent map. ```text theme={null} N = kg·m·s⁻² Pa = N·m⁻² = kg·m⁻¹·s⁻² ``` Do not compare display strings to test compatibility. Normalize definitions and dimensions instead. ## Sensor implementation rules * Send a stable unit symbol with every quantity field for which magnitude depends on a unit. * Preserve significant digits and quality metadata during conversion. * Keep raw readings when a converted value will be used for audit or billing. * Accept an unknown unit as a value you can display or store, but do not invent a conversion. * Reject incompatible control inputs before changing device state. # Scopes and permissions Source: https://docs.neuro-tech.io/mcp/authentication-and-authorization Choose OAuth scopes and identify the role privileges required by MCP tools, resources, and prompts To use a hosted MCP server, you need an accepted account or client registration, authorized access, and the privileges for your intended actions. ## Scopes and role privileges These names serve different purposes: | Setting | Example | Purpose | | -------------- | ------------------------------------ | -------------------------------------------------------------- | | OAuth scope | `MCP:Files:Tools` | Identifies a category of capabilities requested by the client. | | Role privilege | `OAUTH.Scope.MCP.Files.Tools.Create` | Controls access to an operation, in this case creating files. | Each individual server advertises scope categories ending in `:Tools`, `:Resources`, and `:Prompts`. The [server reference](/mcp/servers/overview) lists the exact names and operation privileges. An advertised category does not guarantee that a server provides custom resources or prompts. The provider must authorize the requested categories and the operation privileges. Successful OAuth registration or sign-in alone does not grant these permissions. The server checks category access as well as operation access; ask the operator to verify both in the effective role. Use the scope names advertised by your endpoint. Do not construct a scope by changing the punctuation in an operation privilege and assume the server accepts it. ## Request access for a task 1. Choose the individual server and the operations your application needs. 2. Request the corresponding advertised scope categories in the client's OAuth settings, when the client exposes this setting. 3. Give the operator the required operation privileges from that server's reference. 4. Connect and discover tools, resources, or prompts. Verify that the intended action is available to the session. For example, to list and read stored files, use `/MCP/Files` and request `MCP:Files:Resources`. Ask the operator to verify resource-category access and these operation privileges: ```text theme={null} OAUTH.Scope.MCP.Files.Resources.List OAUTH.Scope.MCP.Files.Resources.Read ``` If you also need to create files, request the tools category and the creation privilege shown in the [File Storage reference](/mcp/servers/file-storage). Choose permissions for the actual task; a tools scope is not a read-only setting. ## Tools, resources, and prompts * **Tools** perform actions. Several tools can share a privilege, including tools with different side effects. Check the complete group before requesting access. * **Resources** expose data through returned URIs. Listing, reading, and subscribing can require different privileges. * **Prompts** provide a guided interaction. Access to a prompt does not automatically authorize the tools needed to complete its steps. Some operations require multiple privileges; their reference rows list all of them. A combined `/MCP` connection retains the requirements of its constituent servers. ## Account and identity requirements Messaging, identity, and payment tools also need a connected Neuron account. Approval of a Legal Identity is a separate requirement for operations that use it. Neither sandbox account enablement nor automatic sandbox identity approval assigns an MCP role. [Agent API credentials](/neuron-api/authentication) belong to that API's authentication flow. Use the hosted MCP server's supported OAuth or other provider-specified authentication method. The local [NeuroAli STDIO connection](/mcp/neuroali) uses a different access model. ## Diagnose missing access | Symptom | Next step | | ------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------- | | Client registered but capabilities are denied | Ask the operator to confirm that a role was assigned to the registered account. | | Sign-in succeeds but discovery or a call is denied | Check both category access and the operation privileges against the server reference. | | An expected tool is missing | Confirm the endpoint and provider's deployed capabilities, then check permissions. | | A tool requests account details, identity information, or approval | Complete the application prerequisite reported by the tool. OAuth access alone cannot satisfy it. | See the [original Neuron MCP connection guide](https://lab.tagroot.io/Community/Post/Connecting_an_MCP_Client_to_MCP_Servers_on_a_Neuron) for registration and role requirements. Continue with [Connect to a Neuron](/mcp/quickstart). # Use NeuroAli Source: https://docs.neuro-tech.io/mcp/neuroali Connect a compatible MCP client to NeuroAli as a local STDIO process [NeuroAli](https://github.com/Trust-Anchor-Group/NeuroAli) is a local MCP server for Neuro services. It brings content, event logs, files, messaging, identities, contracts, and payments into one process. Use it when your MCP client supports launching a local server with the **STDIO** transport. Your client communicates with the process through standard input and output. ## What you need * Git and the .NET 8 SDK to build the project. * A client that can launch a local STDIO MCP server. * A writable working directory for NeuroAli's local data and logs. * The Neuron host and account access required by the tools you plan to use. ## 1. Clone and build ```bash theme={null} git clone https://github.com/Trust-Anchor-Group/NeuroAli.git cd NeuroAli dotnet publish NeuroAli.csproj --configuration Release --output artifacts/neuroali ``` The output directory contains `NeuroAli.dll` and its dependencies. Keep these files together. The project targets .NET 8; the machine running it needs the corresponding runtime. ## 2. Configure the client Add a local MCP server using these settings: | Setting | Value | | ----------------- | -------------------------------------------------------------------------------- | | Transport | STDIO. | | Command | `dotnet` or its absolute path. | | Argument | The absolute path to `artifacts/neuroali/NeuroAli.dll`. Pass it as one argument. | | Working directory | A writable local directory whose data you want to retain. | Let the client launch and manage the process. List its tools to check the connection, then complete any account setup requested by the tool you want to use. The local STDIO connection does not use the hosted Neuron OAuth connection profile. Its tools still need the relevant Neuron account and identity permissions. ## Local HTTP option NeuroAli also starts an HTTP server on port `8080` by default. A client on the same machine can use Streamable HTTP at `http://localhost:8080/MCP`, or one of the individual paths in the [server list](/mcp/servers/overview). Keep access to this local service restricted to the intended machine and client. The [NeuroAli README](https://github.com/Trust-Anchor-Group/NeuroAli#readme) describes its data directories and local interfaces. For a provider-hosted connection, follow [Connect to a Neuron](/mcp/quickstart). # MCP overview Source: https://docs.neuro-tech.io/mcp/overview Connect an AI application to Neuro tools through the Model Context Protocol Model Context Protocol (MCP) lets an AI application discover and use tools provided by a server. Neuro exposes MCP servers for files, Internet content, messaging, identities, contracts, and payments. Your AI application acts as the **MCP client**. It connects to a server, authenticates when required, and discovers the tools available to it. ## Choose a connection | Option | Use it when | What you need | | ------------------------------------- | ---------------------------------------------------- | ------------------------------------------------------------------------------------- | | [Neuron MCP servers](/mcp/quickstart) | Your provider hosts the capabilities you need. | A compatible client, an HTTPS endpoint, and an account with the required permissions. | | [NeuroAli](/mcp/neuroali) | Your client launches a local MCP process over STDIO. | A local NeuroAli build and the Neuron account access needed by its tools. | Start with [Connect to a Neuron](/mcp/quickstart), then choose from the [server list](/mcp/servers/overview). Server availability and permitted tools depend on your provider. Each server reference lists its tools, resources, prompts, and required access. Use [Scopes and permissions](/mcp/authentication-and-authorization) to request the capabilities your application needs. ## MCP and the Agent API Use the [Agent API](/neuron-api/quickstart) when your application constructs HTTP requests directly. Use MCP when your AI application consumes discovered tools. The underlying identity, contract, and payment requirements still apply. A successful tool call can start work that needs approval, signatures, or further processing. Check the returned state before reporting completion, and obtain the user's confirmation before signing a contract or initiating a payment. ## Documentation MCP The [documentation MCP server](/developer-tools/agent-tools) helps a coding agent search these docs. It is separate from the Neuron servers that perform application actions. # Connect to a Neuron Source: https://docs.neuro-tech.io/mcp/quickstart Get MCP access, configure the connection, and discover the tools your account can use Connect your MCP client to an existing Neuron using the endpoint and access supplied by its operator. ## What you need * An MCP client supporting **Streamable HTTP** and the authentication method offered by your provider, usually OAuth 2.0. * The exact HTTPS server URL, such as `https:///MCP/Files`. * An account or OAuth client registration accepted by that Neuron. * A role granting the privileges for the tools you want to use, plus the corresponding OAuth scopes. Ask the operator for the endpoint, registration method, sign-in details, and required permissions. If registration is manual, also obtain the client identifier and any required client credentials. ## 1. Obtain access Your provider can arrange access using an existing Neuron user or XMPP account, or support dynamic OAuth client registration. Dynamic registration creates an account for the client, but **does not grant MCP privileges by default**. The operator must assign the appropriate role before the client can use protected capabilities. Registering again will not fix missing permissions. If you already completed the [Agent API sandbox quickstart](/neuron-api/quickstart), confirm MCP access separately with the operator. Account enablement and sandbox identity approval do not establish an MCP role. This registration-and-role sequence is described in the [Neuron MCP connection guide](https://lab.tagroot.io/Community/Post/Connecting_an_MCP_Client_to_MCP_Servers_on_a_Neuron). ## 2. Configure your client Use your client's generic server-connection settings: | Setting | Value | | ------------------- | ---------------------------------------------------------------------------------------------------------------------- | | Server URL | The full HTTPS endpoint supplied by the operator. | | Transport | Streamable HTTP. | | Authentication | OAuth 2.0, or another method explicitly supported by the provider. | | Client registration | The method supported by both the client and provider. | | Scopes | The advertised categories required for your task; see [Scopes and permissions](/mcp/authentication-and-authorization). | Use a specific endpoint for one capability, or the combined `/MCP` endpoint when your provider exposes it. See [MCP servers](/mcp/servers/overview). ## 3. Sign in and authorize Let your client discover the server's OAuth settings and complete sign-in. Review the requested permissions before approving them. Keep credentials in the client's protected credential storage. MCP authorization is separate from the [Agent API login signature](/neuron-api/authentication). Use the MCP server's advertised authentication flow instead of copying an Agent API JWT or account-creation key into the connection. ## 4. Check the connection Ask the client to list the server's tools. A successful connection returns the tools available to that session. Start with a permitted read operation, such as listing files or reading a known resource. Identity, messaging, and payment tools can require an associated Neuron account or additional user input. Follow the tool's request for those details; connecting the MCP session alone does not create an approved identity or fund a wallet. ## If a step fails | Problem | Check | | ---------------------------------------------------- | --------------------------------------------------------------------------------- | | Endpoint unavailable | Confirm the exact URL and that the provider exposes that server. | | Registration fails | Confirm the supported registration method; ask for manual registration if needed. | | Sign-in succeeds but a tool is unavailable or denied | Have the operator check the account's role and requested scopes. | | A tool asks for account or identity setup | Complete the prerequisite reported by that tool, then retry the intended action. | Continue with the [server references](/mcp/servers/overview) for each server's scopes, operation privileges, tools, resources, and prompts. # Event Log Source: https://docs.neuro-tech.io/mcp/servers/event-log Record application events and search the event logs your account can access. Record application events and search the event logs your account can access. **Endpoint:** `https:///MCP/EventLog`. Use the host supplied by your provider. ## What you need You need the relevant logging or search privileges. Use a severity appropriate to the event: alert and emergency events notify operators immediately. ## Scopes and privileges The server advertises these OAuth scopes: ```text theme={null} MCP:EventLog:Tools MCP:EventLog:Prompts MCP:EventLog:Resources ``` Request the categories you need. The provider must also grant the corresponding role privileges; see [Scopes and permissions](/mcp/authentication-and-authorization). For the tables below, prepend `OAUTH.Scope.MCP.EventLog.` to each suffix. When a row lists multiple privileges, all are required. For example, `OAUTH.Scope.MCP.EventLog.Tools.Log.Alert` is a complete privilege name. ## Tools Select a tool name for its complete arguments, defaults, and return values in the original reference. Discover tools in your client to check what your session can use. | Tool | Required privilege suffix | | ----------------------------------------------------------------------------- | ------------------------- | | [LogAlert](https://lab.tagroot.io/MCP/EventLog#logAlertEvent) | `Tools.Log.Alert` | | [LogCritical](https://lab.tagroot.io/MCP/EventLog#logCriticalErrorEvent) | `Tools.Log.Critical` | | [LogDebug](https://lab.tagroot.io/MCP/EventLog#logDebugEvent) | `Tools.Log.Debug` | | [LogEmergency](https://lab.tagroot.io/MCP/EventLog#logEmergencyEvent) | `Tools.Log.Emergency` | | [LogError](https://lab.tagroot.io/MCP/EventLog#logErrorEvent) | `Tools.Log.Error` | | [LogInformational](https://lab.tagroot.io/MCP/EventLog#logInformationalEvent) | `Tools.Log.Information` | | [LogNotice](https://lab.tagroot.io/MCP/EventLog#logNoticeEvent) | `Tools.Log.Notice` | | [LogWarning](https://lab.tagroot.io/MCP/EventLog#logWarningEvent) | `Tools.Log.Warning` | | [Search](https://lab.tagroot.io/MCP/EventLog#searchForEvents) | `Tools.Search` | ## Use this server Use `Search` to filter by time, message, actor, event identifier, or severity. Use `Offset` and `MaxCount` to page through results. Logging tools accept `Message` and optional context such as `Object`, `Actor`, `Level`, `EventId`, `Facility`, and `Module`. ## Resources and prompts No custom resources are documented. The `FindSensitiveInformation` prompt guides a review of logs; its arguments select what to look for and whether to propose edits or deletion. Review these options before using it. | Prompt | Required privilege suffix | | ---------------------------------------------------------------------------------------- | --------------------------- | | [FindSensitiveInformation](https://lab.tagroot.io/MCP/EventLog#findSensitiveInformation) | `Prompts.FindSensitiveInfo` | See the [original Event Log reference](https://lab.tagroot.io/MCP/EventLog) for complete schemas and response types, or return to [MCP servers](/mcp/servers/overview). # File Storage Source: https://docs.neuro-tech.io/mcp/servers/file-storage Keep files for later use by your MCP client in persistent, account-specific storage. Keep files for later use by your MCP client in persistent, account-specific storage. **Endpoint:** `https:///MCP/Files`. Use the host supplied by your provider. ## What you need You need file resource permissions to list or read files, and the corresponding tool privileges to create or change them. File URIs belong to the account storage and are not shared download links. ## Scopes and privileges The server advertises these OAuth scopes: ```text theme={null} MCP:Files:Tools MCP:Files:Prompts MCP:Files:Resources ``` Request the categories you need. The provider must also grant the corresponding role privileges; see [Scopes and permissions](/mcp/authentication-and-authorization). For the tables below, prepend `OAUTH.Scope.MCP.Files.` to each suffix. When a row lists multiple privileges, all are required. For example, `OAUTH.Scope.MCP.Files.Tools.Append` is a complete privilege name. ## Tools Select a tool name for its complete arguments, defaults, and return values in the original reference. Discover tools in your client to check what your session can use. | Tool | Required privilege suffix | | --------------------------------------------------------------------- | ------------------------- | | [AppendBinaryFile](https://lab.tagroot.io/MCP/Files#appendBinaryFile) | `Tools.Append` | | [AppendTextFile](https://lab.tagroot.io/MCP/Files#appendTextFile) | `Tools.Append` | | [CreateBinaryFile](https://lab.tagroot.io/MCP/Files#createBinaryFile) | `Tools.Create` | | [CreateTextFile](https://lab.tagroot.io/MCP/Files#createTextFile) | `Tools.Create` | | [DeleteFile](https://lab.tagroot.io/MCP/Files#deleteFile) | `Tools.Delete` | | [EditFile](https://lab.tagroot.io/MCP/Files#edit) | `Tools.Edit` | | [SearchFiles](https://lab.tagroot.io/MCP/Files#search) | `Tools.Search` | | [UpdateBinaryFile](https://lab.tagroot.io/MCP/Files#updateBinaryFile) | `Tools.Update` | | [UpdateTextFile](https://lab.tagroot.io/MCP/Files#updateTextFile) | `Tools.Update` | ## Use this server List resources and read a returned URI to inspect an existing file. To create a text file, call `CreateTextFile` with `LocalFileName`, `Content`, and `AppendCrLf`. It returns a resource URI and replaces an existing file with the same name. Binary tools take Base64 content. File names must stay within the storage area: do not use `..` or a leading path separator. For `EditFile`, set `Sensitive` to `true` when editing requires a protected window. ## Resources and prompts Each resource represents a stored file. Subscriptions report file changes. No custom prompts are documented. | Resource operation | Required privilege suffix | | --------------------------------------------------------------------------------- | ------------------------- | | [resources/list](https://lab.tagroot.io/MCP/Files#ResourcesListCursor) | `Resources.List` | | [resources/read](https://lab.tagroot.io/MCP/Files#ResourcesReadUriMeta) | `Resources.Read` | | [resources/subscribe](https://lab.tagroot.io/MCP/Files#ResourcesSubscribeUri) | `Resources.List` | | [resources/unsubscribe](https://lab.tagroot.io/MCP/Files#ResourcesUnsubscribeUri) | `Resources.List` | See the [original File Storage reference](https://lab.tagroot.io/MCP/Files) for complete schemas and response types, or return to [MCP servers](/mcp/servers/overview). # Identity and contracts Source: https://docs.neuro-tech.io/mcp/servers/identity Apply for Legal Identities, request access to identity and contract information, and create or sign contracts from templates. Apply for Legal Identities, request access to identity and contract information, and create or sign contracts from templates. **Endpoint:** `https:///MCP/Identity`. Use the host supplied by your provider. ## What you need You need a connected Neuron account. Identity applications require the personal information and attachments requested by the provider. Your client must support requests for user input (elicitation) for tools that collect these details interactively. ## Scopes and privileges The server advertises these OAuth scopes: ```text theme={null} MCP:Identity:Tools MCP:Identity:Prompts MCP:Identity:Resources ``` Request the categories you need. The provider must also grant the corresponding role privileges; see [Scopes and permissions](/mcp/authentication-and-authorization). For the tables below, prepend `OAUTH.Scope.MCP.Identity.` to each suffix. When a row lists multiple privileges, all are required. For example, `OAUTH.Scope.MCP.Identity.Tools.Attachment.Add` is a complete privilege name. ## Tools Select a tool name for its complete arguments, defaults, and return values in the original reference. Discover tools in your client to check what your session can use. | Tool | Required privilege suffix | | -------------------------------------------------------------------------------------------------------- | --------------------------- | | [AddPhotoAttachmentBase64Upload](https://lab.tagroot.io/MCP/Identity#addPhotoAttachmentBase64Upload) | `Tools.Attachment.Add` | | [AddPhotoAttachmentElicitation](https://lab.tagroot.io/MCP/Identity#addPhotoAttachmentUserInput) | `Tools.Attachment.Add` | | [AddPhotoAttachmentUrlDownload](https://lab.tagroot.io/MCP/Identity#addPhotoAttachmentUrlDownload) | `Tools.Attachment.Add` | | [ApplyForNewPersonalIdentity](https://lab.tagroot.io/MCP/Identity#applyForNewPersonalIdentity) | `Tools.Apply` | | [CompromiseIdentity](https://lab.tagroot.io/MCP/Identity#compromiseIdentity) | `Tools.Compromise` | | [CreateOpenContract](https://lab.tagroot.io/MCP/Identity#createOpenSmartContract) | `Tools.Contract.Create` | | [GetIdentityApplicationProperties](https://lab.tagroot.io/MCP/Identity#getIdentityApplicationProperties) | `Tools.Apply` | | [GetPeerReviewProviders](https://lab.tagroot.io/MCP/Identity#getPeerReviewProviders) | `Tools.Petition.PeerReview` | | [ObsoleteIdentity](https://lab.tagroot.io/MCP/Identity#obsoleteIdentity) | `Tools.Obsolete` | | [PetitionLegalIdentity](https://lab.tagroot.io/MCP/Identity#petitionLegalIdentity) | `Tools.Petition.Identity` | | [PetitionPeerReview](https://lab.tagroot.io/MCP/Identity#petitionPeerReview) | `Tools.Petition.PeerReview` | | [PetitionSignature](https://lab.tagroot.io/MCP/Identity#petitionDigitalSignature) | `Tools.Petition.Signature` | | [PetitionSmartContract](https://lab.tagroot.io/MCP/Identity#petitionSmartContract) | `Tools.Petition.Contract` | | [ProposeContract](https://lab.tagroot.io/MCP/Identity#proposeSmartContract) | `Tools.Contract.Propose` | | [ReadyForApproval](https://lab.tagroot.io/MCP/Identity#readyForApprovalIdentity) | `Tools.ReadyForApproval` | | [RemoveAttachment](https://lab.tagroot.io/MCP/Identity#removeAttachment) | `Tools.Attachment.Remove` | | [SelectPeerReviewProvider](https://lab.tagroot.io/MCP/Identity#selectPeerReviewProvider) | `Tools.Petition.PeerReview` | | [SignContract](https://lab.tagroot.io/MCP/Identity#signSmartContract) | `Tools.Contract.Sign` | ## Use this server For an identity application, get the application properties, apply for a personal identity, add the required attachments, and mark it ready for approval. `ReadyForApproval` submits readiness; approval is a separate provider decision. For a contract, supply an existing `TemplateId` and its `Parameters` to `CreateOpenContract`. Use the resulting contract identifier to propose it to a party or sign a role. `ProposeContract` sends an existing contract proposal; for XML template authoring, follow [Create a contract from scratch](/contracts/from-scratch). Review the contract and obtain the user's confirmation before signing. ## Resources and prompts Resources expose identities, requested contracts, and templates you have used. Check their state and validity before using them. The prompts guide identity creation and peer review; tool permissions are still needed to carry out their steps. | Resource operation | Required privilege suffix | | ------------------------------------------------------------------------------------ | ------------------------- | | [resources/list](https://lab.tagroot.io/MCP/Identity#ResourcesListCursor) | `Resources.List` | | [resources/read](https://lab.tagroot.io/MCP/Identity#ResourcesReadUriMeta) | `Resources.Read` | | [resources/subscribe](https://lab.tagroot.io/MCP/Identity#ResourcesSubscribeUri) | `Resources.List` | | [resources/unsubscribe](https://lab.tagroot.io/MCP/Identity#ResourcesUnsubscribeUri) | `Resources.List` | | Prompt | Required privilege suffix | | ---------------------------------------------------------------------------------------------- | ------------------------------------------------------------------ | | [CreatePersonalLegalIdentity](https://lab.tagroot.io/MCP/Identity#createPersonalLegalIdentity) | `Prompts.Create.Create.PersonalId` | | [RequestPeerReview](https://lab.tagroot.io/MCP/Identity#requestPeerReview) | `Prompts.Create.Create.PersonalId` and `Tools.Petition.PeerReview` | See the [original Identity and contracts reference](https://lab.tagroot.io/MCP/Identity) for complete schemas and response types, or return to [MCP servers](/mcp/servers/overview). # Internet Content Source: https://docs.neuro-tech.io/mcp/servers/internet-content Retrieve content or send HTTP requests through MCP. Retrieve content or send HTTP requests through MCP. **Endpoint:** `https:///MCP/Content`. Use the host supplied by your provider. ## What you need You need access to this server and any authorization required by the destination. Requests originate from the server; they can use its certificate for mutual TLS when available. ## Scopes and privileges The server advertises these OAuth scopes: ```text theme={null} MCP:InternetContent:Tools MCP:InternetContent:Prompts MCP:InternetContent:Resources ``` Request the categories you need. The provider must also grant the corresponding role privileges; see [Scopes and permissions](/mcp/authentication-and-authorization). For the tables below, prepend `OAUTH.Scope.MCP.InternetContent.` to each suffix. When a row lists multiple privileges, all are required. For example, `OAUTH.Scope.MCP.InternetContent.Tools.Delete` is a complete privilege name. ## Tools Select a tool name for its complete arguments, defaults, and return values in the original reference. Discover tools in your client to check what your session can use. | Tool | Required privilege suffix | | --------------------------------------------------- | ------------------------- | | [Delete](https://lab.tagroot.io/MCP/Content#delete) | `Tools.Delete` | | [Get](https://lab.tagroot.io/MCP/Content#get) | `Tools.Get` | | [Post](https://lab.tagroot.io/MCP/Content#post) | `Tools.Post` | | [Put](https://lab.tagroot.io/MCP/Content#put) | `Tools.Put` | | [Query](https://lab.tagroot.io/MCP/Content#query) | `Tools.Query` | ## Use this server Use `Get` with a known `Uri` to retrieve content. `Post`, `Put`, and `Query` also accept `Payload`. Optional settings include `Accept`, `AcceptLanguage`, `AdditionalHeaders`, and `Timeout` in milliseconds (default `30000`, maximum `60000`). Review the destination and payload before a request that changes remote data. ## Resources and prompts This server does not document custom resources or prompts. Discover its tools to work with content. See the [original Internet Content reference](https://lab.tagroot.io/MCP/Content) for complete schemas and response types, or return to [MCP servers](/mcp/servers/overview). # Combined server Source: https://docs.neuro-tech.io/mcp/servers/joined Use one MCP connection for the servers available on your Neuron The combined server joins the capabilities registered on a Neuron into one MCP endpoint. **Endpoint:** `https:///MCP`. Use the host supplied by your provider. ## What it includes The [original combined-server reference](https://lab.tagroot.io/MCP) brings together Internet Content, Event Log, File Storage, XMPP, Identity, and Payments. Your provider's selection can differ; discover the tools, resources, and prompts exposed by your endpoint. Use this endpoint when an application needs several capabilities in one connection. Use an [individual server](/mcp/servers/overview) when it needs a smaller set of tools. ## Scopes and privileges Follow your endpoint's advertised authorization settings. Use the individual server references to identify the categories and operation privileges needed for each task. Connecting to `/MCP` does not grant additional access or remove account, identity, or wallet prerequisites. For example, an application that reads files and checks a wallet balance needs the File Storage resource permissions and the Payments balance permission. Check both sets with your provider using [Scopes and permissions](/mcp/authentication-and-authorization). ## Connect and discover Follow [Connect to a Neuron](/mcp/quickstart) with `/MCP` as the endpoint. After sign-in, list the available capabilities and use their returned names, input schemas, and resource URIs. For a local process exposing these capabilities over STDIO, follow [Use NeuroAli](/mcp/neuroali). # MCP servers Source: https://docs.neuro-tech.io/mcp/servers/overview Choose the Neuron MCP endpoint for the capabilities your application needs A Neuron can publish the following MCP endpoints. Confirm which ones your provider enables, then use your client's tool discovery to see the available operations. Prefix each path with your Neuron's HTTPS host, for example `https:///MCP/Identity`. | Server | Endpoint | What it provides | | -------------------------------------------------- | --------------- | ------------------------------------------------------------------------------------- | | [Combined](/mcp/servers/joined) | `/MCP` | The capabilities of the MCP servers registered on that Neuron through one connection. | | [Internet Content](/mcp/servers/internet-content) | `/MCP/Content` | Retrieve and work with Internet content. | | [Event Log](/mcp/servers/event-log) | `/MCP/EventLog` | Write events and search accessible event logs. | | [File Storage](/mcp/servers/file-storage) | `/MCP/Files` | Store, list, read, and manage files. | | [Messaging and contacts (XMPP)](/mcp/servers/xmpp) | `/MCP/XMPP` | Connect an account and work with messaging and contacts through MCP tools. | | [Identity and contracts](/mcp/servers/identity) | `/MCP/Identity` | Apply for Legal Identities and create, propose, and sign contracts from templates. | | [Payments](/mcp/servers/payments) | `/MCP/Payments` | Work with an eDaler wallet and supported payment operations. | Use the combined endpoint for one connection to available capabilities, or an individual endpoint for a smaller tool set. Each server page lists its scopes, required privileges, tools, resources, and prompts, with links to complete operation arguments in the [original MCP documentation](https://lab.tagroot.io/Documentation/Index.md). ## Requirements by capability All protected operations require the role and permissions described in [Scopes and permissions](/mcp/authentication-and-authorization). A combined connection does not grant additional permissions. * **Messaging:** an account the MCP server can connect on your behalf. * **Identity and contracts:** account access, identity approval where required, and the parties, roles, and templates needed by the contract. * **Payments:** a connected account and Legal Identity, plus the balance or payment-provider setup needed for the operation. The MCP server manages the underlying protocol connection. Your application uses MCP tools to perform these tasks. For the objects and lifecycle behind the tools, see [Legal Identities](/concepts/accounts-and-identities), [contracts](/contracts/overview), and [wallets and payments](/concepts/wallets-and-payments). # Payments MCP server Source: https://docs.neuro-tech.io/mcp/servers/payments Inspect an eDaler wallet, request payments, and transfer value through MCP. Inspect an eDaler wallet, request payments, and transfer value through MCP. **Endpoint:** `https:///MCP/Payments`. Use the host supplied by your provider. ## What you need You need a connected account and an approved Legal Identity containing the required personal information. Transfers also need sufficient balance; buying or selling eDaler requires a supported service provider. ## Scopes and privileges The server advertises these OAuth scopes: ```text theme={null} MCP:Payments:Tools MCP:Payments:Prompts MCP:Payments:Resources ``` Request the categories you need. The provider must also grant the corresponding role privileges; see [Scopes and permissions](/mcp/authentication-and-authorization). For the tables below, prepend `OAUTH.Scope.MCP.Payments.` to each suffix. When a row lists multiple privileges, all are required. For example, `OAUTH.Scope.MCP.Payments.Tools.EDaler.Buy` is a complete privilege name. ## Tools Select a tool name for its complete arguments, defaults, and return values in the original reference. Discover tools in your client to check what your session can use. | Tool | Required privilege suffix | | -------------------------------------------------------------------------------------------------------------- | ------------------------------------------ | | [BuyEDaler](https://lab.tagroot.io/MCP/Payments#buyEdaler) | `Tools.EDaler.Buy` | | [CreateOpenPaymentUri](https://lab.tagroot.io/MCP/Payments#createOpenPaymentUri) | `Tools.Uri.Create` | | [CreatePaymentToBareJidUri](https://lab.tagroot.io/MCP/Payments#createPaymentUriToBareJid) | `Tools.Uri.Create` | | [CreatePaymentToLegalIdUri](https://lab.tagroot.io/MCP/Payments#createPaymentUriToLegalId) | `Tools.Uri.Create` | | [CreatePayMeUri](https://lab.tagroot.io/MCP/Payments#createPayMeUri) | `Tools.Uri.Create` | | [GetBalance](https://lab.tagroot.io/MCP/Payments#getBalance) | `Tools.Balance.Get` | | [GetBuyEDalerOptions](https://lab.tagroot.io/MCP/Payments#getOptionsForBuyingEdaler) | `Tools.EDaler.Buy` | | [GetPendingPayments](https://lab.tagroot.io/MCP/Payments#getPendingPayments) | `Tools.Pending.Get` | | [GetSellEDalerOptions](https://lab.tagroot.io/MCP/Payments#getOptionsForSellingEdaler) | `Tools.EDaler.Sell` | | [GetServiceProvidersForBuyingEDaler](https://lab.tagroot.io/MCP/Payments#getServiceProvidersForBuyingEdaler) | `Tools.EDaler.Buy` | | [GetServiceProvidersForSellingEDaler](https://lab.tagroot.io/MCP/Payments#getServiceProvidersForSellingEdaler) | `Tools.EDaler.Sell` | | [PayToBareJid](https://lab.tagroot.io/MCP/Payments#makePaymentToBareJid) | `Tools.Uri.Create` and `Tools.Uri.Process` | | [PayToLegalId](https://lab.tagroot.io/MCP/Payments#makePaymentToLegalId) | `Tools.Uri.Create` | | [ProcessPaymentUri](https://lab.tagroot.io/MCP/Payments#processPaymentUri) | `Tools.Uri.Process` | | [SellEDaler](https://lab.tagroot.io/MCP/Payments#sellEdaler) | `Tools.EDaler.Sell` | ## Use this server Start with `GetBalance` or `GetPendingPayments`. To buy or sell, discover providers, inspect their options, then use the selected provider identifier and type. Review the recipient and amount and obtain the user's confirmation before creating a payable transfer or making a payment. `Tools.Uri.Create` authorizes payment operations, including `PayToLegalId`; it is not a read-only permission. Check the returned result and pending payments before retrying an uncertain transfer. ## Resources and prompts Resources describe completed transactions, including timestamps, balance changes, counterparties, and messages. The prompts guide buying, selling, and transferring eDaler. Retrieving a prompt does not itself complete a payment. | Resource operation | Required privilege suffix | | ------------------------------------------------------------------------------------ | ------------------------- | | [resources/list](https://lab.tagroot.io/MCP/Payments#ResourcesListCursor) | `Resources.List` | | [resources/read](https://lab.tagroot.io/MCP/Payments#ResourcesReadUriMeta) | `Resources.Read` | | [resources/subscribe](https://lab.tagroot.io/MCP/Payments#ResourcesSubscribeUri) | `Resources.List` | | [resources/unsubscribe](https://lab.tagroot.io/MCP/Payments#ResourcesUnsubscribeUri) | `Resources.List` | | Prompt | Required privilege suffix | | ------------------------------------------------------------------ | ------------------------------------------ | | [CreateEDaler](https://lab.tagroot.io/MCP/Payments#createEdaler) | `Tools.EDaler.Buy` | | [DestroyEDaler](https://lab.tagroot.io/MCP/Payments#destroyEdaler) | `Tools.EDaler.Sell` | | [TransferMoney](https://lab.tagroot.io/MCP/Payments#transferMoney) | `Tools.EDaler.Buy` and `Tools.EDaler.Sell` | See the [original Payments reference](https://lab.tagroot.io/MCP/Payments) for complete schemas and response types, or return to [MCP servers](/mcp/servers/overview). # Messaging and contacts Source: https://docs.neuro-tech.io/mcp/servers/xmpp Send messages and manage contacts through the XMPP MCP server. Send messages and manage contacts through the XMPP MCP server. **Endpoint:** `https:///MCP/XMPP`. Use the host supplied by your provider. ## What you need You need an account the server can connect on your behalf. If account details are missing, the server requests them through the client. Your application communicates through MCP. ## Scopes and privileges The server advertises these OAuth scopes: ```text theme={null} MCP:XMPP:Tools MCP:XMPP:Prompts MCP:XMPP:Resources ``` Request the categories you need. The provider must also grant the corresponding role privileges; see [Scopes and permissions](/mcp/authentication-and-authorization). For the tables below, prepend `OAUTH.Scope.MCP.XMPP.` to each suffix. When a row lists multiple privileges, all are required. For example, `OAUTH.Scope.MCP.XMPP.Tools.Presence.Accept` is a complete privilege name. ## Tools Select a tool name for its complete arguments, defaults, and return values in the original reference. Discover tools in your client to check what your session can use. | Tool | Required privilege suffix | | ---------------------------------------------------------------------------------------------- | ---------------------------- | | [AcceptPresenceSubscription](https://lab.tagroot.io/MCP/XMPP#acceptPresenceSubscription) | `Tools.Presence.Accept` | | [AddToRoster](https://lab.tagroot.io/MCP/XMPP#addToRoster) | `Tools.Roster.Add` | | [DeclinePresenceSubscription](https://lab.tagroot.io/MCP/XMPP#declinePresenceSubscription) | `Tools.Presence.Decline` | | [GetMessage](https://lab.tagroot.io/MCP/XMPP#getMessage) | `Tools.Message.Get` | | [PopMessage](https://lab.tagroot.io/MCP/XMPP#popMessage) | `Tools.Message.Get` | | [RemoveFromRoster](https://lab.tagroot.io/MCP/XMPP#removeFromRoster) | `Tools.Roster.Remove` | | [RequestPresenceSubscription](https://lab.tagroot.io/MCP/XMPP#requestPresenceSubscription) | `Tools.Presence.Subscribe` | | [RequestPresenceUnsubscription](https://lab.tagroot.io/MCP/XMPP#requestPresenceUnsubscription) | `Tools.Presence.Unsubscribe` | | [SendChatMessage](https://lab.tagroot.io/MCP/XMPP#sendChatMessage) | `Tools.Message.Send` | | [UpdateRosterItem](https://lab.tagroot.io/MCP/XMPP#updateRosterItem) | `Tools.Roster.Update` | ## Use this server List resources to inspect contacts and queued messages. Use a bare JID, such as `name@example.net`, for contact identifiers. Request a presence subscription before exchanging messages with a new contact. `SendChatMessage` takes `To` and `Message`, with optional `IsMarkdown` and `Language`. `GetMessage` can remove a message when `Remove` is true; `PopMessage` also removes the retrieved message. Both use the `Tools.Message.Get` privilege. ## Resources and prompts Resources expose contacts and received messages. Use returned resource URIs for reads and subscriptions. No custom prompts are documented. | Resource operation | Required privilege suffix | | -------------------------------------------------------------------------------- | ------------------------- | | [resources/list](https://lab.tagroot.io/MCP/XMPP#ResourcesListCursor) | `Resources.List` | | [resources/read](https://lab.tagroot.io/MCP/XMPP#ResourcesReadUriMeta) | `Resources.Read` | | [resources/subscribe](https://lab.tagroot.io/MCP/XMPP#ResourcesSubscribeUri) | `Resources.List` | | [resources/unsubscribe](https://lab.tagroot.io/MCP/XMPP#ResourcesUnsubscribeUri) | `Resources.List` | See the [original Messaging and contacts reference](https://lab.tagroot.io/MCP/XMPP) for complete schemas and response types, or return to [MCP servers](/mcp/servers/overview). # Audit trails Source: https://docs.neuro-tech.io/neuro-ledger/audit-trail Distinguish ledger history, domain history, and operational events “Audit log” can refer to three different records on a Neuron. Use the one that answers your question. | Record | Answers | Access | | --------------------- | ----------------------------------------------------- | ------------------------------------------ | | Domain history | What happened to this contract, token, or identity? | Agent API or domain client | | Operational event log | What did this Neuron process, warn about, or reject? | Administration UI or Event Log MCP | | Neuro-Ledger blocks | Which persisted changes were signed and synchronized? | Ledger administration and authorized peers | The operational event log is not proof that an object was committed to the ledger. A ledger block is not a substitute for presenting the current signed contract or token history to an application user. ## Application audit checklist 1. Store the domain object ID returned by the Neuron. 2. Store the operation time and the authenticated actor in your application log. 3. Retrieve the object or its history from the owning API when evidence is needed. 4. Correlate failures with Neuron event IDs. 5. Ask the operator for ledger verification only when the assurance requirement calls for it. Never copy protected contract parameters, credentials, or private ledger content into an unrestricted application log. # Read ledger-backed application data Source: https://docs.neuro-tech.io/neuro-ledger/developer-access Use Agent API domain objects to inspect contracts, tokens, and transaction history Use the Agent API resource that owns the object you need. There is no documented general-purpose Agent API operation for appending arbitrary Neuro-Ledger records. | Data | Application entry point | | --------------------------------------- | ----------------------------------------------------------------------------- | | Contracts and signatures | [Contract operations](/neuron-api/api-reference/contracts/overview) | | Tokens and exposed event history | [Token inspection](/neuron-api/guides/tokens-flow) | | Token state-machine reports | [State-machine operations](/neuron-api/api-reference/state-machines/overview) | | Wallet balances and transaction results | [Wallet operations](/neuron-api/api-reference/wallet/overview) | Keep each returned identifier and use its domain API to retrieve subsequent state. Contract IDs, token IDs, and transaction IDs refer to different objects. An HTTP response does not imply that every related asynchronous action is complete. See [audit history](/neuro-ledger/audit-trail) and [asynchronous results](/neuron-api/events-and-asynchronous-state). # How Neuro-Ledger works Source: https://docs.neuro-tech.io/neuro-ledger/how-it-works A conceptual view of entries, blocks, signatures, and synchronization ## 1. A Neuron changes a persisted object The application performs a normal operation, such as creating or updating an object. Ledger participation is determined by the installed service and object configuration; it is not requested by adding a special field to an API call. ## 2. The ledger records the change New, updated, deleted, and cleared records can become ledger entries. Entries retain the information needed to identify the operation and verify its recorded representation. ## 3. Entries are collected into blocks The Neuron groups entries by collection and closes blocks according to its configured collection interval and size threshold. The node signs the resulting block and publishes its reference. ## 4. Authorized peers synchronize Approved contacts exchange block references over XMPP. A peer retrieves a block only when access policy permits it, then verifies the block before accepting its contents. ## 5. History can be checked Operators can inspect block statistics, collections, signatures, and synchronization results. Applications normally inspect the higher-level contract, token, or object history exposed by their supported API. ## Protect private ledger data “Distributed” does not mean “public.” A deployment can require a data-protection agreement and authorization before another node can retrieve blocks. Whether a specific record is shared depends on the deployment and collection policy. # Neuro-Ledger Source: https://docs.neuro-tech.io/neuro-ledger/overview Learn what the ledger records and which interface to use for application access Neuro-Ledger is the Neuron's distributed audit and persistence layer. It records selected object changes in signed blocks and synchronizes them with authorized peers. It is not a public cryptocurrency chain, a smart-contract virtual machine, or an API that every application writes to directly. ## Where it fits ```mermaid theme={null} flowchart LR A[Application] --> I[Neuron interface] I --> O[Contracts, tokens, identities, and other objects] O --> L[Neuro-Ledger] L --> P[Authorized ledger peers] ``` Most developers use the [Agent API](/neuron-api/introduction), [contracts](/contracts/overview), or package APIs. The Neuron decides which resulting records belong in the ledger. ## What applications gain * Important changes can be traced over time. * Blocks and references are signed and can be checked for integrity. * Synchronization is between identified, authorized peers rather than an anonymous global network. * Access controls can protect ledger content that should not be public. ## Use a Neuron interface The supported developer surface is the installed Neuron and its documented APIs. The Neuro-Ledger implementation repository is not required for application development and is not currently part of the public integration surface. Follow a record from persistence to a synchronized block. See which interface to use for each task. # API basics Source: https://docs.neuro-tech.io/neuron-api/api-basics Use the correct Agent API base URL, HTTP method, request body, and response handling ## Base URL All API requests are made to your Neuron's domain: ```text theme={null} https://{host} ``` Where `{host}` is the Neuron domain issued to you by your operator. There is no shared central URL — each Neuron deployment has its own domain. All endpoints are prefixed with `/Agent/`. For example: ```text theme={null} https://{host}/Agent/Account/Login ``` ## Required Referer header Include **`Referer` on every Agent API request**, including login, account creation, and calls from a backend or background service. Use your application's HTTPS URL, for example: ```http theme={null} Referer: https://app.example.com/ ``` Replace the example with a reachable URL for your application. Keep credentials, tokens, and personal data out of this URL. `Referer` identifies the calling application; authentication still uses the operation's required credentials or JWT. * **Backend and command-line clients:** set the header explicitly to your application's HTTPS URL. * **Browser clients:** the browser manages `Referer`. Use a referrer policy that sends the application origin, such as `strict-origin`. In `fetch`, set `referrer: window.location.origin + "/"` and `referrerPolicy: "strict-origin"`. For form submissions, configure the page's `Referrer-Policy` response header accordingly. Check the outgoing request in browser developer tools. Browser restrictions can suppress the header; use your backend if the browser cannot send it. See the [Fetch request options](https://developer.mozilla.org/en-US/docs/Web/API/RequestInit#referrer) for browser behavior. Legal Identity application also validates the supplied URL. If it rejects `Referer`, check that your application's URL is reachable from the Neuron. ## HTTP methods The current Neuron Agent API specification uses `POST` for most operations. `GET /Agent/Account/DomainInfo` is the documented exception. Operations with request bodies use JSON. ## Request structure Operations inherit JWT bearer authentication unless their OpenAPI entry explicitly overrides security. For bearer-authenticated calls, send: ```text theme={null} Referer: https://app.example.com/ Authorization: Bearer {token} Content-Type: application/json ``` Several account and session operations explicitly override the global bearer requirement. Login and account creation use HMAC values in the request body. Other anonymous operations have their own request requirements. Check the generated operation before deciding that a request is anonymous. When a documented `POST` operation has no parameters, its request is still an empty JSON object: ```json theme={null} {} ``` ## Response structure Documented successful response bodies use JSON when a schema is present. The shape varies per endpoint—see the individual [API reference](/neuron-api/api-reference/overview) pages. The OpenAPI document does not define a common error body for all operations or complete non-success response set. See [Error handling](/neuron-api/error-handling) before writing response parsing or retry logic. ## Federated network Some operations explicitly document federated behavior, including retrieving or signing contracts created on another Neuron. Do not assume every object or operation supports federation. See [Federation](/neuron-api/federation) for details. # Create account Source: https://docs.neuro-tech.io/neuron-api/api-reference/accounts-and-onboarding/create-account /test-api/openapi.yaml post /Agent/Account/Create Create a Neuron account and receive an initial JWT ## Overview Creates a new agent account and logs the user in. The account behaves like a regular XMPP account. New accounts are disabled until their email address is verified. Phone verification is optional if a phone number is provided. ## Authentication This endpoint requires an API key and secret. Sign the request with HMAC-SHA256 using the API secret as the key. Signature message: ``` userName:host:eMail:password:apiKey:nonce ``` ## Notes * Protect your API key and secret. They should only be used from secure back-end services. * Each API key has a limit on how many accounts it can create. * If you cannot protect secrets (for example, in a browser), use CreateWebForm. # Create Web Form Source: https://docs.neuro-tech.io/neuron-api/api-reference/accounts-and-onboarding/create-web-form /test-api/openapi.yaml post /Agent/Account/CreateWebForm Creates an agent account on the server manually (and logs in to it). ## Overview Creates an agent account on the server manually (and logs in to it). This account can be used when logging in, using the Agent API, but also to connect to the Neuron using any of the available XMPP bindings available. The account that is created, is considered a regular XMPP account on the broker. When first created, the account is in a disabled state. You need to validate the e-mail address provided in the request first (and the phone number, if providing a phone number), before the account can be enabled. An e-mail with a verification code will be sent to the e-mail address provided in the request. If providing a phone number, an SMS will be sent to the phone number. Note: To use this function, you need to configure the Neuron for use with Google Recaptcha, to protect against malicious account creation. This can be done using the same configuration as is used by the Feedback page. This also means, that when POSTing the request to the resource, it will be posted as a web form, not JSON or XML, as with most of the the other resources defined in this API. You also provide a redirection URL to redirect the user, upon successful creation of an account. Security Notice: To create accounts on the Neuron, an API Key is required. This resource requires an API Key to be generated on the Neuron, with the Owner set to Agent API. If no such key is available, or if the account limit configured in the key is reached, no more accounts can be generated using this resource until such a key is created or its limit increased. You can disable account creation using this resource, by simply removing any such API Key configured, or setting the limit at the number of accounts already created using the API Key. The following table shows if such a key is available, and if accounts can be created using this resource. ## Authentication No authentication required. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Domain Info Source: https://docs.neuro-tech.io/neuron-api/api-reference/accounts-and-onboarding/domain-info /test-api/openapi.yaml get /Agent/Account/DomainInfo Gets human-readable information about the domain of the server. ## Overview Gets human-readable information about the domain of the server. This resource is accessed using HTTP GET, so there is no payload sent to resource. The request can be made anonymously. No authentication is required. This resource is typically called in the beginning of an on-boarding process, where the user is given a choice to select service provider (i.e. domain). ## Authentication No authentication required. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Info Source: https://docs.neuro-tech.io/neuron-api/api-reference/accounts-and-onboarding/info /test-api/openapi.yaml post /Agent/Account/Info Gets information about the currently logged in account. ## Overview Gets information about the currently logged in account. The account does not need to be enabled for this resource to return information about the account. The information will be somewhat restricted if the account is not enabled. ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Accounts and onboarding Source: https://docs.neuro-tech.io/neuron-api/api-reference/accounts-and-onboarding/overview Agent API operations for account creation, verification, recovery, information, and transfer This page lists 9 Agent API operations generated from this repository's OpenAPI document. Open an operation to check its method, path, fields, and documented success response. ## Start with * [Sign in with an existing account](/neuron-api/first-request) * [Create an account with an API key](/neuron-api/guides/creating-an-account) * [Browser onboarding](/neuron-api/guides/browser-based-signup) ## Operations | Operation | Purpose | Authentication | | ---------------------------------------------------------------------------------------------------------------------------- | ------------------------- | ----------------------------- | | [`POST /Agent/Account/Create`](/neuron-api/api-reference/accounts-and-onboarding/create-account) | Create account | Operation-specific; no bearer | | [`POST /Agent/Account/CreateWebForm`](/neuron-api/api-reference/accounts-and-onboarding/create-web-form) | Create Web Form | Operation-specific; no bearer | | [`GET /Agent/Account/DomainInfo`](/neuron-api/api-reference/accounts-and-onboarding/domain-info) | Domain Info | Operation-specific; no bearer | | [`POST /Agent/Account/Info`](/neuron-api/api-reference/accounts-and-onboarding/info) | Info | JWT bearer | | [`POST /Agent/Account/Recover`](/neuron-api/api-reference/accounts-and-onboarding/recover) | Recover | Operation-specific; no bearer | | [`POST /Agent/Account/ResendVerificationCodes`](/neuron-api/api-reference/accounts-and-onboarding/resend-verification-codes) | Resend Verification Codes | Operation-specific; no bearer | | [`POST /Agent/Account/Transfer`](/neuron-api/api-reference/accounts-and-onboarding/transfer) | Transfer | JWT bearer | | [`POST /Agent/Account/VerifyEMail`](/neuron-api/api-reference/accounts-and-onboarding/verify-email) | Verify email | Operation-specific; no bearer | | [`POST /Agent/Account/VerifyPhoneNr`](/neuron-api/api-reference/accounts-and-onboarding/verify-phone-number) | Verify Phone Nr | Operation-specific; no bearer | ## Related guides | Guide | Operations from this resource | | ----------------------------------------------------------------------------- | ------------------------------------------------------------------- | | [Sign in with an existing account](/neuron-api/first-request) | `POST /Agent/Account/Info` | | [Create a sandbox account and approved test identity](/neuron-api/quickstart) | `POST /Agent/Account/Create`
`POST /Agent/Account/Info` | | [Onboard a verified Neuro identity](/build/verified-identity/overview) | `POST /Agent/Account/Create`
`POST /Agent/Account/VerifyEMail` | ## Related * [Accounts and Legal Identities](/concepts/accounts-and-identities) * [Authentication and sessions](/neuron-api/api-reference/authentication-and-sessions/overview) # Recover Source: https://docs.neuro-tech.io/neuron-api/api-reference/accounts-and-onboarding/recover /test-api/openapi.yaml post /Agent/Account/Recover Start account recovery without revealing account existence ## Overview Starts a recovery process when a user has lost access. The server may send a recovery email, request peer approval, or notify the operator depending on the account status. This endpoint can be called without an existing session. ## Authentication No authentication required. # Resend Verification Codes Source: https://docs.neuro-tech.io/neuron-api/api-reference/accounts-and-onboarding/resend-verification-codes /test-api/openapi.yaml post /Agent/Account/ResendVerificationCodes If, during onboarding, the verification codes do not arrive, or are lost, the client can request the codes to be resent. ## Overview If, during onboarding, the verification codes do not arrive, or are lost, the client can request the codes to be resent. To do this, the client needs to provide the token generated during account creation, as well as the eMail or phone number whose code they wish to resend. Security Notice: It is not possible to resend codes for accounts, numbers or e-mail addresses that have been verified. You can only resend codes for accounts still pending verification. This includes partially verified accounts. If the phone number has been verified, but the e-mail address has not, or vice versa, you can resend the code for the unverified part, but not for the verified part. Attempting to resend codes that have been verified, will be flagged, and repetetive calls to resend codes for verified accounts, numbers or addresses may result in the temporary and then permanent blocking of the endpoint making the call. ## Authentication No authentication required. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Transfer Source: https://docs.neuro-tech.io/neuron-api/api-reference/accounts-and-onboarding/transfer /test-api/openapi.yaml post /Agent/Account/Transfer Allows the client to transfer an account created using the Agent API to another application, such as Neuro-Access. ## Overview Allows the client to transfer an account created using the Agent API to another application, such as Neuro-Access. If the account has an associated current Legal ID, the ID will also be transferred to the new application. To transfer an account, without Legal ID, the Key ID, and Key Signatures can be omitted. If transferring an account with any associated Legal ID, and its corresponding private key, the Key ID and Key Signatures must be provided. ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Verify email Source: https://docs.neuro-tech.io/neuron-api/api-reference/accounts-and-onboarding/verify-email /test-api/openapi.yaml post /Agent/Account/VerifyEMail Enable an account by verifying the email address ## Overview New accounts are disabled until the email address is verified. Call this endpoint with the code sent to the user. ## Authentication No authentication required. # Verify Phone Nr Source: https://docs.neuro-tech.io/neuron-api/api-reference/accounts-and-onboarding/verify-phone-number /test-api/openapi.yaml post /Agent/Account/VerifyPhoneNr Verifies a phone number corresponding to an account that is being created. ## Overview Verifies a phone number corresponding to an account that is being created. When creating an account using /Account/Create, the account is at first disabled. This means, it cannot be used actively in the API. To enable an account, you need to verify the e-mail address provided when creating the account. If providing a phone number, you need to verify the phone number as well. If not providing a phone number you can skip this step. The account creation call will send an e-mail with a code to the e-mail address, as well as an SMS to the phone number, if such is provided. The code sent to the phone number needs to be provided in a call to this resource, together with the phone number ## Authentication No authentication required. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Authenticate Jwt Source: https://docs.neuro-tech.io/neuron-api/api-reference/authentication-and-sessions/authenticate-jwt /test-api/openapi.yaml post /Agent/Account/AuthenticateJwt Allows a service to authenticate a JWT token issued by the broker. ## Overview Allows a service to authenticate a JWT token issued by the broker. This resource does not require authenticated access. Any service that receives a JWT token issued by the broker can request the broker to validate the token, and to return parsed information available in the token. ## Authentication No bearer token is required. Pass the JWT to validate in the request body. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Get Session Token Source: https://docs.neuro-tech.io/neuron-api/api-reference/authentication-and-sessions/get-session-token /test-api/openapi.yaml post /Agent/Account/GetSessionToken Allows the client to get session information about a newly created account, created using a web form, without having to provide user credentials again. ## Overview Allows the client to get session information about a newly created account, created using a web form, without having to provide user credentials again. ## Authentication No authentication required. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Login Source: https://docs.neuro-tech.io/neuron-api/api-reference/authentication-and-sessions/login /test-api/openapi.yaml post /Agent/Account/Login Exchange credentials for a short-lived JWT ## Overview Authenticates a user and returns a JWT. This method is intended for programmatic clients and is an alternative to browser-based login flows. ## Authentication Sign the request using HMAC-SHA256 with the account password as the key. Signature message: ``` userName:host:nonce ``` # Logout Source: https://docs.neuro-tech.io/neuron-api/api-reference/authentication-and-sessions/logout /test-api/openapi.yaml post /Agent/Account/Logout Invalidate the current JWT session ## Overview Logs out the current session and invalidates the JWT. ## Authentication Requires a valid JWT bearer token. # Authentication and sessions Source: https://docs.neuro-tech.io/neuron-api/api-reference/authentication-and-sessions/overview Agent API operations for login, JWT validation, refresh, logout, and browser-session handoff This page lists 10 Agent API operations generated from this repository's OpenAPI document. Open an operation to check its method, path, fields, and documented success response. ## Start with * [Sign in with an existing account](/neuron-api/first-request) * [Compare login flows](/neuron-api/guides/login-flows) ## Operations | Operation | Purpose | Authentication | | --------------------------------------------------------------------------------------------------------------------------------- | -------------------------- | ----------------------------- | | [`POST /Agent/Account/AuthenticateJwt`](/neuron-api/api-reference/authentication-and-sessions/authenticate-jwt) | Authenticate Jwt | Operation-specific; no bearer | | [`POST /Agent/Account/GetSessionToken`](/neuron-api/api-reference/authentication-and-sessions/get-session-token) | Get Session Token | Operation-specific; no bearer | | [`POST /Agent/Account/Login`](/neuron-api/api-reference/authentication-and-sessions/login) | Login | Operation-specific; no bearer | | [`POST /Agent/Account/Logout`](/neuron-api/api-reference/authentication-and-sessions/logout) | Logout | JWT bearer | | [`POST /Agent/Account/PrepareRemoteQuickLogin`](/neuron-api/api-reference/authentication-and-sessions/prepare-remote-quick-login) | Prepare Remote Quick Login | JWT bearer | | [`POST /Agent/Account/QuickLogin`](/neuron-api/api-reference/authentication-and-sessions/quick-login) | Quick Login | Operation-specific; no bearer | | [`POST /Agent/Account/Refresh`](/neuron-api/api-reference/authentication-and-sessions/refresh) | Refresh | JWT bearer | | [`POST /Agent/Account/RemoteQuickLogin`](/neuron-api/api-reference/authentication-and-sessions/remote-quick-login) | Remote Quick Login | JWT bearer | | [`POST /Agent/Account/RemoteReferences`](/neuron-api/api-reference/authentication-and-sessions/remote-references) | Remote References | JWT bearer | | [`POST /Agent/Account/WwwLogin`](/neuron-api/api-reference/authentication-and-sessions/www-login) | Www Login | Operation-specific; no bearer | ## Related guides | Guide | Operations from this resource | | ----------------------------------------------------------------------------- | ------------------------------------------------------------- | | [Sign in with an existing account](/neuron-api/first-request) | `POST /Agent/Account/Login` | | [Discover and execute reports through the Agent API](/reports/quickstart) | `POST /Agent/Account/Login`
`POST /Agent/Account/Logout` | | [Create a sandbox account and approved test identity](/neuron-api/quickstart) | `POST /Agent/Account/Login` | ## Related * [Authentication formulas](/neuron-api/authentication) * [Accounts and onboarding](/neuron-api/api-reference/accounts-and-onboarding/overview) # Prepare Remote Quick Login Source: https://docs.neuro-tech.io/neuron-api/api-reference/authentication-and-sessions/prepare-remote-quick-login /test-api/openapi.yaml post /Agent/Account/PrepareRemoteQuickLogin Allows the client to prepare a remote Neuron for a quick login attempt made by the client, currently logged in via the Agent API. Note: This request must be made to Neuron to which the client is connected. ## Overview Allows the client to prepare a remote Neuron for a quick login attempt made by the client, currently logged in via the Agent API. Note: This request must be made to Neuron to which the client is connected. ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Quick Login Source: https://docs.neuro-tech.io/neuron-api/api-reference/authentication-and-sessions/quick-login /test-api/openapi.yaml post /Agent/Account/QuickLogin Allows the client to authenticate itself with the API using a Quick-Login. ## Overview Allows the client to authenticate itself with the API using a Quick-Login. performed in the current HTTP Session. This method is an alternative to the Login and WwwLogin resources. Note: To be able to access the current session, cookies must be enabled. Note 2: Community Login is demonstrated in the link above, as it uses Quick-Login in session mode. API documentation for Quick-Login can be found here: QuickLogin API Documentation. You need to have the Community Package installed for the Community Login to be available. Note 3: It is assumed the Agent API account resides on the same broker. The Agent API is an HTTP REST API for using an XMPP account on an XMPP broker. Once you have made a Quick-Login in a broker, you can use the RemoteQuickLogin resource to perform session logins on other brokers using the QuickLogin on the current broker, providing the JWT token obtained from the current broker. If authentication succeeds, a JSON Web Token (or JWT) is returned to the client. This token can be used as a Bearer token in subsequent calls to the API. It needs to be refreshed before it expires. ## Authentication No authentication required. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Refresh Source: https://docs.neuro-tech.io/neuron-api/api-reference/authentication-and-sessions/refresh /test-api/openapi.yaml post /Agent/Account/Refresh Refresh a JWT without logging in again ## Overview Use this endpoint to obtain a new JWT before the current one expires. If refresh fails or the token is expired, log in again. ## Authentication Requires a valid JWT bearer token. # Remote Quick Login Source: https://docs.neuro-tech.io/neuron-api/api-reference/authentication-and-sessions/remote-quick-login /test-api/openapi.yaml post /Agent/Account/RemoteQuickLogin Allows the client to trigger a Quick Login procedure on a remote Neuron, without having to scan a QR code, and if successful, logging in on the machine using a given Legal Identity. Note: The call to the remote neuron does not require a login or an Agent API connection. Note 2: A Legal ID can be used to login on multiple machines. ## Overview Allows the client to trigger a Quick Login procedure on a remote Neuron, without having to scan a QR code, and if successful, logging in on the machine using a given Legal Identity. Note: The call to the remote neuron does not require a login or an Agent API connection. Note 2: A Legal ID can be used to login on multiple machines. If administrative access is granted to the corresponding Legal Identity, an administrative login will also be performed, if the login is successful. Note 3: Only session logins (i.e. admin logins and quick-logins) can be made using this resource. No new JWT token will be generated, as the Agent API can only be connected to the broker associated with the account the agent is using. Note 4: You can prepare the the remote quick login procedure by calling the /Account/PrepareRemoteQuickLogin resource to get the Legal ID associated with the current account. Note 5: This method of initiating the Quick-Login does not require the client to scan a QR code. Instead, the request to sign the login is sent automatically to the client when the /Account/RemoteQuickLogin resource is called. If authentication succeeds, a quick-login is performed automatically in the current session, and if there is an administrative account associated with the digital identity, such a login is also performed in the current session. ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Remote References Source: https://docs.neuro-tech.io/neuron-api/api-reference/authentication-and-sessions/remote-references /test-api/openapi.yaml post /Agent/Account/RemoteReferences Allows the client to get a list of references to remote neurons the user can quick-login to using /Account/RemoteQuickLogin. Note: The list may not be complete. ## Overview Allows the client to get a list of references to remote neurons the user can quick-login to using /Account/RemoteQuickLogin. Note: The list may not be complete. Each time a Legal Identity is added or removed as a reference on an Neuron, an incremental message is sent ot the Neuron hosting the associated account. If the list is not complete, just remove and add the reference to the Legal ID again on the remote broker, to update the list. ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Www Login Source: https://docs.neuro-tech.io/neuron-api/api-reference/authentication-and-sessions/www-login /test-api/openapi.yaml post /Agent/Account/WwwLogin Allows the client to authenticate itself with the API, using the WWW-Authenticate Header available in the HTTP protocol. If authentication succeeds, a JSON Web Token (or JWT) is returned to the client. ## Overview Allows the client to authenticate itself with the API, using the WWW-Authenticate Header available in the HTTP protocol. If authentication succeeds, a JSON Web Token (or JWT) is returned to the client. This token can be used as a Bearer token in subsequent calls to the API. It needs to be refreshed before it expires. Security Notice: Some WWW-Authentication mechanism send the password in clear text. While encryption is required, password is still unpacked by the remote endpoint, which may be a security consideration. Use the Login or QuickLogin resources to avoid this. The Javascript library uses the these resources instead of the WwwLogin alternative. But if a client is unable to generate cryptographic signatures as required by the specification, traditional WWW-Authentication mechanisms are also available. ## Authentication No authentication required. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Authorize Access To Contract Source: https://docs.neuro-tech.io/neuron-api/api-reference/contracts/authorize-access-to-contract /test-api/openapi.yaml post /Agent/Legal/AuthorizeAccessToContract Allows the client to (pre-)authorize access to (or remove authorization to access) one of its Smart Contracts (or one of the Smart Contracts for which the client is part) to a remote party. ## Overview Allows the client to (pre-)authorize access to (or remove authorization to access) one of its Smart Contracts (or one of the Smart Contracts for which the client is part) to a remote party. When (if) the remote party requests access to the the Smart Contract, the broker will return it automatically, if already authorized. If not authorized, a petition to access the Smart Contract will be sent to the clients of the part of the contract for manual approval. ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Create Contract Source: https://docs.neuro-tech.io/neuron-api/api-reference/contracts/create-contract /test-api/openapi.yaml post /Agent/Legal/CreateContract Allows the client to create a new smart contract, based on an existing (and approved) contract template. ## Overview Allows the client to create a new smart contract, based on an existing (and approved) contract template. The request must be signed using one of the keys created by the client. ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Get Contract Source: https://docs.neuro-tech.io/neuron-api/api-reference/contracts/get-contract /test-api/openapi.yaml post /Agent/Legal/GetContract Allows the client to get a Smart Contract. ## Overview Allows the client to get a Smart Contract. If the Contract belongs to someone else, and the client is not authorized access to the Contract, an error will be returned. Note: Neurons are federated. You can get contracts created on other neurons through this API on the neuron you have your account on. Federated means that the neurons interconnect to share authorized information, when requested, and permitted. ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Get Created Contracts Source: https://docs.neuro-tech.io/neuron-api/api-reference/contracts/get-created-contracts /test-api/openapi.yaml post /Agent/Legal/GetCreatedContracts Gets smart contracts the account has created. ## Overview Gets smart contracts the account has created. ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Get Signed Contracts Source: https://docs.neuro-tech.io/neuron-api/api-reference/contracts/get-signed-contracts /test-api/openapi.yaml post /Agent/Legal/GetSignedContracts Gets smart contracts the account has signed. ## Overview Gets smart contracts the account has signed. ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Contracts Source: https://docs.neuro-tech.io/neuron-api/api-reference/contracts/overview Agent API operations for templates, contract instances, access, proposals, and signatures This page lists 8 Agent API operations generated from this repository's OpenAPI document. Open an operation to check its method, path, fields, and documented success response. ## Start with * [Build an agreement](/build/agreements/overview) * [Use contract API operations](/contracts/agent-api-quickstart) ## Operations | Operation | Purpose | Authentication | | ----------------------------------------------------------------------------------------------------------------- | ---------------------------- | -------------- | | [`POST /Agent/Legal/AuthorizeAccessToContract`](/neuron-api/api-reference/contracts/authorize-access-to-contract) | Authorize Access To Contract | JWT bearer | | [`POST /Agent/Legal/CreateContract`](/neuron-api/api-reference/contracts/create-contract) | Create Contract | JWT bearer | | [`POST /Agent/Legal/GetContract`](/neuron-api/api-reference/contracts/get-contract) | Get Contract | JWT bearer | | [`POST /Agent/Legal/GetCreatedContracts`](/neuron-api/api-reference/contracts/get-created-contracts) | Get Created Contracts | JWT bearer | | [`POST /Agent/Legal/GetSignedContracts`](/neuron-api/api-reference/contracts/get-signed-contracts) | Get Signed Contracts | JWT bearer | | [`POST /Agent/Legal/ProposeTemplate`](/neuron-api/api-reference/contracts/propose-contract-template) | Propose Template | JWT bearer | | [`POST /Agent/Legal/SignContract`](/neuron-api/api-reference/contracts/sign-contract) | Sign Contract | JWT bearer | | [`POST /Agent/Legal/SignData`](/neuron-api/api-reference/contracts/sign-data) | Sign Data | JWT bearer | ## Related guides | Guide | Operations from this resource | | -------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ | | [Author and sign an acknowledgement contract](/contracts/from-scratch) | `POST /Agent/Legal/ProposeTemplate`
`POST /Agent/Legal/CreateContract`
`POST /Agent/Legal/GetContract`
`POST /Agent/Legal/SignContract` | | [Build a tokenized product passport](/build/tokenized-assets/overview) | `POST /Agent/Legal/CreateContract` | | [Author a token with a machine and Script](/build/tokenized-assets/from-scratch) | `POST /Agent/Legal/ProposeTemplate`
`POST /Agent/Legal/CreateContract`
`POST /Agent/Legal/GetContract`
`POST /Agent/Legal/SignContract` | | [Create an agreement between two verified parties](/build/agreements/overview) | `POST /Agent/Legal/CreateContract`
`POST /Agent/Legal/SignContract`
`POST /Agent/Legal/GetContract` | ## Related * [Smart contracts](/concepts/smart-contracts) * [Contract lifecycle](/neuron-api/guides/contracts-flow) # Propose Template Source: https://docs.neuro-tech.io/neuron-api/api-reference/contracts/propose-contract-template /test-api/openapi.yaml post /Agent/Legal/ProposeTemplate Allows the client to propose a new smart contract template. ## Overview Allows the client to propose a new smart contract template. The smart contract template is an XML document that conforms to the smart contract schema. You can design smart contracts using the LegalLab application. ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Send a contract proposal Source: https://docs.neuro-tech.io/neuron-api/api-reference/contracts/send-proposal Deliver a contractProposal stanza through the Agent API XMPP message endpoint Set `NEURON_REFERER` to your application's HTTPS URL. Include this header on every request, including backend calls. See [required request headers](/neuron-api/api-basics#required-referer-header). `POST /Agent/Legal/SendProposal` does not exist in the Neuron server. `AgentAPI.Legal.SendProposal(...)` is a JavaScript convenience function that builds XML and calls the real HTTP operation, [`POST /Agent/Xmpp/SendXmlMessage`](/neuron-api/api-reference/messaging/send-xml-message). ## Request The current contract namespace is `urn:nf:iot:leg:sc:1.0`. XML-escape every attribute value. ```bash theme={null} curl --fail-with-body \ -X POST "https://${NEURON_HOST}/Agent/Xmpp/SendXmlMessage" \ -H "Referer: ${NEURON_REFERER}" \ -H "Authorization: Bearer ${ALICE_JWT}" \ -H "Content-Type: application/json" \ -d '{ "to": "bob@neuron.example.com", "xml": "" }' ``` `to` is Bob's bare or full XMPP JID. `contractId` is the ID returned by `CreateContract`, and `role` must exactly match the role Bob is expected to sign. A successful response reports only that the stanza was sent: ```json theme={null} { "sent": true, "id": "generated-message-id" } ``` `sent: true` is not acceptance and does not prove that Bob reviewed the contract. Bob can receive queued messages with [`POST /Agent/Xmpp/PopMessages`](/neuron-api/api-reference/messaging/pop-messages) or use a supported XMPP/event client. The proposal is accepted when Bob retrieves the exact contract, explicitly approves it in the application, and successfully signs the proposed role. ## JavaScript helper When the Neuron's `/Agent.js` is loaded, the equivalent call is: ```javascript theme={null} await AgentAPI.Legal.SendProposal( contractId, "Reader", "bob@neuron.example.com", "Please review and sign.", ); ``` The helper uses the same current namespace and delegates to `AgentAPI.Xmpp.SendXmlMessage`. The plain helper does not include a shared secret for encrypted contract parameters. Use a contract client with end-to-end proposal support for contracts containing confidential parameters. ## Continue Follow the [two-party contract lifecycle](/neuron-api/guides/contracts-flow), including receipt confirmation, both signatures, and final-state verification. # Sign Contract Source: https://docs.neuro-tech.io/neuron-api/api-reference/contracts/sign-contract /test-api/openapi.yaml post /Agent/Legal/SignContract Allows the client to sign a smart contract. Note: Neurons are federated. ## Signature construction Let `s1 = username + ":" + HTTP-Host + ":" + localName + ":" + namespace + ":" + keyId`, using the algorithm stored with the key. * `keySignature = Base64(HMAC-SHA256(UTF8(keyPassword), UTF8(s1)))` * Generate at least 32 random bytes and Base64-encode them as `nonce`. * Let `s2 = s1 + ":" + keySignature + ":" + nonce + ":" + legalId + ":" + contractId + ":" + role`. * `requestSignature = Base64(HMAC-SHA256(UTF8(accountPassword), UTF8(s2)))` Use the exact HTTP `Host` header value, including a non-default port. Preserve the documented field order and exact casing. Never reuse a nonce. The Neuron then decrypts the stored private key, signs the normalized contract bytes, and returns the updated `Contract` object. See the [contract lifecycle guide](/neuron-api/guides/contracts-flow) for a JavaScript implementation. # Sign Data Source: https://docs.neuro-tech.io/neuron-api/api-reference/contracts/sign-data /test-api/openapi.yaml post /Agent/Legal/SignData Allows the client to sign binary data. ## Overview Allows the client to sign binary data. ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Create Key Source: https://docs.neuro-tech.io/neuron-api/api-reference/cryptography/create-key /test-api/openapi.yaml post /Agent/Crypto/CreateKey Allows the client to create a cryptographic key on the server, and protect it with a password. ## Key identifier The caller chooses `id`. A successful response returns storage timestamps, not a newly generated key identifier. Persist the submitted `id`; later operations call it `keyId`. ## Signature construction Let `s1 = username + ":" + HTTP-Host + ":" + localName + ":" + namespace + ":" + id`. * `keySignature = Base64(HMAC-SHA256(UTF8(keyPassword), UTF8(s1)))` * Generate at least 32 random bytes and Base64-encode them as `nonce`. * Let `s2 = s1 + ":" + keySignature + ":" + nonce`. * `requestSignature = Base64(HMAC-SHA256(UTF8(accountPassword), UTF8(s2)))` Use the exact HTTP `Host` header value, including a non-default port. String order and casing are significant. Never reuse a nonce. See the [copy-paste key guide](/neuron-api/guides/creating-cryptographic-keys) for JavaScript. # Get Algorithms Source: https://docs.neuro-tech.io/neuron-api/api-reference/cryptography/get-algorithms /test-api/openapi.yaml post /Agent/Crypto/GetAlgorithms Allows the client to retrieve a list of available cryptographic algorithms on the server. ## Overview Allows the client to retrieve a list of available cryptographic algorithms on the server. These algorithms can be used to create keys. These keys are necessary in order to apply for legal identities, which are then used to sign smart contracts. ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Get Public Key Source: https://docs.neuro-tech.io/neuron-api/api-reference/cryptography/get-public-key /test-api/openapi.yaml post /Agent/Crypto/GetPublicKey Allows the client to get the current server public key, or the public key of one of its own cryptographic keys. ## Overview Allows the client to get the current server public key, or the public key of one of its own cryptographic keys. The client can use this key to validate signatures server in relation to legal identities, smart contracts, tokens, etc. Note: If a Key ID is provided, information about one of the keys of the client account is returned. If not Key ID is provided, information about the the public server key is returned. Note 2: If no Key ID is provided, resource requires no authentication. If a Key ID is provided, a Bearer token identifying the client account must be provided. ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Cryptography Source: https://docs.neuro-tech.io/neuron-api/api-reference/cryptography/overview Agent API operations for algorithm discovery, key creation, and public-key retrieval This page lists 3 Agent API operations generated from this repository's OpenAPI document. Open an operation to check its method, path, fields, and documented success response. ## Start with * [Create a cryptographic key](/neuron-api/guides/creating-cryptographic-keys) ## Operations | Operation | Purpose | Authentication | | ------------------------------------------------------------------------------------------- | -------------- | -------------- | | [`POST /Agent/Crypto/CreateKey`](/neuron-api/api-reference/cryptography/create-key) | Create Key | JWT bearer | | [`POST /Agent/Crypto/GetAlgorithms`](/neuron-api/api-reference/cryptography/get-algorithms) | Get Algorithms | JWT bearer | | [`POST /Agent/Crypto/GetPublicKey`](/neuron-api/api-reference/cryptography/get-public-key) | Get Public Key | JWT bearer | ## Related guides | Guide | Operations from this resource | | ----------------------------------------------------------------------------- | ---------------------------------------------------------------------- | | [Create a sandbox account and approved test identity](/neuron-api/quickstart) | `POST /Agent/Crypto/GetAlgorithms`
`POST /Agent/Crypto/CreateKey` | | [Onboard a verified Neuro identity](/build/verified-identity/overview) | `POST /Agent/Crypto/CreateKey` | ## Related * [Keys and signatures](/concepts/keys-and-signatures) * [Digital signatures](/build/digital-signatures/overview) # Add Id Attachment Source: https://docs.neuro-tech.io/neuron-api/api-reference/legal-identities/add-id-attachment /test-api/openapi.yaml post /Agent/Legal/AddIdAttachment Allows the client to add an attachment to a Legal Identity application. ## Overview Allows the client to add an attachment to a Legal Identity application. ## Authentication Requires a valid JWT bearer token. Complete uploads while the application is Created, then call ReadyForApproval to start review. The server signs each attachment; no separate SignData call is needed. Follow the [identity application guide](/neuron-api/guides/applying-for-a-legal-identity#4-sign-and-upload-the-attachment) for complete signed HTTP requests. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Apply Id Source: https://docs.neuro-tech.io/neuron-api/api-reference/legal-identities/apply-for-id /test-api/openapi.yaml post /Agent/Legal/ApplyId Allows the client to apply for a new Legal Identity on the server. ## Overview Allows the client to apply for a new Legal Identity on the server. The application must be signed using one of the keys created by the client. ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Authorize Access To Id Source: https://docs.neuro-tech.io/neuron-api/api-reference/legal-identities/authorize-access-to-id /test-api/openapi.yaml post /Agent/Legal/AuthorizeAccessToId Allows the client to (pre-)authorize access to (or remove authorization to access) one of its Legal Identities to a remote party. ## Overview Allows the client to (pre-)authorize access to (or remove authorization to access) one of its Legal Identities to a remote party. When (if) the remote party requests the ID, the broker will return it automatically, if already authorized. If not authorized, a petition to access the identity will be sent to the client for manual approval (or rejection). ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Get Application Attributes Source: https://docs.neuro-tech.io/neuron-api/api-reference/legal-identities/get-application-attributes /test-api/openapi.yaml post /Agent/Legal/GetApplicationAttributes Allows the client to get important attributes necessary to perform a correct ID Application. ## Overview Allows the client to get important attributes necessary to perform a correct ID Application. ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Get Identities Source: https://docs.neuro-tech.io/neuron-api/api-reference/legal-identities/get-identities /test-api/openapi.yaml post /Agent/Legal/GetIdentities Gets the account's legal identities. ## Overview Gets the account's legal identities. ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Get Identity Source: https://docs.neuro-tech.io/neuron-api/api-reference/legal-identities/get-identity /test-api/openapi.yaml post /Agent/Legal/GetIdentity Allows the client to get an Identity. ## Overview Allows the client to get an Identity. If the Identity belongs to someone else, and the client is not authorized access to the Identity, an error will be returned. Note: Neurons are federated. You can get identities created on other neurons through this API on the neuron you have your account on. Federated means that the neurons interconnect to share authorized information, when requested, and permitted. ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Get Service Providers For Id Review Source: https://docs.neuro-tech.io/neuron-api/api-reference/legal-identities/get-service-providers-for-id-review /test-api/openapi.yaml post /Agent/Legal/GetServiceProvidersForIdReview Allows the client to retrieve a list of available service providers that can be used to review a recent ID application. ## Overview Allows the client to retrieve a list of available service providers that can be used to review a recent ID application. ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Legal identities Source: https://docs.neuro-tech.io/neuron-api/api-reference/legal-identities/overview Agent API operations for identity applications, evidence, review, retrieval, and petitions This page lists 13 Agent API operations generated from this repository's OpenAPI document. Open an operation to check its method, path, fields, and documented success response. ## Start with * [Build with verified identity](/build/verified-identity/overview) * [Follow the identity lifecycle](/neuron-api/guides/legal-identity-flow) ## Operations | Operation | Purpose | Authentication | | ------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------- | -------------- | | [`POST /Agent/Legal/AddIdAttachment`](/neuron-api/api-reference/legal-identities/add-id-attachment) | Add Id Attachment | JWT bearer | | [`POST /Agent/Legal/ApplyId`](/neuron-api/api-reference/legal-identities/apply-for-id) | Apply Id | JWT bearer | | [`POST /Agent/Legal/AuthorizeAccessToId`](/neuron-api/api-reference/legal-identities/authorize-access-to-id) | Authorize Access To Id | JWT bearer | | [`POST /Agent/Legal/GetApplicationAttributes`](/neuron-api/api-reference/legal-identities/get-application-attributes) | Get Application Attributes | JWT bearer | | [`POST /Agent/Legal/GetIdentities`](/neuron-api/api-reference/legal-identities/get-identities) | Get Identities | JWT bearer | | [`POST /Agent/Legal/GetIdentity`](/neuron-api/api-reference/legal-identities/get-identity) | Get Identity | JWT bearer | | [`POST /Agent/Legal/GetServiceProvidersForIdReview`](/neuron-api/api-reference/legal-identities/get-service-providers-for-id-review) | Get Service Providers For Id Review | JWT bearer | | [`POST /Agent/Legal/PetitionId`](/neuron-api/api-reference/legal-identities/petition-id) | Petition Id | JWT bearer | | [`POST /Agent/Legal/PetitionPeerReview`](/neuron-api/api-reference/legal-identities/petition-peer-review) | Petition Peer Review | JWT bearer | | [`POST /Agent/Legal/PetitionSignature`](/neuron-api/api-reference/legal-identities/petition-signature) | Petition Signature | JWT bearer | | [`POST /Agent/Legal/ReadyForApproval`](/neuron-api/api-reference/legal-identities/ready-for-approval) | Ready For Approval | JWT bearer | | [`POST /Agent/Legal/SelectReviewService`](/neuron-api/api-reference/legal-identities/select-review-service) | Select Review Service | JWT bearer | | [`POST /Agent/Legal/ValidatePNr`](/neuron-api/api-reference/legal-identities/validate-pnr) | Validate PNr | JWT bearer | ## Related guides | Guide | Operations from this resource | | ----------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [Create a sandbox account and approved test identity](/neuron-api/quickstart) | `POST /Agent/Legal/GetApplicationAttributes`
`POST /Agent/Legal/ApplyId`
`POST /Agent/Legal/AddIdAttachment`
`POST /Agent/Legal/ReadyForApproval`
`POST /Agent/Legal/GetIdentity` | | [Onboard a verified Neuro identity](/build/verified-identity/overview) | `POST /Agent/Legal/GetApplicationAttributes`
`POST /Agent/Legal/ApplyId`
`POST /Agent/Legal/AddIdAttachment`
`POST /Agent/Legal/ReadyForApproval`
`POST /Agent/Legal/GetIdentity` | ## Related * [Accounts and Legal Identities](/concepts/accounts-and-identities) * [Cryptography](/neuron-api/api-reference/cryptography/overview) # Petition Id Source: https://docs.neuro-tech.io/neuron-api/api-reference/legal-identities/petition-id /test-api/openapi.yaml post /Agent/Legal/PetitionId Allows the client to petition the owner of a Legal Identity, for information about the identity. ## Overview Allows the client to petition the owner of a Legal Identity, for information about the identity. ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Petition Peer Review Source: https://docs.neuro-tech.io/neuron-api/api-reference/legal-identities/petition-peer-review /test-api/openapi.yaml post /Agent/Legal/PetitionPeerReview Allows the client to petition a peer to review an ID application. ## Overview Allows the client to petition a peer to review an ID application. ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Petition Signature Source: https://docs.neuro-tech.io/neuron-api/api-reference/legal-identities/petition-signature /test-api/openapi.yaml post /Agent/Legal/PetitionSignature Allows the client to petition the owner of a Legal Identity for a digital signature on some digital content. ## Overview Allows the client to petition the owner of a Legal Identity for a digital signature on some digital content. ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Ready For Approval Source: https://docs.neuro-tech.io/neuron-api/api-reference/legal-identities/ready-for-approval /test-api/openapi.yaml post /Agent/Legal/ReadyForApproval When an ID application is ready (all attachments have been signed and uploaded), the client can call this resource to flag the application as ready for approval. ## Overview When an ID application is ready (all attachments have been signed and uploaded), the client can call this resource to flag the application as ready for approval. This will execute any automated onboarding procedures to analyze the application, and, if passing them, will take the identity to the approved state. They can also take the application to the rejected state, in case they find the information invalid. ## Authentication Requires a valid JWT bearer token. Call this after all required attachments are uploaded while the identity is Created. If the sandbox has already approved it, skip this request. Then retrieve the identity to observe its state. Follow the [identity application guide](/neuron-api/guides/applying-for-a-legal-identity#5-mark-the-application-ready-for-approval) for complete signed HTTP requests. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Select Review Service Source: https://docs.neuro-tech.io/neuron-api/api-reference/legal-identities/select-review-service /test-api/openapi.yaml post /Agent/Legal/SelectReviewService Allows the client to select an internal peer review service, for reviewing a recent identity application. ## Overview Allows the client to select an internal peer review service, for reviewing a recent identity application. ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Validate PNr Source: https://docs.neuro-tech.io/neuron-api/api-reference/legal-identities/validate-pnr /test-api/openapi.yaml post /Agent/Legal/ValidatePNr Allows the client to validate a personal number before using it to apply for a Legal Identity. ## Overview Allows the client to validate a personal number before using it to apply for a Legal Identity. ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Clear Messages Source: https://docs.neuro-tech.io/neuron-api/api-reference/messaging/clear-messages /test-api/openapi.yaml post /Agent/Xmpp/ClearMessages Clears any offline messages available for the account from the server. ## Overview Clears any offline messages available for the account from the server. ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Get Roster Source: https://docs.neuro-tech.io/neuron-api/api-reference/messaging/get-roster /test-api/openapi.yaml post /Agent/Xmpp/GetRoster Gets the account's roster. ## Overview Gets the account's roster. ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Get Roster Item Source: https://docs.neuro-tech.io/neuron-api/api-reference/messaging/get-roster-item /test-api/openapi.yaml post /Agent/Xmpp/GetRosterItem Gets information about a specific roster item for the account. ## Overview Gets information about a specific roster item for the account. ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Information Query Source: https://docs.neuro-tech.io/neuron-api/api-reference/messaging/information-query /test-api/openapi.yaml post /Agent/Xmpp/InformationQuery Sends an Information Query (iq) to an entity on the XMPP network, given its Full JID. ## Overview Sends an Information Query (iq) to an entity on the XMPP network, given its Full JID. For connected entities, you need to have an presence subscription to that entity, approved by the entity, to get the Full JID. You get the Full JID using the Presence Probe resource. ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Messaging Source: https://docs.neuro-tech.io/neuron-api/api-reference/messaging/overview Agent API operations for XMPP messages, presence, roster, retrieval, and browser events This page lists 16 Agent API operations generated from this repository's OpenAPI document. Open an operation to check its method, path, fields, and documented success response. ## Start with * [Send and receive messages](/neuron-api/guides/messaging) * [Receive browser events](/neuron-api/guides/webhooks) ## Operations | Operation | Purpose | Authentication | | ----------------------------------------------------------------------------------------------------------------- | ---------------------------- | -------------- | | [`POST /Agent/Xmpp/ClearMessages`](/neuron-api/api-reference/messaging/clear-messages) | Clear Messages | JWT bearer | | [`POST /Agent/Xmpp/GetRoster`](/neuron-api/api-reference/messaging/get-roster) | Get Roster | JWT bearer | | [`POST /Agent/Xmpp/GetRosterItem`](/neuron-api/api-reference/messaging/get-roster-item) | Get Roster Item | JWT bearer | | [`POST /Agent/Xmpp/InformationQuery`](/neuron-api/api-reference/messaging/information-query) | Information Query | JWT bearer | | [`POST /Agent/Xmpp/PopMessages`](/neuron-api/api-reference/messaging/pop-messages) | Pop Messages | JWT bearer | | [`POST /Agent/Xmpp/PresenceProbe`](/neuron-api/api-reference/messaging/presence-probe) | Presence Probe | JWT bearer | | [`POST /Agent/Xmpp/RegisterEventHandler`](/neuron-api/api-reference/messaging/register-event-handler) | Register Event Handler | JWT bearer | | [`POST /Agent/Xmpp/RemoveRosterItem`](/neuron-api/api-reference/messaging/remove-roster-item) | Remove Roster Item | JWT bearer | | [`POST /Agent/Xmpp/SendFormattedMessage`](/neuron-api/api-reference/messaging/send-formatted-message) | Send formatted message | JWT bearer | | [`POST /Agent/Xmpp/SendPresenceSubscription`](/neuron-api/api-reference/messaging/send-presence-subscription) | Send Presence Subscription | JWT bearer | | [`POST /Agent/Xmpp/SendPresenceUnsubscription`](/neuron-api/api-reference/messaging/send-presence-unsubscription) | Send Presence Unsubscription | JWT bearer | | [`POST /Agent/Xmpp/SendSubscriptionAccepted`](/neuron-api/api-reference/messaging/send-subscription-accepted) | Send Subscription Accepted | JWT bearer | | [`POST /Agent/Xmpp/SendSubscriptionDeclined`](/neuron-api/api-reference/messaging/send-subscription-declined) | Send Subscription Declined | JWT bearer | | [`POST /Agent/Xmpp/SendTextMessage`](/neuron-api/api-reference/messaging/send-text-message) | Send text message | JWT bearer | | [`POST /Agent/Xmpp/SendXmlMessage`](/neuron-api/api-reference/messaging/send-xml-message) | Send Xml Message | JWT bearer | | [`POST /Agent/Xmpp/SetRosterItem`](/neuron-api/api-reference/messaging/set-roster-item) | Set Roster Item | JWT bearer | ## Related guides | Guide | Operations from this resource | | ------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------- | | [Discover and execute reports through the Agent API](/reports/quickstart) | `POST /Agent/Xmpp/PresenceProbe`
`POST /Agent/Xmpp/InformationQuery`
`POST /Agent/Xmpp/PopMessages` | | [Create an agreement between two verified parties](/build/agreements/overview) | `POST /Agent/Xmpp/SendXmlMessage`
`POST /Agent/Xmpp/PopMessages` | ## Related * [Federation](/neuron-api/federation) * [Events and asynchronous state](/neuron-api/events-and-asynchronous-state) # Pop Messages Source: https://docs.neuro-tech.io/neuron-api/api-reference/messaging/pop-messages /test-api/openapi.yaml post /Agent/Xmpp/PopMessages Gets messages for the account from the server. ## Overview Gets messages for the account from the server. ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Presence Probe Source: https://docs.neuro-tech.io/neuron-api/api-reference/messaging/presence-probe /test-api/openapi.yaml post /Agent/Xmpp/PresenceProbe Gets the latest presence issued by a contact in your roster who has approved your presence subscription request. Note: The result to the presence probe request will give you the latest Full JID published by the contact. ## Overview Gets the latest presence issued by a contact in your roster who has approved your presence subscription request. Note: The result to the presence probe request will give you the latest Full JID published by the contact. This Full JID can be used to make directed information queries to the contact. Security Note: You are only allowed to send a presence probe to contacts that have approved a presence subscription from you. Note 2: If you request the presence of an entity to which you do not have a presence subscription, one will be sent automatically. If you want to send custom XML in the presence subscription request, you should call SendPresenceSubscription.md first. ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Register Event Handler Source: https://docs.neuro-tech.io/neuron-api/api-reference/messaging/register-event-handler /test-api/openapi.yaml post /Agent/Xmpp/RegisterEventHandler Registers (or unregisters) an event handler on the client, that gets called when the account receives an XMPP message of a given type. ## Overview Registers (or unregisters) an event handler on the client, that gets called when the account receives an XMPP message of a given type. When such a message is received that matches a registered event handler, the message is pushed as a client event to the client, instead of being stored on the broker, as an offline message. Note: For client events to be received on the client, you need to include the /Events.js javascript file on the page. This javascript file will register the current tab with the server, and enable it to receive asynchronous events from the server. If you are hosting the page on one server, and use the Agent API and Events API from another server, you need to include a meta header on the page, information the /Events.js javascript file where it will register itself to receive client events. To use this neuron, add the following to the HTML header of your page: You also need to inform the AgentAPI that you want to use another host, than the server used to host the page. You do this by making a call to AgentAPI.IO.SetHost(Host,Secure) as follows: ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Remove Roster Item Source: https://docs.neuro-tech.io/neuron-api/api-reference/messaging/remove-roster-item /test-api/openapi.yaml post /Agent/Xmpp/RemoveRosterItem Removes a specific roster item for the account. ## Overview Removes a specific roster item for the account. ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Send formatted message Source: https://docs.neuro-tech.io/neuron-api/api-reference/messaging/send-formatted-message /test-api/openapi.yaml post /Agent/Xmpp/SendFormattedMessage Send a Markdown message with text and HTML representations ## Overview Send a formatted chat message. Provide Markdown in `message` and the server creates plain text and HTML representations for recipients to choose from. ## Authentication Requires a valid JWT bearer token. # Send Presence Subscription Source: https://docs.neuro-tech.io/neuron-api/api-reference/messaging/send-presence-subscription /test-api/openapi.yaml post /Agent/Xmpp/SendPresenceSubscription Allows the client to send a presence subscription from its account to an XMPP recipient. ## Overview Allows the client to send a presence subscription from its account to an XMPP recipient. If the account to which the client is logged in has an approved Legal ID associated with it, this ID will be included in the request, to allow the recipient to know who has made the request. ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Send Presence Unsubscription Source: https://docs.neuro-tech.io/neuron-api/api-reference/messaging/send-presence-unsubscription /test-api/openapi.yaml post /Agent/Xmpp/SendPresenceUnsubscription Allows the client to send a presence unsubscription from its account to an XMPP recipient. ## Overview Allows the client to send a presence unsubscription from its account to an XMPP recipient. ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Send Subscription Accepted Source: https://docs.neuro-tech.io/neuron-api/api-reference/messaging/send-subscription-accepted /test-api/openapi.yaml post /Agent/Xmpp/SendSubscriptionAccepted Allows the client to accept a presence subscription made to its account. ## Overview Allows the client to accept a presence subscription made to its account. ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Send Subscription Declined Source: https://docs.neuro-tech.io/neuron-api/api-reference/messaging/send-subscription-declined /test-api/openapi.yaml post /Agent/Xmpp/SendSubscriptionDeclined Allows the client to decline a presence subscription made to its account. ## Overview Allows the client to decline a presence subscription made to its account. ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Send text message Source: https://docs.neuro-tech.io/neuron-api/api-reference/messaging/send-text-message /test-api/openapi.yaml post /Agent/Xmpp/SendTextMessage Send a plain text XMPP chat message ## Overview Send a plain text chat message from the authenticated account to an XMPP recipient. ## Authentication Requires a valid JWT bearer token. # Send Xml Message Source: https://docs.neuro-tech.io/neuron-api/api-reference/messaging/send-xml-message /test-api/openapi.yaml post /Agent/Xmpp/SendXmlMessage Allows the client to send a custom XML normal message from its account to an XMPP recipient. ## Overview Allows the client to send a custom XML normal message from its account to an XMPP recipient. ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Set Roster Item Source: https://docs.neuro-tech.io/neuron-api/api-reference/messaging/set-roster-item /test-api/openapi.yaml post /Agent/Xmpp/SetRosterItem Sets information about a specific roster item for the account. ## Overview Sets information about a specific roster item for the account. ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Add Source: https://docs.neuro-tech.io/neuron-api/api-reference/open-intelligence/add /test-api/openapi.yaml post /Agent/Intelligence/Add Allows the client to add open intelligence about an endpoint. ## Overview Allows the client to add open intelligence about an endpoint. ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Check Endpoint Source: https://docs.neuro-tech.io/neuron-api/api-reference/open-intelligence/check-endpoint /test-api/openapi.yaml post /Agent/Intelligence/CheckEndpoint Allows the client to check open intelligence of an endpoint. ## Overview Allows the client to check open intelligence of an endpoint. ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Delete Source: https://docs.neuro-tech.io/neuron-api/api-reference/open-intelligence/delete /test-api/openapi.yaml post /Agent/Intelligence/Delete Allows the client to delete open intelligence about an endpoint. ## Overview Allows the client to delete open intelligence about an endpoint. The intelligence information must have been created by the same agent, on the same domain to be able to be deleted. ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Get Source: https://docs.neuro-tech.io/neuron-api/api-reference/open-intelligence/get /test-api/openapi.yaml post /Agent/Intelligence/Get Allows the client to get open intelligence based on input search parameters. ## Overview Allows the client to get open intelligence based on input search parameters. You can search on endpoint, vector, protocol, classification, code or time interval. You can leave input fields empty. Only fields with non-empty values will restrict the result set in the search. Use the offset and max count arguments to implement pagination. ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Open intelligence Source: https://docs.neuro-tech.io/neuron-api/api-reference/open-intelligence/overview Agent API operations for publishing, querying, updating, deleting, and checking endpoint intelligence This page lists 5 Agent API operations generated from this repository's OpenAPI document. Open an operation to check its method, path, fields, and documented success response. ## Operations | Operation | Purpose | Authentication | | ------------------------------------------------------------------------------------------------------ | -------------- | -------------- | | [`POST /Agent/Intelligence/Add`](/neuron-api/api-reference/open-intelligence/add) | Add | JWT bearer | | [`POST /Agent/Intelligence/CheckEndpoint`](/neuron-api/api-reference/open-intelligence/check-endpoint) | Check Endpoint | JWT bearer | | [`POST /Agent/Intelligence/Delete`](/neuron-api/api-reference/open-intelligence/delete) | Delete | JWT bearer | | [`POST /Agent/Intelligence/Get`](/neuron-api/api-reference/open-intelligence/get) | Get | JWT bearer | | [`POST /Agent/Intelligence/Update`](/neuron-api/api-reference/open-intelligence/update) | Update | JWT bearer | ## Related guides No task guide currently links to these operations. Use the operation pages as reference material, not as an inferred multi-step procedure. ## Related * [Authorization and privileges](/neuron-api/authorization-and-privileges) * [Requests and responses](/neuron-api/requests-and-responses) # Update Source: https://docs.neuro-tech.io/neuron-api/api-reference/open-intelligence/update /test-api/openapi.yaml post /Agent/Intelligence/Update Allows the client to update open intelligence about an endpoint. ## Overview Allows the client to update open intelligence about an endpoint. The intelligence information must have been created by the same agent, on the same domain to be able to be updated. ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Agent API playground Source: https://docs.neuro-tech.io/neuron-api/api-reference/openapi/overview Browse Agent API operations and send requests to a development Neuron Use the playground to browse request and response schemas or send a request to a development Neuron. Do not enter production credentials in a shared browser or screen-sharing session. Most operations require a JWT bearer token. Follow the [authentication guide](/neuron-api/authentication) or call [Login](/neuron-api/api-reference/authentication-and-sessions/login) first. ## Endpoint groups * [Accounts & onboarding](/neuron-api/api-reference/accounts-and-onboarding/overview) * [Authentication & sessions](/neuron-api/api-reference/authentication-and-sessions/overview) * [Messaging](/neuron-api/api-reference/messaging/overview) * [Legal identities](/neuron-api/api-reference/legal-identities/overview) * [Contracts](/neuron-api/api-reference/contracts/overview) * [Wallet](/neuron-api/api-reference/wallet/overview) * [Tokens](/neuron-api/api-reference/tokens/overview) * [State machines](/neuron-api/api-reference/state-machines/overview) * [Storage](/neuron-api/api-reference/storage/overview) * [Cryptography](/neuron-api/api-reference/cryptography/overview) * [Open intelligence](/neuron-api/api-reference/open-intelligence/overview) # Use the Agent API reference Source: https://docs.neuro-tech.io/neuron-api/api-reference/overview Find request methods, paths, authentication rules, fields, and response schemas Use the generated operation pages to check an endpoint's method, path, authentication, request body, and documented success response. Start with [Authentication](/neuron-api/authentication) and [API basics](/neuron-api/api-basics) before implementing your first operation. ## Base URL ```text theme={null} https://{host} ``` Use the Neuron domain you were issued credentials for. Replace `{host}` with your Neuron server domain in all requests. ## Authentication Most endpoints require a JWT bearer token passed in the `Authorization` header: ```text theme={null} Referer: https://app.example.com/ Authorization: Bearer {token} ``` Obtain a token via [Login](/neuron-api/api-reference/authentication-and-sessions/login) or [Create account](/neuron-api/api-reference/accounts-and-onboarding/create-account). Some endpoints also require HMAC-signed requests — see the [Authentication guide](/neuron-api/authentication) for details. ## Browse by resource ### [Accounts and onboarding](/neuron-api/api-reference/accounts-and-onboarding/overview) Create and manage Neuron accounts, verify email and phone, recover access, and transfer accounts to other applications. ### [Authentication and sessions](/neuron-api/api-reference/authentication-and-sessions/overview) Log in, refresh tokens, authenticate JWTs, and manage session flows including Quick Login and WWW-Authenticate. ### [Messaging](/neuron-api/api-reference/messaging/overview) Send text and formatted XMPP messages, manage presence subscriptions, probe contacts, and maintain your roster. ### [Legal identities](/neuron-api/api-reference/legal-identities/overview) Apply for legal identities, attach supporting documents, request peer or service review, and petition for signatures or identity access. ### [Contracts](/neuron-api/api-reference/contracts/overview) Create and propose smart contract templates, send proposals to counterparties, sign contracts, and manage access authorization. ### [Wallet](/neuron-api/api-reference/wallet/overview) Query eDaler balances, process eDaler URIs, and initiate buy/sell flows through available service providers. ### [Tokens](/neuron-api/api-reference/tokens/overview) Inspect token metadata, query token events, retrieve creation attributes, and add text or XML notes to tokens. ### [State machines](/neuron-api/api-reference/state-machines/overview) Query the current state of a token's state machine and generate transition reports in multiple formats. ### [Storage](/neuron-api/api-reference/storage/overview) Save and load private XML, manage encrypted vault items, search vault contents, and create shareable vault links. ### [Cryptography](/neuron-api/api-reference/cryptography/overview) Discover available cryptographic algorithms, create signing keys, and retrieve server or account public keys. ### [Open intelligence](/neuron-api/api-reference/open-intelligence/overview) Publish, query, update, and delete open intelligence records about endpoints, and check endpoint status. ### [OpenAPI / playground](/neuron-api/api-reference/openapi/overview) Explore and test all endpoints interactively using the built-in OpenAPI playground. # Create Report Source: https://docs.neuro-tech.io/neuron-api/api-reference/state-machines/create-report /test-api/openapi.yaml post /Agent/StateMachines/CreateReport Creates a report relating to a state machine associated with a token. ## Overview Creates a report relating to a state machine associated with a token. ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Get Current State Source: https://docs.neuro-tech.io/neuron-api/api-reference/state-machines/get-current-state /test-api/openapi.yaml post /Agent/StateMachines/GetCurrentState Gets the current state of a state machine, associated with a token. ## Overview Gets the current state of a state machine, associated with a token. ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # State machines Source: https://docs.neuro-tech.io/neuron-api/api-reference/state-machines/overview Agent API operations for current state and state-machine reports This page lists 2 Agent API operations generated from this repository's OpenAPI document. Open an operation to check its method, path, fields, and documented success response. ## Start with * [Work with tokenized assets](/build/tokenized-assets/overview) ## Operations | Operation | Purpose | Authentication | | --------------------------------------------------------------------------------------------------------- | ----------------- | -------------- | | [`POST /Agent/StateMachines/CreateReport`](/neuron-api/api-reference/state-machines/create-report) | Create Report | JWT bearer | | [`POST /Agent/StateMachines/GetCurrentState`](/neuron-api/api-reference/state-machines/get-current-state) | Get Current State | JWT bearer | ## Related guides | Guide | Operations from this resource | | -------------------------------------------------------------------------------- | ------------------------------------------- | | [Build a tokenized product passport](/build/tokenized-assets/overview) | `POST /Agent/StateMachines/GetCurrentState` | | [Author a token with a machine and Script](/build/tokenized-assets/from-scratch) | `POST /Agent/StateMachines/GetCurrentState` | ## Related * [Neuro-Features and state machines](/concepts/neuro-features-and-state-machines) * [Tokens](/neuron-api/api-reference/tokens/overview) # Content storage availability Source: https://docs.neuro-tech.io/neuron-api/api-reference/storage/content Confirm whether your Neuron supports binary uploads before using the documented content resource Set `NEURON_REFERER` to your application's HTTPS URL. Include this header on every request, including backend calls. See [required request headers](/neuron-api/api-basics#required-referer-header). This resource is not included in the Agent API OpenAPI document. Confirm its paths, methods, headers, visibility rules, media types, and response fields on your Neuron before using it. The content resource stores binary files in the name of the authenticated account. Unlike most Agent endpoints, it uses normal HTTP content negotiation and supports `PUT`, multipart `POST`, `GET`, and `DELETE`. ## Resource paths ```text theme={null} /Agent/Storage/Content /Agent/Storage/Content/{account}/{contentId} ``` After an upload, use the returned `url` for reads, replacements, deletion, and sharing. A `contentId` can contain `/` path separators, but its final file extension must match the registered media type. ## Authentication Uploading, replacing, and deleting require the authenticated owner. Reading depends on the stored visibility: | Visibility | Who can retrieve the content | | ---------- | ------------------------------------------------------ | | `Public` | Anyone, without authentication | | `Presence` | Roster contacts with an approved presence subscription | | `Private` | Only the uploader | ## Upload with PUT Send the file bytes to a chosen resource path. The `Content-Type` must be recognized by the Neuron, and the extension in `contentId` must match it. ```bash theme={null} curl -X PUT \ "https://neuron.example/Agent/Storage/Content/alice/report.pdf" \ -H "Referer: ${NEURON_REFERER}" \ -H "Authorization: Bearer $NEURON_TOKEN" \ -H "Content-Type: application/pdf" \ -H "X-Visibility: Private" \ --data-binary @report.pdf ``` Omit a caller-selected ID only when using multipart `POST`; the server then derives one from the content ETag. ## Upload with multipart POST Post `multipart/form-data` to `/Agent/Storage/Content` with these fields: | Field | Required | Description | | ------------ | -------- | ----------------------------------------------------- | | `Content` | Yes | File body and its media type | | `ContentId` | No | Requested resource name; include a matching extension | | `Visibility` | Yes | `Public`, `Presence`, or `Private` | ```bash theme={null} curl -X POST "https://neuron.example/Agent/Storage/Content" \ -H "Referer: ${NEURON_REFERER}" \ -H "Authorization: Bearer $NEURON_TOKEN" \ -F "Content=@report.pdf;type=application/pdf" \ -F "ContentId=reports/quarterly.pdf" \ -F "Visibility=Private" ``` The JavaScript Agent library exposes the same operation as: ```javascript theme={null} const response = await AgentAPI.Storage.Upload( contentFile, "reports/quarterly.pdf", "Private" ); ``` ## Upload response Both upload methods return a content reference: ```json theme={null} { "uploaded": "2026-08-19T10:15:00Z", "visibility": "Private", "etag": "\"content-etag\"", "url": "https://neuron.example/Agent/Storage/Content/alice/reports/quarterly.pdf" } ``` | Field | Meaning | | ------------ | ---------------------------------------- | | `uploaded` | UTC upload time | | `visibility` | Effective access policy | | `etag` | Entity tag for the stored representation | | `url` | Canonical URL for subsequent operations | ## Retrieve, replace, or delete * `GET {url}` returns the original bytes with their stored `Content-Type` after applying the visibility rule. * `PUT {url}` replaces the owner's content and returns a new content reference. * `DELETE {url}` removes the owner's content. Use the ETag to identify versions in application state. A new upload can produce a new ETag even when the URL remains stable. ## Media-type restrictions The server accepts only registered, decodable media types. It rejects server-executable formats including `text/markdown`, `text/x-cssx`, and `application/x-webscript`; serving those from account storage could otherwise cross the boundary into server-side execution. To inspect the media types supported by the running Neuron, evaluate this in a privileged Script prompt: ```text theme={null} InternetContent.CanDecodeContentTypes ``` `Public` makes the returned URL anonymously readable. Do not use it for identity attachments, contract evidence, keys, or other confidential data. # Create Vault Link Source: https://docs.neuro-tech.io/neuron-api/api-reference/storage/create-vault-link /test-api/openapi.yaml post /Agent/Storage/CreateVaultLink Allows the client to create a secure link to a vault item, for distribution. ## Overview Allows the client to create a secure link to a vault item, for distribution. The client can set the number of times the link can be used, as well as an expiration time. ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Delete From Vault Source: https://docs.neuro-tech.io/neuron-api/api-reference/storage/delete-from-vault /test-api/openapi.yaml post /Agent/Storage/DeleteFromVault Allows the client to delete an item from its vault. ## Overview Allows the client to delete an item from its vault. It is only possible to delete items that have been stored using the same account. ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Get From Vault Source: https://docs.neuro-tech.io/neuron-api/api-reference/storage/get-from-vault /test-api/openapi.yaml post /Agent/Storage/GetFromVault Allows the client to get an item from the vault. ## Overview Allows the client to get an item from the vault. It is only possible to retrieve items that have been stored using the same account. ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Load Private Xml Source: https://docs.neuro-tech.io/neuron-api/api-reference/storage/load-private-xml /test-api/openapi.yaml post /Agent/Storage/LoadPrivateXml Allows the client to load previously saved private XML information from the server. ## Overview Allows the client to load previously saved private XML information from the server. ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Storage Source: https://docs.neuro-tech.io/neuron-api/api-reference/storage/overview Agent API operations for private XML and vault data This page lists 7 Agent API operations generated from this repository's OpenAPI document. Open an operation to check its method, path, fields, and documented success response. ## Operations | Operation | Purpose | Authentication | | -------------------------------------------------------------------------------------------- | ----------------- | -------------- | | [`POST /Agent/Storage/CreateVaultLink`](/neuron-api/api-reference/storage/create-vault-link) | Create Vault Link | JWT bearer | | [`POST /Agent/Storage/DeleteFromVault`](/neuron-api/api-reference/storage/delete-from-vault) | Delete From Vault | JWT bearer | | [`POST /Agent/Storage/GetFromVault`](/neuron-api/api-reference/storage/get-from-vault) | Get From Vault | JWT bearer | | [`POST /Agent/Storage/LoadPrivateXml`](/neuron-api/api-reference/storage/load-private-xml) | Load Private Xml | JWT bearer | | [`POST /Agent/Storage/SavePrivateXml`](/neuron-api/api-reference/storage/save-private-xml) | Save Private Xml | JWT bearer | | [`POST /Agent/Storage/SearchInVault`](/neuron-api/api-reference/storage/search-in-vault) | Search In Vault | JWT bearer | | [`POST /Agent/Storage/StoreInVault`](/neuron-api/api-reference/storage/store-in-vault) | Store In Vault | JWT bearer | ## Related guides No task guide currently links to these operations. Use the operation pages as reference material, not as an inferred multi-step procedure. ## Related * [Security and transport](/neuron-api/security-and-transport) * [Content storage availability](/neuron-api/api-reference/storage/content) # Save Private Xml Source: https://docs.neuro-tech.io/neuron-api/api-reference/storage/save-private-xml /test-api/openapi.yaml post /Agent/Storage/SavePrivateXml Allows the client to save private information on the server using XML. ## Overview Allows the client to save private information on the server using XML. ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Search In Vault Source: https://docs.neuro-tech.io/neuron-api/api-reference/storage/search-in-vault /test-api/openapi.yaml post /Agent/Storage/SearchInVault Allows the client to search for items in the vault. ## Overview Allows the client to search for items in the vault. It is only possible to retrieve items that have been stored using the same account. ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Store In Vault Source: https://docs.neuro-tech.io/neuron-api/api-reference/storage/store-in-vault /test-api/openapi.yaml post /Agent/Storage/StoreInVault Allows the client to store information security in the vault. ## Overview Allows the client to store information security in the vault. The information is stored encrypted is secure storage, complying with stricty industry standards such as PCI/DSS. The resource can be used to store new information, or to update existing information. Masks can be provided to the information, so that when it is retrieved later, only the masked information is returned. In return for storing the information in the vault, an opaque identifier is returned. This identifier can be safely stored by the client, and used to retrieve the information later. This allows the client to avoid storing sensitive information locally. ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Add Text Note Source: https://docs.neuro-tech.io/neuron-api/api-reference/tokens/add-text-note /test-api/openapi.yaml post /Agent/Tokens/AddTextNote Adds a text note to a token. ## Overview Adds a text note to a token. ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Add Xml Note Source: https://docs.neuro-tech.io/neuron-api/api-reference/tokens/add-xml-note /test-api/openapi.yaml post /Agent/Tokens/AddXmlNote Adds an XML note to a token. ## Overview Adds an XML note to a token. ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Get Contract Tokens Source: https://docs.neuro-tech.io/neuron-api/api-reference/tokens/get-contract-tokens /test-api/openapi.yaml post /Agent/Tokens/GetContractTokens Gets a list of tokens on the Neuron created by a specific contract. ## Overview Gets a list of tokens on the Neuron created by a specific contract. ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Get Creation Attributes Source: https://docs.neuro-tech.io/neuron-api/api-reference/tokens/get-creation-attributes /test-api/openapi.yaml post /Agent/Tokens/GetCreationAttributes Gets essential attributes needed for getting the Trust Provider to accept token creation contracts. ## Overview Gets essential attributes needed for getting the Trust Provider to accept token creation contracts. ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Get Description Source: https://docs.neuro-tech.io/neuron-api/api-reference/tokens/get-description /test-api/openapi.yaml post /Agent/Tokens/GetDescription Creates a report relating to a state machine associated with a token. ## Overview Creates a report relating to a state machine associated with a token. ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Get Token Source: https://docs.neuro-tech.io/neuron-api/api-reference/tokens/get-token /test-api/openapi.yaml post /Agent/Tokens/GetToken Gets information about a token. ## Overview Gets information about a token. ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Get Token Events Source: https://docs.neuro-tech.io/neuron-api/api-reference/tokens/get-token-events /test-api/openapi.yaml post /Agent/Tokens/GetTokenEvents Gets a list of token events. ## Overview Gets a list of token events. ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Get Tokens Source: https://docs.neuro-tech.io/neuron-api/api-reference/tokens/get-tokens /test-api/openapi.yaml post /Agent/Tokens/GetTokens Gets a list of tokens on the Neuron owned by the account. ## Overview Gets a list of tokens on the Neuron owned by the account. ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Tokens Source: https://docs.neuro-tech.io/neuron-api/api-reference/tokens/overview Agent API operations for inspecting Neuro-Features, creation attributes, notes, and event history This page lists 8 Agent API operations generated from this repository's OpenAPI document. Open an operation to check its method, path, fields, and documented success response. ## Start with * [Work with tokenized assets](/build/tokenized-assets/overview) * [Inspect token data](/neuron-api/guides/tokens-flow) ## Operations | Operation | Purpose | Authentication | | ------------------------------------------------------------------------------------------------------ | ----------------------- | -------------- | | [`POST /Agent/Tokens/AddTextNote`](/neuron-api/api-reference/tokens/add-text-note) | Add Text Note | JWT bearer | | [`POST /Agent/Tokens/AddXmlNote`](/neuron-api/api-reference/tokens/add-xml-note) | Add Xml Note | JWT bearer | | [`POST /Agent/Tokens/GetContractTokens`](/neuron-api/api-reference/tokens/get-contract-tokens) | Get Contract Tokens | JWT bearer | | [`POST /Agent/Tokens/GetCreationAttributes`](/neuron-api/api-reference/tokens/get-creation-attributes) | Get Creation Attributes | JWT bearer | | [`POST /Agent/Tokens/GetDescription`](/neuron-api/api-reference/tokens/get-description) | Get Description | JWT bearer | | [`POST /Agent/Tokens/GetToken`](/neuron-api/api-reference/tokens/get-token) | Get Token | JWT bearer | | [`POST /Agent/Tokens/GetTokenEvents`](/neuron-api/api-reference/tokens/get-token-events) | Get Token Events | JWT bearer | | [`POST /Agent/Tokens/GetTokens`](/neuron-api/api-reference/tokens/get-tokens) | Get Tokens | JWT bearer | ## Related guides | Guide | Operations from this resource | | -------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [Build a tokenized product passport](/build/tokenized-assets/overview) | `POST /Agent/Tokens/GetCreationAttributes`
`POST /Agent/Tokens/GetContractTokens`
`POST /Agent/Tokens/GetToken`
`POST /Agent/Tokens/GetTokenEvents` | | [Author a token with a machine and Script](/build/tokenized-assets/from-scratch) | `POST /Agent/Tokens/GetCreationAttributes`
`POST /Agent/Tokens/GetContractTokens`
`POST /Agent/Tokens/GetToken`
`POST /Agent/Tokens/AddTextNote`
`POST /Agent/Tokens/GetTokenEvents` | ## Related * [Neuro-Features and state machines](/concepts/neuro-features-and-state-machines) * [Contracts](/neuron-api/api-reference/contracts/overview) # Get Balance Source: https://docs.neuro-tech.io/neuron-api/api-reference/wallet/get-balance /test-api/openapi.yaml post /Agent/Wallet/GetBalance Allows the client to retrieve information about the current state of its wallet. ## Overview Allows the client to retrieve information about the current state of its wallet. ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Get Payment Options For Buying Edaler Source: https://docs.neuro-tech.io/neuron-api/api-reference/wallet/get-payment-options-for-buying-edaler /test-api/openapi.yaml post /Agent/Wallet/GetPaymentOptionsForBuyingEDaler Allows the client to initiate the process of getting payment options for buying eDaler. ## Overview Allows the client to initiate the process of getting payment options for buying eDaler. ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Get Payment Options For Selling Edaler Source: https://docs.neuro-tech.io/neuron-api/api-reference/wallet/get-payment-options-for-selling-edaler /test-api/openapi.yaml post /Agent/Wallet/GetPaymentOptionsForSellingEDaler Allows the client to initiate the process of getting payment options for selling eDaler. ## Overview Allows the client to initiate the process of getting payment options for selling eDaler. ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Get Service Providers For Buying Edaler Source: https://docs.neuro-tech.io/neuron-api/api-reference/wallet/get-service-providers-for-buying-edaler /test-api/openapi.yaml post /Agent/Wallet/GetServiceProvidersForBuyingEDaler Allows the client to retrieve a list of available service providers that can be used to buy eDaler. ## Overview Allows the client to retrieve a list of available service providers that can be used to buy eDaler. ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Get Service Providers For Selling Edaler Source: https://docs.neuro-tech.io/neuron-api/api-reference/wallet/get-service-providers-for-selling-edaler /test-api/openapi.yaml post /Agent/Wallet/GetServiceProvidersForSellingEDaler Allows the client to retrieve a list of available service providers that can be used to sell eDaler. ## Overview Allows the client to retrieve a list of available service providers that can be used to sell eDaler. ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Get Transaction Information Source: https://docs.neuro-tech.io/neuron-api/api-reference/wallet/get-transaction-information /test-api/openapi.yaml post /Agent/Wallet/GetTransactionInformation Allows the client to get updated transaction information from the server. ## Overview Allows the client to get updated transaction information from the server. It also allows the client to re-register the current Tab ID (from Events.js) and function to call, in case changes are registered with the server-side transaction object. Call this function to restart event notification if you navigate between pages. ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Initiate Buy Edaler Source: https://docs.neuro-tech.io/neuron-api/api-reference/wallet/initiate-buy-edaler /test-api/openapi.yaml post /Agent/Wallet/InitiateBuyEDaler Allows the client to initiate the process of buying eDaler, using a service provider that does not use a smart contract as the basis for the transaction (i.e. ## Overview Allows the client to initiate the process of buying eDaler, using a service provider that does not use a smart contract as the basis for the transaction (i.e. a service provider that will require the client to open a third-party page to complete the transaction). Note: Service Providers publishing a smart contract template as the basis of operation start processing transactions when the contract has been created and signed by the client and the Trust Provider. There is no need to initiate the process by calling this resource in such cases. ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Initiate Sell Edaler Source: https://docs.neuro-tech.io/neuron-api/api-reference/wallet/initiate-sell-edaler /test-api/openapi.yaml post /Agent/Wallet/InitiateSellEDaler Allows the client to initiate the process of selling eDaler, using a service provider that does not use a smart contract as the basis for the transaction (i.e. ## Overview Allows the client to initiate the process of selling eDaler, using a service provider that does not use a smart contract as the basis for the transaction (i.e. a service provider that will require the client to open a third-party page to complete the transaction). Note: Service Providers publishing a smart contract template as the basis of operation start processing transactions when the contract has been created and signed by the client and the Trust Provider. There is no need to initiate the process by calling this resource in such cases. ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Wallet Source: https://docs.neuro-tech.io/neuron-api/api-reference/wallet/overview Agent API operations for eDaler balances, providers, buy and sell initiation, and transaction lookup This page lists 9 Agent API operations generated from this repository's OpenAPI document. Open an operation to check its method, path, fields, and documented success response. ## Start with * [Build a payment integration](/build/payments/overview) ## Operations | Operation | Purpose | Authentication | | ------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------- | -------------- | | [`POST /Agent/Wallet/GetBalance`](/neuron-api/api-reference/wallet/get-balance) | Get Balance | JWT bearer | | [`POST /Agent/Wallet/GetPaymentOptionsForBuyingEDaler`](/neuron-api/api-reference/wallet/get-payment-options-for-buying-edaler) | Get Payment Options For Buying Edaler | JWT bearer | | [`POST /Agent/Wallet/GetPaymentOptionsForSellingEDaler`](/neuron-api/api-reference/wallet/get-payment-options-for-selling-edaler) | Get Payment Options For Selling Edaler | JWT bearer | | [`POST /Agent/Wallet/GetServiceProvidersForBuyingEDaler`](/neuron-api/api-reference/wallet/get-service-providers-for-buying-edaler) | Get Service Providers For Buying Edaler | JWT bearer | | [`POST /Agent/Wallet/GetServiceProvidersForSellingEDaler`](/neuron-api/api-reference/wallet/get-service-providers-for-selling-edaler) | Get Service Providers For Selling Edaler | JWT bearer | | [`POST /Agent/Wallet/GetTransactionInformation`](/neuron-api/api-reference/wallet/get-transaction-information) | Get Transaction Information | JWT bearer | | [`POST /Agent/Wallet/InitiateBuyEDaler`](/neuron-api/api-reference/wallet/initiate-buy-edaler) | Initiate Buy Edaler | JWT bearer | | [`POST /Agent/Wallet/InitiateSellEDaler`](/neuron-api/api-reference/wallet/initiate-sell-edaler) | Initiate Sell Edaler | JWT bearer | | [`POST /Agent/Wallet/ProcessEDalerUri`](/neuron-api/api-reference/wallet/process-edaler-uri) | Process Edaler Uri | JWT bearer | ## Related guides | Guide | Operations from this resource | | ------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [Inspect wallet data from an AI application backend](/build/ai-agents/overview) | `POST /Agent/Wallet/GetBalance` | | [Integrate a development eDaler purchase](/build/payments/buy-edaler) | `POST /Agent/Wallet/GetBalance`
`POST /Agent/Wallet/GetServiceProvidersForBuyingEDaler`
`POST /Agent/Wallet/GetPaymentOptionsForBuyingEDaler`
`POST /Agent/Wallet/InitiateBuyEDaler`
`POST /Agent/Wallet/GetTransactionInformation` | ## Related * [Wallets and payments](/concepts/wallets-and-payments) * [Rate limits](/neuron-api/rate-limits) # Process Edaler Uri Source: https://docs.neuro-tech.io/neuron-api/api-reference/wallet/process-edaler-uri /test-api/openapi.yaml post /Agent/Wallet/ProcessEDalerUri Allows the client to process an eDaler URI. ## Overview Allows the client to process an eDaler URI. ## Authentication Requires a valid JWT bearer token. ## Notes This endpoint uses the request schema notation described in [Pattern matching](/neuron-api/pattern-matching). # Agent API authentication Source: https://docs.neuro-tech.io/neuron-api/authentication Reference for login signatures, account creation signatures, and JWTs Use the [quickstart](/neuron-api/first-request) for a working login. This page documents the exact values that are signed. Include the [`Referer` header](/neuron-api/api-basics#required-referer-header) on every request, including signed login and account-creation requests and calls from a backend. ## Login Create a new nonce and build this UTF-8 string: ```text theme={null} userName:host:nonce ``` Compute Base64-encoded HMAC-SHA-256 using the **account password** as the HMAC key. Send `userName`, `nonce`, `signature`, and `seconds` to `POST /Agent/Account/Login`. The `host` value must exactly match the HTTP host used for the request, including a non-default port and excluding the scheme and path. ## Account creation Account creation is for a trusted backend that has an operator-issued Agent API key and secret. Without a phone number, sign: ```text theme={null} userName:host:eMail:password:apiKey:nonce ``` With a phone number, sign: ```text theme={null} userName:host:eMail:phoneNr:password:apiKey:nonce ``` Use the **API secret** as the HMAC key. Send the matching fields to `POST /Agent/Account/Create`. The field order, capitalization of values, empty values, and host must be identical between the message and request. Do not put an account-creation API secret in a browser, mobile application, public repository, or downloadable client. Use the browser-based onboarding flow or a trusted backend. ## JWTs Successful login returns a short-lived JWT. Send it on authenticated calls: ```text theme={null} Authorization: Bearer ``` * Keep JWTs out of URLs and logs. * The specification describes `Account/Refresh` and `Account/Logout`; verify their lifecycle behavior on the target deployment before relying on refresh or immediate invalidation. * Treat a stolen JWT as an active credential until it expires or its deployment has demonstrably invalidated it. ## HMAC test vector Use this deterministic vector to verify an implementation without contacting a Neuron: ```text theme={null} userName: alice host: neuron.example.com nonce: fixed-nonce password: correct horse battery staple message: alice:neuron.example.com:fixed-nonce HMAC-SHA-256 (Base64): KyuVbr8pHJ/FiMObl8rE+IbuwtzuC/TKuPl+I+Yjvic= ``` Use this fixed nonce only for the test vector. Generate a fresh cryptographic nonce for every real login request. ## Common signature failures | Symptom | Check | | ------------------------------------ | ---------------------------------------------------- | | Signature rejected | Exact canonical message and UTF-8 encoding | | Works locally but not through proxy | Host and forwarded host configuration | | Login signing uses API secret | Login must use the account password | | Create signing uses account password | Account creation must use the API secret | | Intermittent replay rejection | Generate a new cryptographic nonce for every request | # Authorization and privileges Source: https://docs.neuro-tech.io/neuron-api/authorization-and-privileges Separate bearer authentication from deployment-specific Agent API privileges Authentication proves which Agent API session is calling. Authorization decides whether that account may perform the requested operation. A valid JWT does not imply access to every resource group. ## What the API description establishes * Most operations inherit JWT bearer authentication. * Operations with `security: []` explicitly override that bearer requirement. * Some operation descriptions mention additional account, identity, key, or review prerequisites. The current OpenAPI document does not provide a complete machine-readable privilege name or role requirement for every operation. ## Application checklist 1. Read the generated operation's authentication requirement. 2. Identify the account, Legal Identity, key, contract role, provider, or operator prerequisite stated by the workflow. 3. Ask the Neuron operator for the narrowest role or privilege set that satisfies those requirements. 4. Test one permitted and one denied case in the target environment. 5. Treat a bearer token and the privileges of its account as separate security decisions. ## Do not infer privileges Do not copy privilege names from MCP scopes, administration roles, legacy pages, or a different deployment into Agent API code. Until operation-level privilege metadata is verified, the deployment owner is the source for the exact grant. Related: [Authentication](/neuron-api/authentication), [Security and transport](/neuron-api/security-and-transport), and [OpenAPI reference](/neuron-api/api-reference/openapi/overview). # Content types Source: https://docs.neuro-tech.io/neuron-api/content-types Set Content-Type and Accept correctly for Agent API requests and responses Agent API resources use the HTTP `Content-Type` header to interpret request bodies and `Accept` to select a response representation. Send both headers even when an operation currently documents only one representation; individual resources may support additional representations over time. ## Common representations | Media type | Meaning | | ------------------ | -------------------------------- | | `application/json` | JSON-encoded request or response | | `text/plain` | Plain text | | `text/xml` | XML document | Most documented Agent API operations use `POST` with JSON. Follow the generated operation's request body instead of assuming every resource accepts every media type. ## JSON request ```http theme={null} POST /Agent/Account/Info HTTP/1.1 Host: Referer: https://app.example.com/ Authorization: Bearer Accept: application/json Content-Type: application/json {} ``` An operation with no input fields still receives `{}` when its request body is required. ## Binary and attachment data Some operations represent attachment or binary content inside their documented JSON or XML request. Do not assume a generic `/files` endpoint or `multipart/form-data` contract. Use the exact request schema and encoding documented for that operation. ## Content negotiation failures * `400 Bad Request` can indicate that the body does not match the operation's schema. * `406 Not Acceptable` can indicate that the requested response representation is unsupported. * `415 Unsupported Media Type` may be returned by HTTP infrastructure when the request representation is unsupported; confirm the deployed behavior before depending on it. See [API basics](/neuron-api/api-basics) and the generated endpoint reference for operation-specific requirements. # Error handling Source: https://docs.neuro-tech.io/neuron-api/error-handling Handle Agent API failures without assuming an undocumented universal error schema Treat every non-2xx Agent API response and transport failure as an unsuccessful operation. The OpenAPI document describes successful `200` responses but does not define a universal error object, complete status-code set, or operation-specific retry rules. Do not implement against the older example containing `error.code`, `error.message`, and `requestId`. That shape has not been established as a common error format across Neuron deployments. ## Minimum client behavior 1. Record the operation, Neuron host, HTTP status when available, and a local correlation identifier. 2. Keep credentials, JWTs, personal data, contract attachments, and unreviewed upstream bodies out of browser responses and ordinary logs. 3. Preserve the raw status and body only in a protected server-side diagnostic path when policy permits it. 4. Parse a structured error only when the specific deployment or operation documents its schema. 5. Present a stable application-owned error to an untrusted client. Translate upstream failures into an application response your interface can handle. Preserve useful diagnostics in protected backend logs, and show the user the next action without exposing the raw upstream body. ## Retry decision Do not infer safety from the HTTP method: most current Agent API operations use `POST`, including both reads and state-changing commands. * Retry a read only when the application can tolerate repetition and the deployment's failure contract identifies the condition as transient. * Do not automatically retry signing, messaging, account creation, contract mutation, token mutation, or value-moving operations without a verified idempotency or reconciliation mechanism. * If the deployment returns a retry delay, honor the deployment's documented semantics; a common `Retry-After` behavior is not currently specified for all Neuron deployments. * Bound attempts, add jitter, and surface a terminal failure rather than creating an infinite authentication or command loop. See [Idempotency and replay](/neuron-api/idempotency-and-replay) and [Rate limits](/neuron-api/rate-limits) for the behavior to confirm with your provider. # Events and asynchronous state Source: https://docs.neuro-tech.io/neuron-api/events-and-asynchronous-state Observe Agent API workflows without treating request acceptance as completion Identity review, contract approval and signing, state-machine transitions, federation, and payment processing can outlive the HTTP request that initiated them. The public material describes several possible observation surfaces: | Surface | What is documented | | ----------------------------- | ----------------------------------------------------------------------------------- | | Retrieval or status operation | Prefer when the workflow defines a stable identifier and a documented query | | XMPP message retrieval | `PopMessages` returns stored messages; destructive clearing is a separate operation | | Browser event bridge | Interactive and tab-bound; not a durable server webhook | | MCP event tools | Depends on the MCP server actually deployed and authorized | | Operator or provider process | Required where review or approval is manual | The Agent API does not document one durable webhook mechanism for every operation. Confirm how the target Neuron reports completion before implementing background processing. ## State-handling pattern 1. Persist the returned domain identifier before leaving the initiating request. 2. Record an application-owned pending state. 3. Observe with the verified query, message, event, or operator-mediated mechanism. 4. Make repeated observations idempotent. 5. Distinguish approved/finalized, rejected/failed, expired, and still-pending outcomes. 6. Define a timeout and a human-visible recovery path. See [Realtime browser events](/neuron-api/guides/webhooks) for the documented interactive bridge. # Federation Source: https://docs.neuro-tech.io/neuron-api/federation Distinguish per-Neuron Agent API sessions from explicitly federated operations An Agent API account and its JWT belong to the Neuron host that issued them. Build a separate client and session for each host. Some documented operations can work with objects or actors on another Neuron. Examples in the current specification include retrieving or signing federated contracts and sending XMPP messages to another address. Remote Quick Login has a separate session-oriented description. ## Confirm support for each operation * Do not send a JWT to a different host. * Do not reuse a host-bound HMAC signature against another host. * Do not assume every identifier can be resolved or mutated across federation. * Use only the federation behavior explicitly described for the operation and verified on the target deployments. * Treat acceptance by the local Neuron and completion across the network as separate states when the workflow is asynchronous. See [Trust and federation](/concepts/trust-and-federation) for the conceptual model and [Events and asynchronous state](/neuron-api/events-and-asynchronous-state) for completion handling. # Sign in with an existing account Source: https://docs.neuro-tech.io/neuron-api/first-request Sign a login request, obtain a JWT, and retrieve your account over HTTPS Use your existing account credentials to sign in and retrieve account information. You can send these requests with any HTTP client or backend language. ## Before you start You need your account's exact HTTPS host, username, password, and a reachable HTTPS URL identifying your application. If you have an API key and secret instead, [create your sandbox account and identity](/neuron-api/quickstart) first. See [Get API access](/get-started/api-access) for both access options. For a sandbox account, use `sandbox.neuro-tech.io`. For another environment, use the host supplied by its operator. An account and its credentials belong to that environment. ## 1. Calculate the login signature Generate a fresh nonce from at least 32 cryptographically random bytes and encode it as Base64. Use that exact string in both the signed message and the request body. ```text theme={null} message = userName:host:nonce signature = Base64(HMAC-SHA256(key=UTF8(accountPassword), data=UTF8(message))) ``` Replace the names with their values, separated by colons with no added whitespace. The host excludes `https://` and paths, and includes the port if it is not the default. Use standard Base64 for the HMAC digest, not hexadecimal or Base64URL. The HMAC key is the account password. Check your language's implementation against the [authentication test vector](/neuron-api/authentication#hmac-test-vector). ## 2. Sign in Send this request over HTTPS, replacing the placeholders with your host, username, nonce, and calculated signature: ```http theme={null} POST /Agent/Account/Login HTTP/1.1 Host: Referer: https://your-app.example/ Accept: application/json Content-Type: application/json { "userName": "", "nonce": "", "signature": "", "seconds": 3600 } ``` Replace the example `Referer` with your application's URL. Include it on **every Agent API request**, including login and calls from a backend. Login does not require a bearer token. A successful response contains `jwt` and `expires`. Retain the JWT in your backend session and use the returned expiry when deciding whether to sign in again. See [Login reference](/neuron-api/api-reference/authentication-and-sessions/login) for the response schema. ## 3. Retrieve your account Copy the returned `jwt` into the `Authorization` header and send an empty JSON object: ```http theme={null} POST /Agent/Account/Info HTTP/1.1 Host: Referer: https://your-app.example/ Authorization: Bearer Accept: application/json Content-Type: application/json {} ``` Success is an account information response for the account you signed in with. Check its identity against the intended username and host before continuing. The [Account information reference](/neuron-api/api-reference/accounts-and-onboarding/info) describes the returned fields. ## Troubleshoot sign-in | Problem | What to check | | -------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- | | Signature rejected | Exact username, host, nonce, colon separators, UTF-8 input, and Base64 output. Sign with the account password. | | New sandbox account cannot sign in | Complete [sandbox account enablement](/neuron-api/quickstart#2-enable-the-sandbox-account). | | Login succeeds but account information fails | Send the returned JWT to the same host, include `Referer`, and check expiry and account access. | | A request fails or times out | Inspect the HTTP status using [error handling](/neuron-api/error-handling). Generate a new nonce for another login attempt. | ## Continue building [Add Neuro to your application](/get-started/first-application), or use your session to [apply for a Legal Identity](/neuron-api/guides/applying-for-a-legal-identity) and [create a contract](/contracts/from-scratch). # Apply for a Legal Identity Source: https://docs.neuro-tech.io/neuron-api/guides/applying-for-a-legal-identity Create an identity application, upload its evidence, and submit it for review through the Agent API Create the identity application, attach the required photos or documents, then call `ReadyForApproval` to start review. `ApplyId` alone does not complete this sequence. For account and key creation in the sandbox, start with the [Agent API quickstart](/neuron-api/quickstart). The requests below work with your provider's HTTPS host and requirements. ## Before you start You need an enabled account, its JWT and account password, and the signing key used for the application. Retain the key's `keyId`, `localName`, `namespace`, and key password. Keep credentials and identity evidence in your backend. Send `Referer` on every Agent API request, including backend calls. Replace the host and other placeholders in the examples below. ## 1. Get the application requirements ```http theme={null} POST /Agent/Legal/GetApplicationAttributes HTTP/1.1 Host: Referer: https://your-app.example/ Authorization: Bearer Accept: application/json Content-Type: application/json {} ``` The response includes `Required` property names, `nrPhotos`, `peerReview`, and `nrReviewers`. Use these with the selected review provider's requirements to decide which properties and attachments to collect. Ask the provider which document types and image formats it accepts; a photo count does not identify the required documents. ## 2. Create the application Submit the required properties using [Apply ID](/neuron-api/api-reference/legal-identities/apply-for-id). The [quickstart's application step](/neuron-api/quickstart#5-apply-for-a-test-legal-identity) shows the complete request and signature calculation; replace its test properties with the ones required for your application. Retain the returned `Identity.id` as `legalId`. Attachments must be added to your own identity while `Identity.status.state` is `Created`, before submitting it for review. ## 3. Prepare each attachment Read the file as bytes and Base64-encode those bytes. Use plain Base64 without a `data:image/...;base64,` prefix. Send one file per request. | Request field | What to supply | | ----------------------- | ----------------------------------------------------------------------------------------- | | `attachmentBase64` | The Base64-encoded file bytes. | | `attachmentFileName` | A filename identifying the evidence, such as `ProfilePhoto.jpg`. | | `attachmentContentType` | The actual media type, such as `image/jpeg` or `image/png`. It must match the file bytes. | | `legalId` | The `Identity.id` returned by `ApplyId`. | | `keyId` | The signing key used for this application. | Automated review services can use the filename to recognize a document. Confirm which of these names your reviewer requires: | Filename without extension | Evidence | | ----------------------------------------- | ------------------------------------------------------ | | `ProfilePhoto` | Profile photograph. | | `IdCardFront`, `IdCardBack` | Front and back of a national identity card. | | `Passport` | Personal-information and signature pages in one image. | | `DriverLicenseFront`, `DriverLicenseBack` | Front and back of a driver's license. | Use the extension matching your file format, for example `IdCardFront.png`. Upload only the evidence needed for the selected review method. See the [original attachment reference](https://lab.tagroot.io/Documentation/Neuron/Agent/Legal/AddIdAttachment.md) for recognized names. ## 4. Sign and upload the attachment Define `HMAC(secret, message)` as Base64-encoded HMAC-SHA-256 using the UTF-8 secret and UTF-8 message. Generate a fresh nonce from 32 random bytes encoded as Base64 for each upload. Build these strings by joining the actual values with `:` in exactly this order: ```text theme={null} keyMessage = userName:host:localName:namespace:keyId keySignature = HMAC(keyPassword, keyMessage) message = keyMessage:keySignature:nonce:attachmentBase64:attachmentFileName:attachmentContentType:legalId requestSignature = HMAC(accountPassword, message) ``` The `host` must match the request's HTTP host, without the scheme or path. Sign the exact filename, content type, Base64 value, and identity identifier you send. Do not change the file or re-encode it after signing. ```http theme={null} POST /Agent/Legal/AddIdAttachment HTTP/1.1 Host: Referer: https://your-app.example/ Authorization: Bearer Accept: application/json Content-Type: application/json { "keyId": "", "legalId": "", "nonce": "", "keySignature": "", "requestSignature": "", "attachmentBase64": "", "attachmentFileName": "ProfilePhoto.jpg", "attachmentContentType": "image/jpeg" } ``` [Add ID Attachment](/neuron-api/api-reference/legal-identities/add-id-attachment) signs the file with the selected key, attaches it to the application, and returns the updated `Identity`. You do not need a separate `SignData` call or a multipart upload. Check the updated identity for the attachment reference and retain it with `legalId`. Repeat for each required file, using a fresh nonce and request signature. Wait for every upload to succeed before continuing. ## 5. Mark the application ready for approval Call `ReadyForApproval` after all required properties and attachments are present to start the configured review, even when no attachments are required. In the sandbox, [an identity may already be automatically approved](/neuron-api/quickstart#6-upload-the-required-attachments). If its current state is `Approved`, skip `ReadyForApproval`; it requires an identity still in `Created` state. Using the same `keyMessage` and a new nonce, calculate: ```text theme={null} keySignature = HMAC(keyPassword, keyMessage) message = keyMessage:keySignature:nonce:legalId requestSignature = HMAC(accountPassword, message) ``` ```http theme={null} POST /Agent/Legal/ReadyForApproval HTTP/1.1 Host: Referer: https://your-app.example/ Authorization: Bearer Accept: application/json Content-Type: application/json { "keyId": "", "legalId": "", "nonce": "", "keySignature": "", "requestSignature": "" } ``` [Ready For Approval](/neuron-api/api-reference/legal-identities/ready-for-approval) returns `Identity`. The request starts review; its HTTP success does not guarantee approval. ## 6. Observe the result ```http theme={null} POST /Agent/Legal/GetIdentity HTTP/1.1 Host: Referer: https://your-app.example/ Authorization: Bearer Accept: application/json Content-Type: application/json {"legalId":""} ``` Read `Identity.status.state`. Continue to signing or other identity-dependent actions only after the identity is `Approved`. While review is pending, poll at a bounded interval or use your Neuron's event mechanism. See [Observe Legal Identity review](/neuron-api/guides/getting-your-identity-approved). The signature formulas and request order are checked locally. Upload and review outcomes still need testing with your provider. ## Recover from an incomplete application | Problem | Next step | | ------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | | Attachment signature rejected | Check the exact Base64 value, filename, media type, host, identity ID, field order, and passwords. Use a new nonce for a corrected request. | | Invalid attachment | Check that the Base64 decodes to a file matching its content type and the provider's accepted format. | | Identity is no longer `Created` | Retrieve its state. Do not try to append evidence to an approved identity; ask the operator how to correct or replace the application. | | Upload times out | Retrieve the identity and inspect its attachments before uploading again. | | Identity remains `Created` | Confirm all required uploads succeeded and `ReadyForApproval` was accepted, then check the review status with the operator. | | Readiness request times out | Retrieve the identity before retrying; review may already have started. | Keep attachment bytes, identity documents, passwords, and JWTs out of logs, URLs, analytics, and error reports. Persist identity and attachment references for recovery. # Browser-based signup Source: https://docs.neuro-tech.io/neuron-api/guides/browser-based-signup Create and activate an Agent account from a browser without exposing an API secret All Agent API calls need `Referer`. Browsers manage this header; the fetch examples use the page origin and `strict-origin` policy. See [required request headers](/neuron-api/api-basics#required-referer-header). Use the web-form endpoint when an untrusted browser must create an account directly. Unlike the JSON [Create account](/neuron-api/api-reference/accounts-and-onboarding/create-account) flow, the browser flow uses reCAPTCHA and redirects rather than exposing the account-creation API key to JavaScript. Before launch, test the signup and redirect flow with your application's actual origin, cookie settings, and reCAPTCHA configuration. ## Prerequisites The Neuron operator must: * configure Google reCAPTCHA; * create an API key whose owner is `Agent API` and whose account limit has not been reached; * configure email delivery and, if phone verification is required, SMS delivery; * serve the signup page over HTTPS. Removing the API key or setting its limit to the current account count disables public account creation. ## Submit the form Serve the signup page with `Referrer-Policy: strict-origin` so the browser includes its origin as `Referer` when submitting the form. Render the reCAPTCHA widget and submit a normal HTML form to `/Agent/Account/CreateWebForm`: ```html theme={null}
``` The endpoint consumes form data, not JSON. The redirect target must be an application URL you trust; do not copy a redirect URL from arbitrary query input. ## Recover the new session After the Neuron redirects the browser, preserve its session cookie and exchange the creation session for account state: ```js theme={null} const response = await fetch( "https://neuron.example/Agent/Account/GetSessionToken", { method: "POST", credentials: "include", referrer: window.location.origin + "/", referrerPolicy: "strict-origin", headers: { "Content-Type": "application/json" }, body: JSON.stringify({}) } ); if (!response.ok) throw new Error(`Session exchange failed: ${response.status}`); const result = await response.json(); ``` The created account starts disabled. Ask the user for the code delivered to their email and call [Verify email](/neuron-api/api-reference/accounts-and-onboarding/verify-email). If a phone number was supplied, complete [phone verification](/neuron-api/api-reference/accounts-and-onboarding/verify-phone-number) too. Keep the returned JWT in memory where possible. Never place it in a URL, page source, analytics event, or browser log. # Follow the contract API lifecycle Source: https://docs.neuro-tech.io/neuron-api/guides/contracts-flow Create a contract, prepare a proposal, collect signatures, and retrieve the result Contracts are created and signed using approved Legal Identities. Contract proposals are XMPP messages sent through `POST /Agent/Xmpp/SendXmlMessage`; there is no `POST /Agent/Legal/SendProposal` server resource. ## Lifecycle ```mermaid theme={null} sequenceDiagram participant Initiator participant Source as Initiator's Neuron participant Target as Counterparty's Neuron participant Counterparty Initiator->>Source: Legal/CreateContract Source-->>Initiator: Contract object Initiator->>Source: Legal/SignContract for assigned role Initiator->>Source: Xmpp/SendXmlMessage(contractProposal) Source->>Target: XMPP proposal stanza Counterparty->>Target: Xmpp/PopMessages or receive event Counterparty->>Target: Legal/GetContract Counterparty->>Target: Legal/SignContract for assigned role Target-->>Counterparty: Contract with final state ``` ## Follow the lifecycle 1. Create a contract from an approved template with `Legal/CreateContract`. Assign each approved Legal Identity to its exact role. 2. Have the initiating party retrieve and review the returned contract, then sign its assigned role. 3. [Send a `contractProposal` stanza](/neuron-api/api-reference/contracts/send-proposal) to the counterparty's bare or full JID. A `sent: true` response confirms sending, not receipt or acceptance. 4. Confirm the counterparty received the matching `contractId` and `role`, then retrieve the contract with `Legal/GetContract`. 5. Show the counterparty the exact returned human-readable contract. Treat explicit user confirmation as the acceptance boundary. 6. Sign the counterparty's role with `Legal/SignContract`. 7. Retrieve the contract again and verify the state required by the template. Confirm every required role signature instead of treating a successful HTTP response as completion. ## Construct a contract signature Use the algorithm metadata stored with `keyId`: ```text theme={null} s1 = username:HTTP-Host:localName:namespace:keyId keySignature = Base64(HMAC-SHA256(key=UTF8(keyPassword), data=UTF8(s1))) s2 = s1:keySignature:nonce:legalId:contractId:role requestSignature = Base64(HMAC-SHA256(key=UTF8(accountPassword), data=UTF8(s2))) ``` `HTTP-Host` must match the request header exactly, including a non-default port. Generate `nonce` from at least 32 random bytes, Base64-encode it, and never reuse it. ## Related endpoints * [Propose a contract template](/neuron-api/api-reference/contracts/propose-contract-template) * [Create a contract](/neuron-api/api-reference/contracts/create-contract) * [Send a proposal over XMPP](/neuron-api/api-reference/contracts/send-proposal) * [Sign a contract](/neuron-api/api-reference/contracts/sign-contract) * [Get contract](/neuron-api/api-reference/contracts/get-contract) # Create an account from a trusted backend Source: https://docs.neuro-tech.io/neuron-api/guides/creating-an-account Create and verify an account from a backend that can protect the API secret For the Neuro sandbox, follow the [account and identity quickstart](/neuron-api/quickstart), which uses public account enablement and automatic test-identity approval. The guide below covers the general provider-managed process. Use this guide only when a trusted backend can protect the operator-issued account-creation API key and secret. For public clients, use [browser-based signup](/neuron-api/guides/browser-based-signup). ## Expected result ```text theme={null} Operator-approved creation credentials ↓ Account creation request signed for the exact Neuron host ↓ Required email and phone verification ↓ Enabled account and a fresh authenticated session ``` ## Prerequisites * Exact Neuron host and environment semantics. * Account-creation API key and secret from that Neuron's operator. * Operator-confirmed account quota and verification policy. * A trusted backend secret store. * A user interaction for collecting and confirming required contact details. ## Procedure 1. Optionally retrieve `GET /Agent/Account/DomainInfo` and confirm the user selected the intended Neuron. 2. Read the generated `POST /Agent/Account/Create` schema and its signature message. Sign the documented canonical message with the API secret; do not replace it with a signature over only the nonce. 3. Submit the account request from the backend and retain only the safe identifiers, status, and session state the application needs. 4. Complete the required `VerifyEMail` and `VerifyPhoneNr` operations for the deployment. 5. Establish a fresh session through the verified login flow rather than assuming the creation response represents a fully enabled account. 6. Retrieve `Account/Info` and verify the resulting account state. ## Security notes * Never send the account-creation API secret to a browser or mobile binary. * Bind every signature to the exact documented fields and host. * Generate a fresh unpredictable nonce for every signed request. * Do not log passwords, secrets, nonces, verification codes, or returned JWTs. * Apply user-interface throttling without inventing undocumented server rate limits or retry windows. ## Verification The workflow is complete only when the account state returned by the target Neuron satisfies its activation policy and the user can establish a new session. Account activation does not create or approve a Legal Identity. ## Next * [Create a cryptographic key](/neuron-api/guides/creating-cryptographic-keys) * [Apply for a Legal Identity](/neuron-api/guides/applying-for-a-legal-identity) * [Accounts and onboarding reference](/neuron-api/api-reference/accounts-and-onboarding/overview) # Create an Agent API cryptographic key Source: https://docs.neuro-tech.io/neuron-api/guides/creating-cryptographic-keys Choose an algorithm, create encrypted key material through the Neuron, and retain its reference Agent API key creation asks the Neuron to create and store encrypted key material for supported signing workflows. This differs from a direct XMPP client that manages its own private keys. ## Expected result ```text theme={null} Authenticated Agent API session ↓ Supported algorithm selected ↓ Signed key-creation request ↓ Encrypted key stored by the Neuron ↓ Stable key reference retained for identity and signing workflows ``` ## Procedure 1. Call `POST /Agent/Crypto/GetAlgorithms` with the documented empty JSON body. 2. Select an algorithm accepted by the relying identity or contract workflow; do not hard-code an algorithm merely because one Neuron returns it. 3. Choose a unique `id` for the key. This caller-supplied value is the `keyId` used by later identity and signing operations. 4. Calculate the signatures using the formulas below. 5. Submit the request and retain the submitted `id`, `localName`, and `namespace`. 6. Retrieve the public key through `POST /Agent/Crypto/GetPublicKey` when the relying workflow needs verification material. ## State to retain | Value | Why | | --------------------------------------------------- | ---------------------------------------------------------- | | Neuron host | Key references are deployment-bound | | Local name and namespace | Locate the application key without relying on display text | | Key identifier required by later operations | Bind identity and signing requests to the intended key | | Algorithm and creation metadata returned by the API | Support validation, rotation, and audit decisions | Never store a key password or account password beside these identifiers. `CreateKey` returns `created` and `updated`; it does not return a generated `keyId`. ## Construct the request The signed messages use colon separators with no whitespace: ```text theme={null} s1 = username:HTTP-Host:localName:namespace:id keySignature = Base64(HMAC-SHA256(key=UTF8(keyPassword), data=UTF8(s1))) s2 = s1:keySignature:nonce requestSignature = Base64(HMAC-SHA256(key=UTF8(accountPassword), data=UTF8(s2))) ``` `HTTP-Host` is the exact value sent in the HTTP `Host` header, including a non-default port. Generate `nonce` from at least 32 cryptographically random bytes, encode it as Base64, and do not reuse it. ```http theme={null} POST /Agent/Crypto/CreateKey HTTP/1.1 Host: Referer: https://your-app.example/ Authorization: Bearer Accept: application/json Content-Type: application/json { "localName": "", "namespace": "", "id": "agreement-key", "nonce": "", "keySignature": "", "requestSignature": "" } ``` Send the request over HTTPS using your [authenticated session](/neuron-api/first-request) and application URL as `Referer`. Use the same `id` in the signed message and JSON body. Store that submitted identifier with the account and Legal Identity that will use it. See [Create key reference](/neuron-api/api-reference/cryptography/create-key). ## Next * [Keys and signatures](/concepts/keys-and-signatures) * [Apply for a Legal Identity](/neuron-api/guides/applying-for-a-legal-identity) * [Cryptography reference](/neuron-api/api-reference/cryptography/overview) # Observe Legal Identity review Source: https://docs.neuro-tech.io/neuron-api/guides/getting-your-identity-approved Select a supported review method and handle pending, approved, or rejected outcomes For the Neuro sandbox, follow the [account and identity quickstart](/neuron-api/quickstart), which uses public account enablement and automatic test-identity approval. The guide below covers the general provider-managed process. After creating the application, [upload its required attachments and call `ReadyForApproval`](/neuron-api/guides/applying-for-a-legal-identity#3-prepare-each-attachment) to start review. The sandbox may approve the identity earlier: if its current state is already `Approved`, skip `ReadyForApproval` and continue with that identity. ## Choose the deployed review method Use `GetApplicationAttributes` and the supported service-provider operations to discover what the Neuron actually offers. A deployment might use operator review, an identity review service, peer review, or another configured policy. If the chosen reviewer requires explicit access, grant only the documented identity access for that review and record how it is revoked afterward. ## Application state model ```text theme={null} Draft in application ↓ Application created and attachments uploaded ↓ ReadyForApproval accepted ↓ Pending review ├── approved/current └── rejected or correction required ``` Use the status returned by `GetIdentity` rather than mapping it to a guessed enum. Store the raw status plus the application state your user interface needs. ## Observe completion 1. Persist the Legal Identity/application identifier returned earlier. 2. Use the event, message, callback, or polling mechanism confirmed for the target Neuron. 3. Make repeated observations idempotent so the same result is not applied twice. 4. Retrieve the current identity before enabling a trust-dependent application action. 5. Surface rejection or correction information without leaking identity evidence. ## Completion The workflow is complete when the relying application has retrieved the identity's current status and evaluated it against its own provider and assurance policy. “Request accepted” and “review pending” are not successful identity verification. ## Next * [Agreements](/build/agreements/overview) * [Tokenized assets](/build/tokenized-assets/overview) * [Trust and federation](/concepts/trust-and-federation) # Legal Identity flow Source: https://docs.neuro-tech.io/neuron-api/guides/legal-identity-flow Map the key, application, evidence, submission, and review checkpoints For the Neuro sandbox, follow the [account and identity quickstart](/neuron-api/quickstart), which uses public account enablement and automatic test-identity approval. The guide below covers the general provider-managed process. Use this map to coordinate account, key, application, evidence, and review state. Open the linked guides for procedures and the API reference for exact fields. Ask the operator which identity review method and required fields apply to your Neuron. ```text theme={null} Account active for the required operations ↓ Create and retain a cryptographic key reference ↓ Get deployment-specific application requirements ↓ Submit the signed Legal Identity application ↓ Attach the required evidence ↓ Call ReadyForApproval to start review ↓ Observe pending → approved/current or rejected ``` ## Checkpoints | Checkpoint | Do not continue until | | ------------ | ----------------------------------------------------------------------------------- | | Account | The target Neuron reports the account state required by the operation | | Key | The application retained the exact key reference used for signing | | Requirements | Required properties, evidence, and review options came from the target deployment | | Application | The Legal Identity/application identifier and status were persisted | | Submission | Required attachments are present and `ReadyForApproval` succeeded | | Review | The current identity was retrieved and accepted by the relying application's policy | ## Related guides * [Create an account](/neuron-api/guides/creating-an-account) * [Create a key](/neuron-api/guides/creating-cryptographic-keys) * [Apply for a Legal Identity](/neuron-api/guides/applying-for-a-legal-identity) * [Observe review](/neuron-api/guides/getting-your-identity-approved) * [Verified identity overview](/build/verified-identity/overview) # Login flows Source: https://docs.neuro-tech.io/neuron-api/guides/login-flows Choose an Agent API, browser-session, remote, or OAuth login flow All Agent API calls need `Referer`. Browsers manage this header; the fetch examples use the page origin and `strict-origin` policy. See [required request headers](/neuron-api/api-basics#required-referer-header). Neuron has two related authentication surfaces in the available specifications: Agent API JWTs authorize HTTP API calls, while HTTP session login authorizes browser access to hosted pages and administration. Start with [Sign in with an existing account](/neuron-api/first-request) for a complete HTTP example. For browser or cross-Neuron login, choose a method enabled by your provider. | Client | Start with | Result | | ------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------- | | First-party back end with Agent credentials | [Login](/neuron-api/api-reference/authentication-and-sessions/login) | Agent API JWT. | | Browser or native app acting for a user | [OAuth Authorization Code with PKCE](/protocols/oauth) | Scoped OAuth access and optional refresh token. | | Terminal, appliance, or input-constrained device | [OAuth device authorization](/protocols/oauth) | Scoped OAuth access after approval on another device. | | Browser already authenticated with Quick Login | [Quick login](/neuron-api/api-reference/authentication-and-sessions/quick-login) | Agent API JWT for an account on the same Neuron. | | Browser opening a different Neuron | Prepare locally, then [remote quick login](/neuron-api/api-reference/authentication-and-sessions/remote-quick-login) remotely | HTTP session on the remote Neuron; no remote Agent JWT. | | Legacy HTTP-auth client | [WWW login](/neuron-api/api-reference/authentication-and-sessions/www-login) | Agent API JWT. Prefer another flow for new work. | ## Direct Agent login The direct flow sends the login request, receives `jwt` and `expires`, and uses the token as `Authorization: Bearer `. The specification describes [Refresh](/neuron-api/api-reference/authentication-and-sessions/refresh) and [Logout](/neuron-api/api-reference/authentication-and-sessions/logout); verify their deployed lifecycle behavior before depending on it. Use the Agent API's documented signing rules. A request signed for a different host or a reused nonce can fail even when the username and password are correct. ## Documented Quick Login shape Quick Login depends on the current HTTP session, so send cookies: ```js theme={null} const response = await fetch("/Agent/Account/QuickLogin", { method: "POST", credentials: "include", referrer: window.location.origin + "/", referrerPolicy: "strict-origin", headers: { "Content-Type": "application/json" }, body: JSON.stringify({ seconds: 900 }) }); const { jwt, userName, expires } = await response.json(); ``` ## Documented Remote Quick Login sequence 1. On the Neuron where the Agent is connected, call `PrepareRemoteQuickLogin` with its JWT and retain `legalId`. 2. In the browser session for the target Neuron, call `RemoteQuickLogin` with that Legal ID and a user-visible purpose. 3. The user's client receives and signs the petition. 4. Inspect `loggedIn` and `petitionSent`. Confirm that successful approval creates the expected HTTP session on the target Neuron. Do not assume the remote call creates an Agent API JWT for the remote broker. If an administrator-associated identity can gain administrative access, confirm the required permissions and approval UI before enabling the flow. ## Token handling * Request the shortest practical lifetime; Agent endpoints limit `seconds` to 3600. * Store refresh tokens only in encrypted server-side or storage protected by the operating system. * Validate `expires` instead of assuming a lifetime. * Never send a token to a different Neuron host. * Treat account, legal-identity, and OAuth scopes as separate authorization decisions. # Send XMPP messages Source: https://docs.neuro-tech.io/neuron-api/guides/messaging Send text or formatted XMPP chat messages Neuron uses XMPP for messaging. The Agent API lets you send messages without a persistent XMPP connection. ## Message sequence ```mermaid theme={null} sequenceDiagram participant Client participant Neuron Client->>Neuron: Account/Login (HMAC) Neuron-->>Client: JWT Client->>Neuron: Xmpp/SendTextMessage (JWT) Neuron-->>Client: sent + message id Client->>Neuron: Xmpp/SendFormattedMessage (JWT) Neuron-->>Client: sent + message id ``` ## Find the recipient JID A JID is the XMPP address of a user, such as `alice@neuron.example.com`. You can retrieve JIDs from your roster or directory services provided by your Neuron. ## Send a message * [Send text messages](/neuron-api/api-reference/messaging/send-text-message) * [Send formatted messages](/neuron-api/api-reference/messaging/send-formatted-message) # Inspect Neuro-Features and event history Source: https://docs.neuro-tech.io/neuron-api/guides/tokens-flow Retrieve Neuro-Features, creation attributes, notes, and events Neuro-Features represent assets or rights created through approved contracts. This guide starts with an existing feature identifier and shows how to inspect its metadata and history. To create a new asset, follow [Author a token with a state machine and Script](/build/tokenized-assets/from-scratch). ## Prerequisites * The exact Neuron host and an authenticated account with the required privileges. * An existing Neuro-Feature identifier supplied by your application or operator. * Permission to read the related contract, attributes, state, notes, or events required by your application. ## Request sequence ```mermaid theme={null} sequenceDiagram participant Client participant Neuron Client->>Neuron: Tokens/GetTokens Neuron-->>Client: list Client->>Neuron: Tokens/GetToken Neuron-->>Client: token details Client->>Neuron: Tokens/GetTokenEvents Neuron-->>Client: event history ``` ## Related operations * [Get creation attributes](/neuron-api/api-reference/tokens/get-creation-attributes) * [Add text note](/neuron-api/api-reference/tokens/add-text-note) * [Add XML note](/neuron-api/api-reference/tokens/add-xml-note) * [Get contract tokens](/neuron-api/api-reference/tokens/get-contract-tokens) ## Next step Persist the feature identifier and the latest state your application observed. Follow only the state transitions and transfer procedure confirmed for the feature's approved contract and target Neuron. # User onboarding Source: https://docs.neuro-tech.io/neuron-api/guides/user-onboarding Create, verify, and activate a Neuron account Use this flow when you want to create a Neuron account from a trusted back-end service and guide the user to a verified, active session. Before collecting user details, confirm the required account fields, contact verification, and identity review method with the Neuron operator. ## Account creation sequence ```mermaid theme={null} sequenceDiagram participant Client participant Neuron Client->>Neuron: Account/DomainInfo (optional) Client->>Neuron: Account/Create (HMAC + API key) Neuron-->>Client: JWT + disabled account Client->>Neuron: Account/VerifyEMail (code) Neuron-->>Client: verified Client->>Neuron: Account/Login (HMAC) Neuron-->>Client: JWT ``` ## Create and verify the account 1. Optional: call `Account/DomainInfo` to show a human-friendly domain name. 2. Call `Account/Create` to create the account and receive an initial JWT. 3. Prompt the user to enter the email verification code. 4. Call `Account/VerifyEMail` to enable the account. 5. Call `Account/Login` to obtain a fresh JWT for ongoing use. Read the generated operation pages before implementing each request. Do not copy older account-creation examples that sign only a nonce; account creation and login use different secrets and different canonical messages. ## Common pitfalls * Reusing a nonce will invalidate the request. * An unverified account cannot use most endpoints. * If login fails after verification, check the host used for signing. ## Add a Legal Identity * [Create the identity application and upload its required evidence](/neuron-api/guides/applying-for-a-legal-identity), then call `ReadyForApproval` to start review. Skip readiness if the sandbox has already approved the identity. * Use [Legal Identity flow](/neuron-api/guides/legal-identity-flow) to track the account, key, application, attachment, and review stages. * Review [Authentication](/neuron-api/authentication). # Realtime browser events Source: https://docs.neuro-tech.io/neuron-api/guides/webhooks Route incoming XMPP messages to a live browser tab through Neuron's event channel The Agent API does not expose a generic server-to-server webhook registration endpoint. It can route matching incoming XMPP messages to a live browser tab through Neuron's client-event system. Use this for interactive applications; use [message polling](/neuron-api/api-reference/messaging/pop-messages) or your own durable queue consumer for background processing. ## 1. Load the event client Include `/Events.js` from the Neuron so the page receives a tab ID and maintains its event channel. When the page and API use different hosts, declare the event server in the page metadata as required by that deployment and configure the Agent client host with `AgentAPI.IO.SetHost(host, secure)`. Cross-origin deployments also need correct CORS, cookie, and TLS configuration. Do not relax origins globally to make the event channel work. ## 2. Register a handler After the event client has assigned a tab ID, register the most specific match you need: ```http theme={null} POST /Agent/Xmpp/RegisterEventHandler HTTP/1.1 Referer: https://app.example.com/ Authorization: Bearer Content-Type: application/json { "localName": "alert", "namespace": "urn:example:alerts:1", "type": "normal", "function": "onAlert", "tabId": "" } ``` All match fields are optional. A specific local name and namespace wins over a broader fallback. `function` names the browser callback. Leaving it empty unregisters that match. ```js theme={null} window.onAlert = event => { // Validate the event shape and escape any rendered message content. console.log("Alert received", event); }; ``` When a message matches a live registration, Neuron pushes it to the tab instead of storing it as an offline message. Therefore, browser delivery is not durable. ## 3. Design for disconnects * register again when a page reloads or receives a new tab ID; * make handlers idempotent because reconnect races can cause repeat work; * poll [Pop messages](/neuron-api/api-reference/messaging/pop-messages) after reconnect when missing a message is unacceptable; * use the narrowest local-name, namespace, and stanza-type match; * unregister handlers no longer needed by sending the same selector with an empty `function`. # Idempotency and replay Source: https://docs.neuro-tech.io/neuron-api/idempotency-and-replay Avoid duplicating Agent API commands while idempotency remains operation-specific The OpenAPI document does not define an idempotency header, idempotency-key store, or replay window shared by all Agent API operations. ## Safe default Classify an operation before retrying it: | Operation kind | Default behavior | | -------------------------------------------------------- | ------------------------------------------------------------------------------------- | | Read or inspection | A bounded retry may be acceptable after verifying the deployment's transient failures | | Create, sign, send, transfer, clear, delete, or initiate | Do not automatically retry without reconciliation or a verified idempotency contract | | Login or signed request | Generate a fresh nonce for a new attempt; never replay the identical signed request | ## Application-owned reconciliation Where the API accepts a stable identifier, generate and persist it before sending the command. After an ambiguous failure, query by that identifier before deciding to issue another command. This is an application pattern, not proof that every endpoint deduplicates it. For value movement, signatures, contracts, identity submissions, and messages, obtain operation-specific rules from the Neuron operator before enabling automated retries. # Agent API Source: https://docs.neuro-tech.io/neuron-api/introduction Start building Neuro applications through HTTPS and find the exact operation reference The **Agent API** is Neuro's application-facing HTTP API. Use it to work with accounts, Legal Identities, contracts, tokens, wallets, messaging, and storage. Its name is unrelated to AI agents. Create an account with your API key, enable it in the sandbox, and obtain an approved test identity. ## Get connected You need the **exact HTTPS host** supplied by your service provider and **either**: * **An API key and its secret** to [create an account](/neuron-api/guides/creating-an-account), then sign in. * **Existing account credentials (username and password)** to [sign in directly](/neuron-api/first-request). Follow [Get API access](/get-started/api-access) to obtain these details and choose your next step. ```text theme={null} https:///Agent/... ``` Each provider supplies its own API host. Most operations use a JWT in the Authorization header. Login and account creation use the signed requests explained in [authentication](/neuron-api/authentication). **Every Agent API request must include `Referer`, including backend calls.** Set it to your application's URL. See [required request headers](/neuron-api/api-basics#required-referer-header). ## Add the capabilities your application needs | Task | Guide | Exact reference | | --------------------------------- | ------------------------------------------------------ | ----------------------------------------------------------------------- | | Establish reviewed identity | [Verified identity](/build/verified-identity/overview) | [Legal identities](/neuron-api/api-reference/legal-identities/overview) | | Create and sign agreements | [Contracts](/contracts/quickstart) | [Contract operations](/neuron-api/api-reference/contracts/overview) | | Work with contract-created assets | [Tokens](/build/tokenized-assets/overview) | [Token operations](/neuron-api/api-reference/tokens/overview) | | Inspect balances and transactions | [Payments](/build/payments/overview) | [Wallet operations](/neuron-api/api-reference/wallet/overview) | | Send messages and receive results | [Messaging](/neuron-api/guides/messaging) | [Message operations](/neuron-api/api-reference/messaging/overview) | Use normal HTTP libraries. Follow [application architecture](/get-started/choose-integration) for browser/backend responsibilities. Author custom XML with [schemas and examples](/resources/overview) when your workflow needs it. # Assignment pattern notation Source: https://docs.neuro-tech.io/neuron-api/pattern-matching Read the assignment pattern-matching notation used to describe Agent API inputs Some legacy Agent API pages describe input content using Neuron Script assignment pattern-matching notation. This notation documents request shape and validation; it is not an HTTP query-filter language. ## Common patterns | Pattern | Meaning | | ------------------------------------- | -------------------------------------------------- | | `Required(Str(PUserName))` | A required string assigned to `PUserName` | | `Optional(Int(PSeconds))` | An optional integer assigned to `PSeconds` | | `Required(Int(0 < PSeconds <= 3600))` | A required integer satisfying the stated range | | `Optional(DateTime(PExpires))` | An optional date-time value assigned to `PExpires` | ## How to read a pattern 1. The outer `Required` or `Optional` expression describes presence. 2. The inner expression describes the expected value type. 3. A condition inside the type expression describes validation. 4. The `P...` variable names correspond to values consumed by the resource implementation; the JSON field names come from the operation's documented request schema. ## Canonical application contract Application developers should use the generated OpenAPI schema for exact JSON field names, types, and required properties. Pattern notation remains documented so legacy examples and implementation-oriented reference material can be interpreted correctly. Do not translate these expressions into `GET /v1/...?...` filters. The Agent API publishes resources below `/Agent` and normally uses `POST` unless an individual resource states otherwise. # Create your sandbox account and identity Source: https://docs.neuro-tech.io/neuron-api/quickstart Use an API key to create an account, enable it in the Neuro sandbox, and obtain an automatically approved test identity over HTTPS Start with an API key and secret from your broker/Neuron operator. By the end, you will have an enabled sandbox account, an authenticated session, a signing key, and an approved test Legal Identity. The examples show HTTP requests you can send from any backend language or API client. If you already have an account, use [Sign in with an existing account](/neuron-api/first-request). ## 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 `Referer` on every request. A public project page can serve this purpose. Use the sandbox over **HTTPS**: ```text theme={null} https://sandbox.neuro-tech.io ``` In signed messages, the host is exactly `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 ```mermaid theme={null} flowchart LR Create[Create account with API key] --> Enable[Enable sandbox account] Enable --> Login[Sign in for a JWT] Login --> Key[Create signing key] Key --> Apply[Apply for a Legal Identity] Apply --> State{Already Approved?} State -->|Yes| Approved[Continue with approved identity] State -->|No| Attach[Upload required attachments] Attach --> Ready[ReadyForApproval] Ready --> Observe[Observe automatic approval] Observe --> Approved ``` 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. Define `HMAC(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: ```text theme={null} message = userName:host:eMail:password:apiKey:nonce signature = HMAC(apiSecret, message) ``` Join the actual values with `:` 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](/neuron-api/authentication#account-creation). Send the following request, replacing every placeholder: ```http theme={null} POST /Agent/Account/Create HTTP/1.1 Host: sandbox.neuro-tech.io Referer: https://your-app.example/ Accept: application/json Content-Type: application/json { "userName": "", "eMail": "", "password": "", "apiKey": "", "nonce": "", "signature": "", "seconds": 3600, "language": "en" } ``` No bearer token is needed. The API secret is used locally for signing and is not included in the request. The response includes `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](/neuron-api/api-reference/accounts-and-onboarding/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: ```http theme={null} POST /hackathon-contract-approver/account/enable HTTP/1.1 Host: sandbox.neuro-tech.io Referer: https://your-app.example/ Accept: application/json Content-Type: application/json {"account":""} ``` Use the account's **username**, not its Legal Identity ID or full JID. No API key, password, or JWT is required for this sandbox helper. Expected response shape: ```json theme={null} { "account": "", "enabled": true, "already_enabled": false } ``` Repeating this enablement request is supported; `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: ```text theme={null} message = userName:host:nonce signature = HMAC(accountPassword, message) ``` ```http theme={null} POST /Agent/Account/Login HTTP/1.1 Host: sandbox.neuro-tech.io Referer: https://your-app.example/ Accept: application/json Content-Type: application/json { "userName": "", "nonce": "", "signature": "", "seconds": 3600 } ``` Keep the returned `jwt` in memory. Send it as `Authorization: Bearer ` on the remaining `/Agent/` requests. Confirm the account with: ```http theme={null} POST /Agent/Account/Info HTTP/1.1 Host: sandbox.neuro-tech.io Referer: https://your-app.example/ Authorization: Bearer Accept: application/json Content-Type: application/json {} ``` Confirm the response refers to your account and reports it as enabled. Login does not itself create a Legal Identity. ## 4. Select an algorithm and create a signing key Call [`POST /Agent/Crypto/GetAlgorithms`](/neuron-api/api-reference/cryptography/get-algorithms) 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: ```text theme={null} keyMessage = userName:host:localName:namespace:keyId keySignature = HMAC(keyPassword, keyMessage) requestSignature = HMAC(accountPassword, keyMessage:keySignature:nonce) ``` ```http theme={null} POST /Agent/Crypto/CreateKey HTTP/1.1 Host: sandbox.neuro-tech.io Referer: https://your-app.example/ Authorization: Bearer Accept: application/json Content-Type: application/json { "localName": "", "namespace": "", "id": "sandbox-identity-key", "nonce": "", "keySignature": "", "requestSignature": "" } ``` Success returns `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](/neuron-api/api-reference/legal-identities/get-application-attributes) 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**: ```text theme={null} keySignature = HMAC(keyPassword, keyMessage) message = keyMessage:keySignature:nonce:FN:Alex:LN:Sandbox requestSignature = HMAC(accountPassword, message) ``` ```http theme={null} POST /Agent/Legal/ApplyId HTTP/1.1 Host: sandbox.neuro-tech.io Referer: https://your-app.example/ Authorization: Bearer Accept: application/json Content-Type: application/json { "keyId": "sandbox-identity-key", "nonce": "", "keySignature": "", "requestSignature": "", "Properties": [ {"name":"FN","value":"Alex"}, {"name":"LN","value":"Sandbox"} ] } ``` Replace `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 or `ReadyForApproval`. Check `Identity.status.state` using [GetIdentity](#8-confirm-automatic-approval). **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](/neuron-api/guides/applying-for-a-legal-identity#3-prepare-each-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 to `Approved`, `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: ```text theme={null} keySignature = HMAC(keyPassword, keyMessage) message = keyMessage:keySignature:nonce:legalId requestSignature = HMAC(accountPassword, message) ``` ```http theme={null} POST /Agent/Legal/ReadyForApproval HTTP/1.1 Host: sandbox.neuro-tech.io Referer: https://your-app.example/ Authorization: Bearer Accept: application/json Content-Type: application/json { "keyId": "sandbox-identity-key", "legalId": "", "nonce": "", "keySignature": "", "requestSignature": "" } ``` The response contains `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 after `ReadyForApproval`: ```http theme={null} POST /Agent/Legal/GetIdentity HTTP/1.1 Host: sandbox.neuro-tech.io Referer: https://your-app.example/ Authorization: Bearer Accept: application/json Content-Type: application/json {"legalId":""} ``` Wait for `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 | Value | Purpose | | --------------------------------------- | --------------------------------------------------------------------------- | | Sandbox host and username | Identify the account used by your application. | | Account password | Authorize login and signed requests; keep it in your secret store. | | `jwt` and `expires` | Authenticate requests for the current session. | | `keyId`, `localName`, `namespace` | Identify the signing key and its algorithm. | | Key password | Authorize use of the signing key; store it separately from public metadata. | | `legalId` and observed `Approved` state | Identify the sandbox identity used in later signing workflows. | Continue with [contract authoring](/contracts/from-scratch) or [a token with a state machine and Script](/build/tokenized-assets/from-scratch). 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. ## Troubleshoot a blocked step | Symptom | Check | | ------------------------------------------ | ------------------------------------------------------------------------------------------------------------------ | | API key not found or account limit reached | Use a key issued for this sandbox and ask its operator about the quota. | | Username already exists | Use a new username, or sign in to the existing account. | | Login fails after creation | Enable the exact username through the sandbox helper before logging in. | | Signature invalid | Check the secret used, exact host, field order, UTF-8 encoding, and Base64 output. | | Identity application rejects `Referer` | Supply a reachable application URL, including on backend requests. | | Identity remains `Created` | Confirm uploads completed and `ReadyForApproval` succeeded, then poll or contact the operator; do not apply again. | | Request times out after a write | Check the account or identity already created before resending the write. | ## Move beyond the sandbox Use the host and credentials supplied for your production Neuron. Replace sandbox enablement with the required contact-verification process, and automatic identity approval with the provider's evidence and review procedure. See [account creation](/neuron-api/guides/creating-an-account) and [identity approval](/neuron-api/guides/getting-your-identity-approved). # Rate limits Source: https://docs.neuro-tech.io/neuron-api/rate-limits Plan for deployment-specific Agent API limits without assuming undocumented headers The OpenAPI document does not define a shared request quota, burst limit, `429` response schema, or `Retry-After` behavior for all Neuron deployments. Before production, obtain from the Neuron operator: * limits by account, credential, IP, operation, and time window; * whether login, recovery, creation, messaging, and value-moving operations have separate limits; * the response status, headers, and body used when a limit is reached; * the correct retry delay and escalation path; * monitoring signals for sustained throttling. Clients should bound concurrency and retry attempts even when the deployment publishes no limit. Do not interpret an absent published limit as unlimited capacity. # Requests and responses Source: https://docs.neuro-tech.io/neuron-api/requests-and-responses Build Agent API requests from the generated operation pages Use the generated operation page as the contract for path, method, security override, required fields, and documented success shape. ## Requests * Build URLs as `https:///Agent//`. * Use the generated method. Most current operations use `POST`; `GET /Agent/Account/DomainInfo` is the documented exception. * Send `Content-Type: application/json`. * Send [`Referer`](/neuron-api/api-basics#required-referer-header) with your application's URL on every request, including backend calls. * Send `{}` when a documented `POST` operation has an empty JSON request. * Preserve field names and capitalization exactly; examples include both lower-camel-case fields and capitalized collection fields. * Do not add a shared `/v1` prefix. ## Responses The specification documents `200` success responses. Some contain a JSON object with required fields, some allow additional deployment fields, and some have no documented body schema. Validate required fields before using them and ignore unknown fields unless the operation says otherwise. A `200` response shape does not establish business completion for an asynchronous workflow. Persist the returned identifier and observe the later state using the mechanism verified for that workflow. No single schema currently defines non-success response bodies across all Agent API operations. See [Error handling](/neuron-api/error-handling). # Security and transport Source: https://docs.neuro-tech.io/neuron-api/security-and-transport Protect Agent API credentials and verify deployment-specific transport controls ## TLS / HTTPS Agent API URLs use HTTPS: ```text theme={null} https:// ``` Use the exact host supplied by the operator. The public documentation does not yet define a minimum TLS version, certificate policy, mutual-TLS option, proxy topology, or IP-allowlisting contract covering all Neuron deployments. Obtain those controls from the deployment owner before production. ## Credential management * Store account passwords, account-creation API keys and secrets, and JWTs in a secrets manager or protected runtime configuration—never hardcode them. * Never log full JWT tokens or HMAC secrets in your application logs. * If a credential may be compromised, stop using it and follow the rotation or account-recovery procedure supplied by the Neuron operator. A universal rotation API is not currently documented. ## Keep trusted credentials out of public clients * Never embed an account-creation API secret or trusted account password in browser or mobile code. * Put trusted Agent API calls behind an application backend. * Return only fields the user-facing client needs. * Keep JWTs out of URLs, analytics, crash reports, and browser-visible errors. * Verify cookies, CORS, redirect origins, and CSRF protection for the exact browser flow and deployment. ## Storage and logging The documentation does not establish one encryption-at-rest algorithm or automatic masking policy for every Neuron deployment. Classify the data your application stores, minimize it, encrypt it according to the deployment's approved policy, and redact logs at the application boundary. Never log account passwords, API secrets, full JWTs, authorization headers, private keys, or unreviewed identity and contract payloads. # Versioning and compatibility Source: https://docs.neuro-tech.io/neuron-api/versioning Identify Agent API URLs and confirm compatibility with your Neuron version Agent API resources are published below the per-Neuron `/Agent` path. The documentation currently has no verified basis for a shared central `/v1` base URL, so examples must not use one. ## URL model ```text theme={null} https:///Agent// ``` For example: ```text theme={null} https://neuron.example.com/Agent/Account/Info ``` ## Confirm compatibility Neuro does not currently publish a compatibility, deprecation, or sunset policy covering all Neuron deployments. Until one is available: * do not claim a `v1` URL contract; * do not claim a fixed deprecation window; * do not claim that a particular HTTP status will be used after sunset; * record the tested Neuron build or deployment alongside executable examples; * test the documented operations against the Neuron build you will use before release. A successful request against one Neuron deployment does not establish compatibility with other deployments. Confirm the deployed build and operator policy before production rollout. ## Ask the operator Before production, ask how the deployment handles: 1. How a client identifies the API/runtime version. 2. Which changes are considered additive or breaking. 3. How deprecations are announced. 4. How long deprecated behavior remains available. 5. Which API and schema versions your application targets. 6. Where release notes and migration guides are published. # Glossary Source: https://docs.neuro-tech.io/overview/glossary Key terms and concepts used in Neuro This page explains the key terms you will encounter when building with Neuro. You do not need to understand every term before you begin, but having a shared vocabulary makes the rest of the documentation much easier to follow. The runtime and broker that applications connect to when using Neuro services. It enables secure, federated interaction across domains and hosts higher-level capabilities such as identities, contracts, tokens, and ledger-backed services. The distributed audit and persistence layer used by Neuro services. It is designed to support auditable, distributed systems without depending on a traditional blockchain model. A trusted actor within a domain that validates identities, approves or governs identities and contracts, and contributes trust to the network through signatures and policy. Often described as a digital equivalent of a notary. The identity used to participate in the network as a connected actor or account. It identifies the account communicating with a Neuron or another participant. A stronger, cryptographically protected identity tied to a real legal actor such as a person or organization. Legal identities are used when trust, signatures, ownership, or compliance matter. A structured digital agreement. In Neuro, smart contracts combine human-readable and machine-readable content, support signatures and lifecycle rules, and are designed to work across domains. A digital instrument tied to ownership, agreements, and traceable events. In Neuro, tokens can represent NFTs, asset-backed instruments, rights, or other digital and cyber-physical assets. Neuro's token model for digital instruments and tokenized assets. Neuro-Features are created using smart contracts and can represent ownership, rights, or asset-backed structures. A federated digital payment mechanism used in Neuro. It can be linked to contracts, tokens, and programmable payment flows. A model where multiple domains manage their own infrastructure but still interoperate in a shared framework. Federation is a core part of how Neuro supports cross-domain interaction. A distinct operating boundary in the federated network. Each domain can manage its own users, services, policies, and trust relationships. A cryptographic proof attached to an identity, contract, or other signed data to verify integrity and authorship. Signatures are central to how Neuro establishes trust. The part of a cryptographic key pair used to validate signatures or encrypted interactions. The secret part of a cryptographic key pair used to create signatures. Agent API key operations use key material stored encrypted by the Neuron and invoked through the Agent interface. A structured model for representing workflows as states and allowed transitions over time. In Neuro, state machines can be connected to contracts, tokens, and programmable payment logic. Neuro's main HTTP API. The caller acts through a Neuron's Agent endpoint instead of connecting directly over XMPP while holding the corresponding private keys. The name is unrelated to artificial-intelligence agents. The federated communication protocol underlying the Neuron's communication model. It provides the base for secure, cross-domain messaging and interaction. The ability to inspect and verify what happened, who acted, and what was recorded. Auditability is one of the main reasons Neuro uses Neuro-Ledger together with signatures and identities. ## Go deeper See how the main components relate at runtime. Start with the Agent API, connect an MCP client, or find an application guide. # What is a Neuron? Source: https://docs.neuro-tech.io/overview/what-is-the-neuron Understand the service that hosts your account and exposes the Agent API A **Neuron** is the service your application connects to for Neuro capabilities. Its provider supplies an HTTPS endpoint and provisions the accounts and permissions for that environment. Depending on its enabled capabilities, a Neuron provides accounts, identity services, contracts, tokens, wallets, messaging, and access to auditable records. Different environments can enable different services. ## How your application uses it Your backend calls `https:///Agent/...`. It authenticates for an account, sends the required operation, and retrieves the resulting object or state. The [Agent API quickstart](/neuron-api/quickstart) demonstrates the first request. The Neuron also communicates with other services and Neurons. These relationships matter when an agreement involves participants from different domains; see [trust and federation](/concepts/trust-and-federation). You need access to an existing service to follow these application guides. Get its address, account credentials, supported build, and development-data policy through [API access](/get-started/api-access). # OAuth 2 authorization server Source: https://docs.neuro-tech.io/protocols/oauth Register clients, authorize scopes, issue JWTs, use device flow, and introspect tokens Current Neuron builds can act as an OAuth 2 authorization server. ## Endpoints | Purpose | Path | Standard | | --------------------------- | ----------------------------------------- | ------------- | | Authorization | `/oauth/authorize` | RFC 6749 | | Token | `/oauth/token` | RFC 6749 | | Dynamic registration | `/oauth/register` | RFC 7591/7592 | | Registration management | `/oauth/registration` | RFC 7592 | | Device authorization | `/oauth/device` | RFC 8628 | | Introspection | `/oauth/introspect` | RFC 7662 | | Authorization metadata | `/.well-known/oauth-authorization-server` | RFC 8414 | | Protected-resource metadata | `/.well-known/oauth-protected-resource` | RFC 9728 | PKCE and refresh tokens are supported. Use server metadata to discover the grants, signing algorithms, and client-authentication methods enabled by the running build. ## Choose a flow * **Authorization Code + PKCE:** browser/mobile/desktop clients acting for a user. * **Device authorization:** terminal, appliance, or agent without a usable browser. * **Confidential client:** server-side application able to protect a secret. * **mTLS or Neuron authentication exchange:** deployment-specific trusted client flows. Do not use the implicit grant for new applications. ## Scopes to privileges Neuron authorization is role-based. OAuth scopes map to privileges prefixed with `OAUTH.Scope.`, with colons changed to periods. An authenticated client receives a token only for scopes its backing account can authorize. ## Dynamic registration The operator enables dynamic registration by creating an API key named `OAUTH`. Registrations are limited per remote endpoint. A registration creates a corresponding XMPP account with no useful privileges and normal XMPP communication disabled by default. ## Branding login pages OAuth login UI is produced from Markdown and embedded into `MasterOAuth.md` in the web root. Package and version customizations; preserve CSRF, redirect-URI, consent, and error placeholders when changing the layout. ## Security checklist * exact-match redirect URIs; * PKCE for public clients; * short-lived access tokens and protected refresh tokens; * least-privilege scope grants; * WAF restrictions for `/oauth/` where appropriate; * never log codes, tokens, secrets, or verifier values; * revoke/disable abandoned clients. # Communication and interoperability Source: https://docs.neuro-tech.io/protocols/overview Understand the protocols behind application-visible identity, messaging, and data Neuro combines HTTPS application requests with interoperable identity, messaging, and data formats. Your application uses the Agent API; underlying protocols explain how participants and services can communicate across domains. ## What matters in API requests A participant may be addressed by a JID such as `alice@neuron.example.com`. XML namespaces identify the meaning of a contract or message. A namespace is an exact identifier, so similar names or older versions are not interchangeable. Use the format documented for the operation. [Contract proposals](/neuron-api/api-reference/contracts/send-proposal), for example, are submitted to an HTTP endpoint with an XML payload. The Neuron manages delivery over its configured messaging services. ## Learn the related concepts * [Trust and federation](/concepts/trust-and-federation) explains cross-domain participants. * [Harmonized IoT interfaces](/iot/harmonized-interfaces) explains shared device data models. * [Schema resources](/resources/schemas) identify the formats used by contracts and tokens. * [Messaging through the Agent API](/neuron-api/guides/messaging) shows application requests. # Refresh reports for a dashboard Source: https://docs.neuro-tech.io/reports/dashboard-integration Run reports on a backend schedule, cache completed results, and provide a controlled manual refresh. Run a report in a backend job and serve its last successful result to your dashboard. Report execution can be expensive. Opening, reloading, or navigating a dashboard should read cached data rather than start another report. ## Choose a refresh policy Agree on data freshness and execution frequency with your provider before enabling recurring runs. Choose one of these policies: | Policy | When to use it | Behavior | | ----------------------------- | -------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------- | | Scheduled | Users need a regularly updated summary. | A backend scheduler starts a job at the agreed interval. All viewers share its cached result. | | Manual | Reports are needed occasionally. | An authorized user requests a refresh; the backend queues one job and returns immediately. | | Scheduled with manual refresh | Users normally accept scheduled data but occasionally need a newer result. | Manual requests use the same queue, concurrency limit, and cooldown as scheduled jobs. | For daily statistics, once per day after the reporting day closes is a reasonable starting proposal. For example, `0 2 * * *` on a scheduler explicitly configured for UTC means 02:00 UTC daily. This example is an application choice, not a service limit or a guarantee that the provider's data is complete at that time. Confirm the time and acceptable data age with your provider. ## Separate execution from dashboard reads ```mermaid theme={null} flowchart LR S[Backend schedule] --> Q[Refresh queue] M[Authorized manual refresh] --> Q Q --> W[One report worker] W --> A[Agent API] A --> W W --> C[Last successful result] C --> B[Dashboard backend] B --> D[Dashboard viewers] ``` The report worker signs in, resolves the target, submits the report, and collects progress to completion. It replaces the cached result only after checking completion, errors, and the expected output. See [Run a report over HTTP](/reports/execute-over-http) for the API sequence. Keep the Agent API password and JWT in the backend. Browser users authenticate to your application and receive only the data they are allowed to see. An expired Agent API JWT does not invalidate an already completed cached report. ## Prevent duplicate work * Acquire a shared lock before starting a refresh. Use a lock shared across backend instances, not just an in-memory browser flag. * If a matching job is already running, return its status instead of submitting another execution. * Apply a server-side cooldown to manual requests. Disabling a button alone does not prevent duplicate requests. * Skip or coalesce a scheduled refresh when the previous one is still active. * Do not tie report submission to component mounting, page loads, UI polling, or each viewer's session. With `PopMessages`, use one consumer for the Agent API account and dispatch messages by their query ID. For an initial integration, serialize report runs for that account. Competing consumers can take each other's progress messages. The [execution guide](/reports/execute-over-http#collect-progress-messages) explains why polling consumes account messages. ## Choose explicit report parameters Calculate the reporting window once when the job starts, in the report's documented time zone. Persist those dates with the result so the dashboard shows the actual period that was requested. For a UTC report, two possible policies are: * Previous complete day: yesterday for both start and end dates, if the report uses inclusive dates. * Trailing seven complete days: UTC today minus seven days through UTC yesterday, if dates are inclusive. Confirm the report's date semantics rather than inferring them from its filename. Current-state metrics and lifetime counters may be independent of the selected dates. Show both the reporting period and the result's completion time. If the report has optional parameters that save snapshots or perform other writes, leave them unset for ordinary dashboard refreshes unless that behavior is intended. Do not assume a report is read-only because it produces statistics. ## Store the last successful result Scope the cache to the authorized tenant or account, Neuron host, Reports JID, report ID, language, and normalized parameter values. Avoid sharing cached data across tenants merely because the report ID matches. Store the completed output together with: | Metadata | Purpose | | --------------------- | ---------------------------------------------------------------- | | Requested parameters | Identify the exact date window and options. | | Query ID | Correlate execution with diagnostics. | | Completion timestamp | Show when the cached result was last refreshed. | | Last attempt status | Show whether a refresh is queued, running, completed, or failed. | | Expected next refresh | Explain when new data is normally due. | Keep the previous successful result while a new run is in progress. If the new run fails, retain the previous result and label it as stale with the last successful refresh time. An aborted query, a timeout, or an incomplete table must not replace a complete cached result. ## Handle manual refresh and first use An authorized refresh request should enqueue work and return a job status from your backend. The browser can poll your backend for that status; each status poll must not execute another Neuron report. When the job completes, the dashboard reads the updated cache. Before any successful run exists, show a pending or unavailable state and queue at most one initial job. Do not let every visitor independently trigger the first execution. ## Recover from failures Distinguish a rejected submission from an accepted execution whose completion was not observed. A client timeout does not cancel the Neuron query. Keep its ID and avoid automatically submitting a second expensive run. Use a bounded retry policy for failures where a new attempt is appropriate, and do not retry permission failures until access is corrected. The application owns its scheduler, cache, locks, deadlines, and cooldowns. The Reports API does not provide these merely because execution is asynchronous. ## Verify before rollout 1. Run the intended report with the partner account and explicit parameters. 2. Check the returned table IDs, columns, cell types, and error messages against the dashboard's needs. 3. Open the dashboard in multiple sessions and confirm that these reads start no new Neuron executions. 4. Request refresh twice and confirm that only one job runs. 5. Confirm that a failed refresh retains the last successful result and shows its age. Use [report response formats](/reports/responses) when mapping the result to your dashboard. # Run a report over HTTP Source: https://docs.neuro-tech.io/reports/execute-over-http Submit report parameters through the Agent API and collect asynchronous query progress from your backend. Submit a report to **`POST https:///Agent/Xmpp/InformationQuery`**, then collect its result messages with **`POST https:///Agent/Xmpp/PopMessages`**. Execution uses `type: "set"` and the `executeNodeQuery` XML command. Completion arrives asynchronously. Run this sequence in a backend job when serving a dashboard. Cache the completed result and reuse it across dashboard loads. The [dashboard integration guide](/reports/dashboard-integration) covers scheduled jobs and controlled manual refreshes. ## Prepare the session and target Complete [report discovery](/reports/quickstart) first. Your application needs a current JWT, the resolved full Reports JID, an exact report ID, and its parameter form. The discovery sample logs out when it exits; obtain a new session for execution. All requests below go to your provider's Agent API host. The full Reports JID belongs in `to`, even when it identifies another Neuron. Keep the credentials and token on your backend. Replace the illustrative host, application URL, report ID, and parameter names with your values. Use the same account and JWT for submission and polling. ## Fetch the current form Send `POST https://neuron.example.com/Agent/Xmpp/InformationQuery`: ```http theme={null} POST /Agent/Xmpp/InformationQuery HTTP/1.1 Host: neuron.example.com Referer: https://your-app.example/ Authorization: Bearer Content-Type: application/json Accept: application/json { "to": "reports@neuron.example.com/current-resource", "type": "get", "xml": "" } ``` Check both the HTTP status and the response's `ok` property. On success, read the form from `Stanza.x`. See [parameter forms](/reports/responses#parameter-forms) for the response structure. ## Submit the report Generate a unique `queryId` for each execution and retain it to correlate result messages. Submit an XMPP data form with `type='submit'`, using each field's exact `var` and `type`. Include hidden fields returned by the form. Send one `` element per value for a multi-value field. Send `POST https://neuron.example.com/Agent/Xmpp/InformationQuery`, changing `type` to `set`: ```http theme={null} POST /Agent/Xmpp/InformationQuery HTTP/1.1 Host: neuron.example.com Referer: https://your-app.example/ Authorization: Bearer Content-Type: application/json Accept: application/json { "to": "reports@neuron.example.com/current-resource", "type": "set", "xml": "2026-08" } ``` Use an XML builder or escape XML text and attribute values before embedding them in the request. Use your language's JSON serializer for the outer body. For a report with no fields, send an empty submit form: ``. A successful response has `ok: true`, for example with other fields omitted: ```json theme={null} { "ok": true } ``` **This acknowledges the query; it does not contain the completed report.** Check the HTTP status and `ok`; stop on a failed query and inspect its sanitized error fields. Record the query ID and start collecting progress. ## Collect progress messages For a backend using polling, send `POST https://neuron.example.com/Agent/Xmpp/PopMessages`: ```http theme={null} POST /Agent/Xmpp/PopMessages HTTP/1.1 Host: neuron.example.com Referer: https://your-app.example/ Authorization: Bearer Content-Type: application/json Accept: application/json { "maxCount": 100 } ``` The response contains `Messages`. Each message contains its sender and a `Content` array of XML elements represented as JSON. Find elements with `__name: "queryProgress"` and `__ns: "urn:nf:iot:concentrator:1.0"`. Match the expected sender, `queryId`, source `Reports`, and report `id` before using the data. Illustrative completion message, with unrelated fields omitted: ```json theme={null} { "Messages": [ { "from": "reports@neuron.example.com/current-resource", "Content": [ { "__name": "queryProgress", "__ns": "urn:nf:iot:concentrator:1.0", "src": "Reports", "id": "Client Reports\\Monthly usage.rpx", "queryId": "client-run-unique-id", "seqNr": "8", "queryDone": { "__name": "queryDone", "__ns": "urn:nf:iot:concentrator:1.0" } } ] } ] } ``` Poll at an application-defined interval until `queryDone` or `queryAborted`, with an overall deadline appropriate for your report. `Messages: []` means no queued messages were returned on that poll; it does not mean the report is complete. Pop Messages consumes queued messages for the whole account. Use one consumer that dispatches all messages, or a dedicated report account. Do not run competing pollers or discard unrelated messages. Matching browser event handlers redirect messages to client events instead of this queue. Preserve each batch before processing it. Track `seqNr` as a number, handle duplicate or out-of-order progress, and do not silently label a report complete if earlier progress is missing. If a poll response is lost after the server consumes its messages, this queue does not provide a replay acknowledgment protocol. ## Assemble the result | Progress element | Client action | | ---------------------------- | ------------------------------------------------------------------------------------ | | `queryStarted` | Mark execution as started. | | `title` | Read the report title from `name`. | | `beginSection`, `endSection` | Maintain the section hierarchy; `beginSection.header` is the heading. | | `newTable` | Create a table using `tableId`, `tableName`, and the `column` definitions. | | `newRecords` | Append `record` cells to the table identified by `tableId`, preserving column order. | | `tableDone` | Mark that table complete. Other tables or objects can still follow. | | `newObject` | Retain `contentType` and Base64 content from `value`. | | `queryMessage` | Retain the message's `level` and text in `value`. | | `status` | Update progress text from `message`. | | `queryDone` | Mark the query complete after preceding progress has been processed. | | `queryAborted` | Mark the query aborted; any collected output is partial. | Raw HTTP polling returns these messages. It does not automatically produce the JavaScript helper's `Tables`, `Sections`, and `Objects` object. Use the [response guide](/reports/responses) to interpret cells or to design a comparable result model. Set a client deadline and keep the query ID for diagnostics. A client timeout does not cancel the server query. Avoid automatically resubmitting timed-out reports: they may still be running, and report scripts can perform work beyond reading data. ## End the session After collecting the result, send `POST https://neuron.example.com/Agent/Account/Logout` and discard the JWT: ```http theme={null} POST /Agent/Account/Logout HTTP/1.1 Host: neuron.example.com Referer: https://your-app.example/ Authorization: Bearer Content-Type: application/json Accept: application/json {} ``` # Reports JavaScript methods Source: https://docs.neuro-tech.io/reports/javascript Use GetReports, GetReportParameters, and ExecuteReport and understand their return values. The JavaScript files served by a Neuron expose three Reports methods. They resolve the report target, build concentrator requests, and, for execution, assemble asynchronous progress into a result object. For a shared credential integration, use the [backend quickstart](/reports/quickstart). The browser helpers keep the Agent API session in browser storage; use them only where an individual user's browser session is appropriate. Do not embed your shared client account's password or JWT in a public page. ## Endpoints used by the browser helpers The helpers send requests to `https://`. These are the endpoints you should see in the browser's network inspector: | Helper or action | Network request | Purpose | | ------------------------------- | --------------------------------------- | ----------------------------------------------------------------------- | | `Account.Login()` | `POST /Agent/Account/Login` | Sign in and retain the returned JWT for later calls. | | Resolve a bare Reports JID | `POST /Agent/Xmpp/PresenceProbe` | Find the target's current full JID before a report query. | | `Reports.GetReports()` | `POST /Agent/Xmpp/InformationQuery` | Send `getAllNodes` with source `Reports`. | | `Reports.GetReportParameters()` | `POST /Agent/Xmpp/InformationQuery` | Send `getCommandParameters` with the report ID and command `Execute`. | | Register report progress | `POST /Agent/Xmpp/RegisterEventHandler` | Register `queryProgress` delivery to the browser tab before execution. | | `Reports.ExecuteReport()` | `POST /Agent/Xmpp/InformationQuery` | Send `executeNodeQuery` with submitted fields and a generated query ID. | | Receive completion | `wss:///ClientEventsWS` | Deliver asynchronous progress to `Events.js` on an HTTPS page. | | `Account.Logout()` | `POST /Agent/Account/Logout` | End the session. | `ExecuteReport()` manages registration and result assembly. Its event registration uses this JSON body, with the actual tab ID supplied by `Events.js`: ```json theme={null} { "localName": "queryProgress", "namespace": "urn:nf:iot:concentrator:1.0", "type": "", "function": "AgentAPI.Things.Concentrator.QueryProgress.OnQueryProgress", "tabId": "" } ``` The helper makes this request for you. Loading the scripts alone does not establish an authenticated session or prove that progress is arriving. An accepted execution request followed by a completed result confirms the full flow. Use the [HTTP execution guide](/reports/execute-over-http) for backend polling with `PopMessages`; matching browser handlers divert progress from that queue. ## Load the Neuron libraries Read the JavaScript source served by the lab Neuron: * [Agent.js](https://lab.tagroot.io/Agent.js) — HTTP requests, authentication, and session handling. * [Agent.Things.js](https://lab.tagroot.io/Agent.Things.js) — concentrator queries, parameter submission, and asynchronous result assembly. * [Agent.Reports.js](https://lab.tagroot.io/Agent.Reports.js) — the `GetReports`, `GetReportParameters`, and `ExecuteReport` methods. These links provide reference implementations from `lab.tagroot.io`. For your application, use the files served by your provider's Neuron so they match its build. In a browser integration, load these files from the same Neuron build: ```html theme={null} ``` After the scripts load, set the host and sign in with credentials entered by the individual user: ```javascript theme={null} AgentAPI.IO.SetHost("neuron.example.com", true); await AgentAPI.Account.Login(userName, password, 3600); ``` `userName` and `password` are runtime inputs from your sign-in form. Clear the password input after login. The helper generates the nonce and signature, calls `/Agent/Account/Login`, and stores the returned session JWT for subsequent calls. The `NEURON` metadata tells `Events.js` where to receive events when your page uses another origin. Your provider must allow your application's origin for Agent API and Events access. Use a browser referrer policy that sends the application origin so Agent API requests include the required `Referer` header. An HTTPS page needs HTTPS scripts/API requests and WSS Events; `Events.js` selects `ws://` when the page itself uses HTTP. `Events.js` is needed for the execution helper to receive progress and settle its promise. Discovery and parameter retrieval do not require asynchronous events. ## List report IDs ```javascript theme={null} const jid = "reports@neuron.example.com"; const language = "en"; const reportIds = await AgentAPI.Reports.GetReports(jid, language); ``` Returns a string array containing visible executable leaf report IDs. It filters out nodes without a parent, nodes without commands, and nodes with children. It does not return report contents or execute a report. ```json theme={null} ["Client Reports\\Monthly usage.rpx"] ``` The current helper expects the underlying node list to be an array. If the server returns a single node object, the helper can return an empty list. The [backend discovery sample](/reports/quickstart) normalizes both shapes. ## Fetch a parameter form Use a report ID from discovery: ```javascript theme={null} const reportId = "Client Reports\\Monthly usage.rpx"; const form = await AgentAPI.Reports.GetReportParameters(jid, language, reportId); ``` Returns the form from `Stanza.x`, or `[]` when no `x` element is returned. Check for a valid form before execution. Normalize a single `field` object to an array when using the current execution helper. See [parameter forms](/reports/responses#parameter-forms). ## Submit values and await completion Each `ExecuteReport` call starts report execution. For dashboards, use a shared backend job and cached results rather than calling it on every page load. See [dashboard refresh policies](/reports/dashboard-integration#choose-a-refresh-policy). This example continues with the fetched form and an illustrative `Month` parameter: ```javascript theme={null} if (!form || Array.isArray(form) || form.__name !== "x") { throw new Error("The report did not return a parameter form."); } const parameters = structuredClone(form); parameters.field = parameters.field == null ? [] : Array.isArray(parameters.field) ? parameters.field : [parameters.field]; const month = parameters.field.find(field => field.var === "Month"); if (!month) throw new Error("This report does not define a Month parameter."); month.value = { value: "2026-08" }; const result = await AgentAPI.Reports.ExecuteReport( jid, language, reportId, parameters ); if (!result.Done || result.HasErrors || result.Errors.length > 0) { throw new Error("The report did not complete successfully."); } for (const table of Object.values(result.Tables)) { console.log(table.Name, table.Columns, table.Records); } ``` Replace the field name and value with those defined by your report. Preserve hidden fields and defaults unless you intend to change them. Treat report messages as part of result validation as well; the helper's `HasErrors` does not classify every message level. The current helper serializes one nested string value per field (`field.value.value`). Use strings such as `"0"` and `"false"`, not JavaScript numbers or booleans. Multi-value fields require the [HTTP submit form](/reports/execute-over-http#submit-the-report), which can contain repeated `` elements. The promise resolves after `queryDone` or `queryAborted`; an abort can resolve with `HasErrors: true` instead of rejecting. Transport or command errors can reject the promise. Add an application deadline because missing events can leave it pending. A local deadline does not cancel execution on the server. See [assembled results](/reports/responses#assembled-javascript-results) for the returned fields. ## Method signatures ```javascript theme={null} AgentAPI.Reports.GetReports(JID, Language, DeviceToken, ServiceToken, UserToken) AgentAPI.Reports.GetReportParameters(JID, Language, Report, DeviceToken, ServiceToken, UserToken) AgentAPI.Reports.ExecuteReport(JID, Language, Report, Parameters, DeviceToken, ServiceToken, UserToken) ``` The last three arguments are optional device, service, and user tokens for deployments that require them. They are separate from the JWT used to authenticate HTTP requests. Leave them omitted unless your provider supplies them. You can resolve a bare target once with `AgentAPI.Things.XmppHelper.GetFullJid(jid, false)` and use the full JID for subsequent calls. Resolve it again if the target reconnects. The helpers otherwise probe bare JIDs when needed. When the user signs out, call `await AgentAPI.Account.Logout()` to end the session. # Reports API Source: https://docs.neuro-tech.io/reports/overview Discover, run, and display the reports shared with your Agent API account. Use the Reports API to list reports available to your account, supply their parameters, and retrieve tables, messages, and generated objects. Your application connects to the Neuron over HTTPS using the Agent API credentials supplied to you. For dashboards, run reports on a backend schedule or through a controlled manual refresh. Serve cached results to viewers; do not execute an expensive report on every page load. Follow [Refresh reports for a dashboard](/reports/dashboard-integration) for scheduling, concurrency, and stale-data handling. ## Get your connection details Your provider supplies these values: | Value | Example | Purpose | | ----------- | ---------------------------------- | ----------------------------------------------------------------------------------------- | | Neuron host | `neuron.example.com` | Host serving the Agent API. Use `https://neuron.example.com/Agent/...` for HTTP requests. | | Username | `client.reports` | Account used to sign in. Preserve the supplied spelling. | | Password | Supplied separately | Used to sign the login request and obtain a session token. | | Reports JID | `reports@neuron.example.com` | Address of the Neuron that hosts the reports. | | Report ID | `Client Reports\Monthly usage.rpx` | Exact identifier returned by report discovery. | | Language | `en` | Language requested for labels and report text. | **Reports JID is the report server's address.** It is separate from your login username and the report's filename. Do not construct it from the HTTP host: the report server may use another XMPP domain. Use the exact address supplied by your provider. The provider configures report permissions and approves the required presence subscription. You do not need a Neuron administrator login or a digital identity to use this report authorization flow. ## Endpoints used by reports The main report endpoint is **`POST https:///Agent/Xmpp/InformationQuery`**. Use it to discover reports, fetch a parameter form, and start execution. The XML command in its JSON body selects the action. All requests below go to the Agent API host supplied with your account. The Reports JID is the target inside the request body. | Step | HTTP endpoint | Request and result | | ---------------------------- | ----------------------------------- | ------------------------------------------------------------------------------------------------------ | | Sign in | `POST /Agent/Account/Login` | Send username, nonce, HMAC signature, and session duration; retain `jwt` and `expires`. | | Resolve a bare Reports JID | `POST /Agent/Xmpp/PresenceProbe` | Send `to`; retain the returned full `jid`. | | List reports | `POST /Agent/Xmpp/InformationQuery` | Send `type: "get"` with `getAllNodes` and `src='Reports'`; read `Stanza.nodeInfos.nodeInfo`. | | Fetch parameters | `POST /Agent/Xmpp/InformationQuery` | Send `type: "get"` with `getCommandParameters` and `command='Execute'`; read `Stanza.x`. | | Start execution | `POST /Agent/Xmpp/InformationQuery` | Send `type: "set"` with `executeNodeQuery`, a unique `queryId`, and the submitted form; check `ok`. | | Collect results on a backend | `POST /Agent/Xmpp/PopMessages` | Send `maxCount`; process matching `queryProgress` elements in `Messages[].Content[]` until completion. | | End the session | `POST /Agent/Account/Logout` | Send `{}` with the session JWT. | Include `Content-Type: application/json`, `Accept: application/json`, and your application's URL in `Referer` on every request. After login, also include `Authorization: Bearer `. The [discovery guide](/reports/quickstart) and [execution guide](/reports/execute-over-http) show complete requests and responses in order. Browser integrations using `ExecuteReport()` receive completion through the [Agent Events connection](/reports/javascript#endpoints-used-by-the-browser-helpers). They use `POST /Agent/Xmpp/RegisterEventHandler` and the `/ClientEventsWS` WebSocket instead of backend polling. ## Follow the report lifecycle 1. Sign in and obtain a JWT session token. 2. Resolve the Reports JID to its current full address. 3. List the reports visible to your account. 4. Fetch the selected report's parameter form. 5. Submit the parameters and collect progress until the report completes. 6. Read the returned tables, messages, and objects. Discovery returns identifiers, not report results. Running a report produces results asynchronously. There is no universal set of columns: each report defines its own parameters and output. ## Choose your integration Sign in with supplied credentials and discover reports using complete HTTP requests. Submit a parameter form and collect results from any backend language. Understand the three Reports methods and their assembled results. Interpret parameter forms, tables, typed cells, and completion states. Keep shared client credentials and JWTs on your backend. Return only the report data your application needs to its browser users. `AgentAPI.Reports` is a JavaScript extension built on the Agent API's XMPP messaging resources. There is no separate `/Agent/Reports/GetReports` HTTP endpoint. Your HTTP client does not need to open an XMPP connection. # Discover your first report Source: https://docs.neuro-tech.io/reports/quickstart Call the login, presence, and query endpoints over HTTPS to discover report IDs and retrieve their parameter forms. Sign in, resolve your report server, and retrieve a report's parameter form using ordinary HTTPS requests. You can follow this guide with any HTTP client or backend language. For a dashboard, execute reports from a scheduled backend job or a controlled manual refresh and cache the completed result. Dashboard loads should read that cache. See [Refresh reports for a dashboard](/reports/dashboard-integration). ## Prepare your connection Have these values ready before sending requests: | Value | Example | Where it is used | | --------------------- | ---------------------------- | ------------------------------------------------------------------------------------------ | | Neuron host | `neuron.example.com` | HTTPS destination and host in the login signature. Obtain it from your provider. | | Username and password | Supplied by your provider | Sign the login request for the account with report access. | | Application URL | `https://your-app.example/` | `Referer` header on every request, including backend calls. | | Reports JID | `reports@neuron.example.com` | Report server address supplied by your provider; separate from the HTTP host and username. | The provider must grant report access and approve your account's presence subscription to the report server. Keep shared credentials and JWTs on your backend. All hosts, report names, and response values below are illustrative. The request destination is always your Agent API host, even when the Reports JID points to another Neuron. For example, the query URL is `https://neuron.example.com/Agent/Xmpp/InformationQuery`. The `to` field inside its JSON body selects the report server. ## 1. Sign in Generate a fresh nonce from at least 32 cryptographically random bytes and encode it as Base64. Calculate the signature using the exact username, hostname, and nonce: ```text theme={null} message = userName + ":" + host + ":" + nonce signature = Base64(HMAC-SHA256(key=UTF8(password), data=UTF8(message))) ``` The host excludes `https://` and paths. Include a non-default port if your provider uses one. Use standard Base64 for the HMAC digest. Send the same nonce string that you signed. Send `POST https://neuron.example.com/Agent/Account/Login`: ```http theme={null} POST /Agent/Account/Login HTTP/1.1 Host: neuron.example.com Referer: https://your-app.example/ Content-Type: application/json Accept: application/json { "userName": "", "nonce": "", "signature": "", "seconds": 3600 } ``` Login does not require a bearer token. A successful response contains: ```json theme={null} { "jwt": "", "expires": 1788958800 } ``` Retain the returned `jwt` and expiry in your backend session. Use that JWT in all remaining requests. `expires` is a Unix timestamp in seconds; multiply by 1,000 before passing it to JavaScript's `Date` constructor. Replace the example `Referer` with your application's HTTPS URL throughout this guide. ## 2. Resolve the report server Send the provider's bare Reports JID to `POST https://neuron.example.com/Agent/Xmpp/PresenceProbe`: ```http theme={null} POST /Agent/Xmpp/PresenceProbe HTTP/1.1 Host: neuron.example.com Referer: https://your-app.example/ Authorization: Bearer Content-Type: application/json Accept: application/json { "to": "reports@neuron.example.com" } ``` On success, read `jid`. An illustrative response, with other fields omitted: ```json theme={null} { "jid": "reports@neuron.example.com/current-resource", "type": "available" } ``` Use this full JID, including `/current-resource`, as `to` in subsequent queries. Do not invent the resource suffix. If the response is unavailable or lacks a full JID, wait for the target to become available and resolve it again. The suffix can change when the target reconnects. If your provider already supplied a current full JID, use it directly and skip the probe. A probe can send a presence subscription request and return `403` until the target approves it. Ask your provider to approve that request before retrying; a successful login does not grant presence access. ## 3. Discover report IDs Send `POST https://neuron.example.com/Agent/Xmpp/InformationQuery` with `type: "get"` and the `getAllNodes` XML command: ```http theme={null} POST /Agent/Xmpp/InformationQuery HTTP/1.1 Host: neuron.example.com Referer: https://your-app.example/ Authorization: Bearer Content-Type: application/json Accept: application/json { "to": "reports@neuron.example.com/current-resource", "type": "get", "xml": "" } ``` The outer HTTP method remains `POST`. The JSON `type` selects the query operation, and `xml` is a string containing one XML element. Keep the namespace and source ID `Reports` exactly as shown. Check both the HTTP status and `ok` in the response. A successful response can look like this: ```json theme={null} { "ok": true, "Stanza": { "nodeInfos": { "nodeInfo": { "id": "Client Reports\\Monthly usage.rpx", "parentId": "Client Reports", "hasCommands": "true", "hasChildren": "false" } } } } ``` Read `Stanza.nodeInfos.nodeInfo`, which can be one object, an array, or absent when there are no nodes. To obtain the same report list as the Reports helper, keep nodes with a `parentId` and enabled `hasCommands`, excluding nodes with `hasChildren` enabled. These flags can be JSON booleans or strings. Preserve each matching `id` exactly, including spaces and backslashes. An empty list means no matching report nodes were returned. An HTTP error or `ok: false` means the query failed. If the source is missing or hidden, use the [source visibility check](/reports/troubleshooting#check-source-visibility) before continuing. ## 4. Fetch the selected report's parameters Call the **same endpoint** with `getCommandParameters`, the discovered report ID, and `command='Execute'`: ```http theme={null} POST /Agent/Xmpp/InformationQuery HTTP/1.1 Host: neuron.example.com Referer: https://your-app.example/ Authorization: Bearer Content-Type: application/json Accept: application/json { "to": "reports@neuron.example.com/current-resource", "type": "get", "xml": "" } ``` After checking `ok: true`, read the form from `Stanza.x`. An illustrative response, with metadata omitted: ```json theme={null} { "ok": true, "Stanza": { "x": { "type": "form", "field": { "var": "Month", "type": "text-single", "label": "Month", "required": {}, "value": { "value": "2026-08" } } } } } ``` Use the returned field names, types, defaults, allowed values, and validation rules. `Month` is an example; your report may have different fields or none. Preserve hidden fields and normalize a single `field` object to an array. See [parameter forms](/reports/responses#parameter-forms) for multi-value fields and other types. Use an XML builder or escape XML attributes when substituting report IDs. Then use a JSON serializer for the outer request. In JSON, `\\` represents one backslash; the report ID itself contains a single backslash. ## 5. Execute or end the session You now have the JWT, full Reports JID, exact report ID, and parameter form needed to execute a report. Keep this session open and continue with [Run a report over HTTP](/reports/execute-over-http), which shows submission and result collection. If you are finished with discovery, send `POST https://neuron.example.com/Agent/Account/Logout` with an empty JSON object: ```http theme={null} POST /Agent/Account/Logout HTTP/1.1 Host: neuron.example.com Referer: https://your-app.example/ Authorization: Bearer Content-Type: application/json Accept: application/json {} ``` Discard the JWT after logout. Sign in again before starting a new execution session. ## Optional Node.js sample The [discovery sample](/downloads/reports-discovery.mjs) implements login, presence resolution, report listing, parameter retrieval, and logout. It requires Node.js 22 or later and does not execute reports. Save it as `discover.mjs` and create a private `.env` file beside it: ```dotenv theme={null} NEURON_HOST=neuron.example.com NEURON_USER=client.reports NEURON_PASSWORD="replace-with-the-provided-password" NEURON_REFERER=https://your-app.example/ REPORTS_JID=reports@neuron.example.com REPORT_LANGUAGE=en ``` Run these commands separately to list IDs and fetch one report's form: ```bash theme={null} node --env-file=.env discover.mjs node --env-file=.env discover.mjs "Client Reports\Monthly usage.rpx" ``` Each invocation signs in and logs out. Keep `.env` out of source control. # Report response formats Source: https://docs.neuro-tech.io/reports/responses Interpret discovery, parameter forms, report tables, typed cells, objects, and completion states. There are two response levels: raw HTTP responses from the Agent API and the objects assembled by its JavaScript helpers. Field names are case-sensitive. The examples below illustrate structure; report IDs, parameters, columns, and values depend on your report. ## HTTP query envelopes Information Query returns an envelope: ```json theme={null} { "ok": true, "Stanza": { "nodeInfos": { "nodeInfo": { "id": "Client Reports\\Monthly usage.rpx", "parentId": "Client Reports", "hasCommands": "true", "hasChildren": "false" } } } } ``` This discovery example omits XML metadata and other node attributes. Always inspect `ok`, even after HTTP success. Failed queries can include `errorText`, `errorType`, `errorCode`, and `ErrorElement`. XML is represented as JSON using these conventions: | Representation | Meaning | | -------------------------------- | -------------------------------------------------------------------------------------------------------------- | | `__name`, `__ns` | XML element name and namespace. | | Named properties such as `field` | Child elements. One child is an object; repeated children are an array. A missing child can be absent. | | `value` | Text content. A `` child can itself have a `value` text property. | | Attribute properties | Usually strings, including values such as `"true"`, `"false"`, and sequence numbers. | | `__ordered` | Ordered child elements when different child names occur together. Use this to preserve mixed table-cell order. | Normalize absent, single, and repeated elements before iteration: ```javascript theme={null} const asArray = value => value == null ? [] : Array.isArray(value) ? value : [value]; ``` The `GetReports` helper reduces the matching report nodes to a string array. The raw HTTP envelope is not itself that array. ## Parameter forms Parameter retrieval returns an XMPP data form in `Stanza.x`. The JavaScript helper returns that form directly. Illustrative form, with XML metadata omitted: ```json theme={null} { "type": "form", "title": { "value": "Monthly usage" }, "field": [ { "var": "Month", "type": "text-single", "label": "Month", "desc": { "value": "Month to include, in YYYY-MM format." }, "required": {}, "value": { "value": "2026-08" } }, { "var": "Format", "type": "list-single", "label": "Format", "value": { "value": "summary" }, "option": [ { "label": "Summary", "value": { "value": "summary" } }, { "label": "Details", "value": { "value": "details" } } ] } ] } ``` | Field property | How to use it | | --------------- | ----------------------------------------------------------------------------------------------------- | | `var` | Exact submission key. Do not replace it with the displayed label. | | `type` | Input type, such as `text-single`, `boolean`, `list-single`, `list-multi`, `hidden`, or `fixed`. | | `label`, `desc` | Text for the person supplying parameters. | | `required` | Presence of this element marks a required field. It need not be a JSON boolean. | | `value` | Default or supplied value, normally nested as `{ "value": "text" }`. Repeated values can be an array. | | `option` | Allowed options; submit their values rather than their display labels. | Honor any validation information in the form. Do not assume every report accepts dates, the same date format, or the same field names. Preserve hidden fields. Fixed fields describe the form rather than requesting user input. An actual empty form can be submitted with no fields; a missing form should be investigated. ## Assembled JavaScript results `ExecuteReport` returns a completed query record assembled from progress events. This illustrative result contains one section and one table. A report can contain multiple tables, nested sections, and generated objects. ```json theme={null} { "Sections": [ { "Type": "Section", "Header": "Usage", "Items": [ { "Type": "Table", "Id": "usage", "Name": "Monthly usage", "Columns": [ { "Id": "month", "Header": "Month" }, { "Id": "total", "Header": "Total", "NrDecimals": "2" } ], "Records": [ ["2026-08", { "Type": "Quantity", "Magnitude": "125.5", "Unit": "kWh" }] ], "Done": true } ] } ], "Objects": [], "Tables": { "usage": { "Type": "Table", "Id": "usage", "Name": "Monthly usage", "Columns": [ { "Id": "month", "Header": "Month" }, { "Id": "total", "Header": "Total", "NrDecimals": "2" } ], "Records": [ ["2026-08", { "Type": "Quantity", "Magnitude": "125.5", "Unit": "kWh" }] ], "Done": true } }, "Ok": true, "Errors": [], "HasErrors": false, "Started": true, "Done": true, "Title": "Monthly usage" } ``` | Property | Meaning | | --------------------- | ------------------------------------------------------------------------------------------------- | | `Tables` | Object keyed by table ID, not an array. Iterate with `Object.values(result.Tables)`. | | `Sections` | Hierarchical presentation. Sections have `Type: "Section"`, `Header`, and `Items`. | | `Objects` | Generated objects with `Type: "Object"`, `ContentType`, and `Base64`. | | `Title` | Report title, if supplied. | | `Started`, `Done` | Execution lifecycle flags. `Done` alone does not distinguish successful completion from an abort. | | `HasErrors`, `Errors` | Errors recorded by the helper. An abort adds `"Aborted."`. | | `Ok` | Initialized to true by the current helper. Do not use it alone to determine success. | Section `Items` can contain nested sections, tables, objects, and messages. A table can appear in a section and in `Tables`; these are two ways to access the same output, not two separate tables. Messages have `Type: "Message"`, `Level`, and `Text`. Inspect their levels and text; they are not all copied into `Errors`. The helper removes `Status` when the query ends. Do not require it in a completed result. An HTTP execution acknowledgment never contains this assembled object. ## Read tables and cells `Columns` defines display order. Each entry in `Records` is a row array in that same order: `Records[rowIndex][columnIndex]` belongs to `Columns[columnIndex]`. Columns contain `Id` and may include `Header`, `SourceId`, `Partition`, `ForegroundColor`, `BackgroundColor`, `Alignment`, and `NrDecimals`. Do not assume a particular table ID, column count, or column name unless your provider defines that contract for your report. | Cell shape | Meaning | | ------------------------------------------------------------------------------ | --------------------------------------------------------------------------------- | | String or other scalar | Text or a scalar value. Numeric, date, and boolean XML values can remain strings. | | `{ "Type": "Quantity", "Magnitude": "125.5", "Unit": "kWh" }` | Value with a unit. | | `{ "Type": "Measurement", "Magnitude": "20.1", "Unit": "°C", "Error": "0.2" }` | Value, unit, and measurement error. | | `{ "Type": "EncodedObject", "ContentType": "image/png", "Base64": "..." }` | Encoded content within a table cell. | | Missing or null value | Empty cell. Preserve its position instead of shifting later cells. | For raw `newRecords` progress, cells retain their XML names, such as `string`, `double`, `quantity`, or `measurement`. Read `record.__ordered` when present; grouping by cell type would scramble column order. For quantities and measurements, the raw attributes are `m` (magnitude), `u` (unit), and `e` (measurement error). Convert values according to the report's contract. Avoid converting large integers to JavaScript numbers if precision matters. Render labels and text as text. Decode objects according to an allowed content type rather than inserting arbitrary output as HTML. ## Handle partial or failed results * Reject HTTP failures and Information Query responses with `ok: false` before consuming success data. * Wait for query completion, not just the first table or its `Done` flag. * Treat aborted queries, missing progress, and client deadlines as incomplete results. * Inspect helper `HasErrors`, `Errors`, and section messages before displaying a result as successful. See [Reports troubleshooting](/reports/troubleshooting) for the next check for each symptom. # Troubleshoot report access and execution Source: https://docs.neuro-tech.io/reports/troubleshooting Separate login, target addressing, report permissions, parameter errors, and incomplete execution. Identify which step failed before retrying. Successful login confirms your credentials; it does not confirm permission to view a report. | Symptom | What to check | | ------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Login fails | Verify the supplied host, exact username, password, and login signature construction. | | A previously working session fails | Check the JWT expiry and obtain a new session. | | Presence probe is denied | Ask your provider to approve the presence subscription from your account to the report target. | | The target is unavailable | Verify the Reports JID with your provider and resolve its current full JID again. | | `Source not found.` | Check the target and whether this account can view the `Reports` data source. This response can mean the source is hidden by authorization. | | Discovery returns `[]` | Confirm the intended report is loaded on this target and visible to this account. Preserve a query failure as an error rather than converting it to an empty list. | | JavaScript discovery is empty but HTTP returns one node | The current helper assumes a node array. Use the backend sample or normalize the underlying single-node response. | | A selected report is missing | Refresh discovery and use its exact report ID, including spaces and path separators. | | Parameter submission fails | Fetch a fresh form and check field names, required values, options, hidden fields, and validation rules. | | Execution is accepted but never completes | Check browser events or the backend message consumer. Ensure another consumer is not taking the progress messages. | | `queryAborted` or helper `HasErrors` | Treat collected output as partial and inspect messages and errors. | ## Check the report target The HTTP host identifies where you call the Agent API. The Reports JID identifies where reports are hosted. The account username identifies who you are. The report ID identifies which report to run. These values are not interchangeable. For example, `neuron.example.com`, `client.reports`, `reports@neuron.example.com`, and `Client Reports\Monthly usage.rpx` can all be needed for the same request sequence. ## Check source visibility After login and presence resolution, ask which data sources the account can see. Send `POST https://neuron.example.com/Agent/Xmpp/InformationQuery` using your actual host, application URL, JWT, and full Reports JID: ```http theme={null} POST /Agent/Xmpp/InformationQuery HTTP/1.1 Host: neuron.example.com Referer: https://your-app.example/ Authorization: Bearer Content-Type: application/json Accept: application/json { "to": "reports@neuron.example.com/current-resource", "type": "get", "xml": "" } ``` Check HTTP success and `ok: true`, then inspect `Stanza.dataSources.dataSource`. Normalize a single object to an array and look for `src: "Reports"`. If it is absent, confirm the target and source permissions with your provider. Source visibility alone does not prove permission to execute every report. This is the HTTP request behind `AgentAPI.Things.Concentrator.GetAllDataSources()` in the [original report walkthrough](https://lab.tagroot.io/Community/Post/Using_Agent_API_to_execute_reports_on_a_Neuron). ## Check the report's Execute command Send another request to the same endpoint, using the same headers and the exact ID returned by discovery: ```http theme={null} POST /Agent/Xmpp/InformationQuery HTTP/1.1 Host: neuron.example.com Referer: https://your-app.example/ Authorization: Bearer Content-Type: application/json Accept: application/json { "to": "reports@neuron.example.com/current-resource", "type": "get", "xml": "" } ``` After checking `ok`, inspect `Stanza.commands.command`, normalizing a single command to an array. The report workflow needs an accessible command with `command: "Execute"` and `type: "Query"`. If it is absent, ask your provider to check that report's executable commands and the account's permissions. A `Query` returns asynchronous output; `Simple` and `Parametrized` commands use a different execution flow. ## Give your provider a useful failure report Include the operation that failed, time, Reports JID, report ID, HTTP status, and sanitized `errorText` or helper error message. For an execution problem, include the query ID and whether you received `queryStarted`, any records, and a terminal event. Do not include passwords, JWTs, or report data that the recipient does not need. ## Provider checks The report target must grant the calling account the report privileges it needs. `Source.Reports.View` controls visibility of the Reports data source. Report nodes can require additional privileges. Presence approval and report authorization are separate checks. A role entry commonly used for report access is: ```text theme={null} +Source\.Reports\..* ``` This grants matching report privileges; it does not restrict the account to one report file. For access to one report, configure report-specific privileges and restrict the other reports as required. Confirm the visible list using the actual client account. If an XMPP account has the required role but only a matching local administrator user makes access work, check that the server includes the XMPP account authorization fix. A duplicate administrator user is not required for report access. ## Retry deliberately Refresh presence and discovery after a target reconnects or permissions change. Avoid automatically executing a report again after a timeout: the first execution might still be running. Preserve the original error instead of replacing every failure with “report not found.” # LegalLab contract example library Source: https://docs.neuro-tech.io/resources/contract-examples Choose and download original contract XML by use case, with roles, parameters, and schema requirements These examples come from the LegalLab repository at revision `d6fac7d837fe244a0c057cd527635deebfc5088d`. You can download XML without installing LegalLab. Use the optional [LegalLab editor](/contracts/legallab-quickstart) to inspect a file, or open it in your text editor. ## Choose your starting point | Goal | Example | | --------------------------- | ------------------------------ | | Learn typed inputs | ParameterTypes in Syntax | | Add derived contract values | CalculatedParameters in Syntax | | Define one token | DemoToken in Tokens | | Inspect a state machine | Calculator in StateMachines | | Explore payments and escrow | ProjectEscrow in StateMachines | Each entry below links to the original XML preview and raw download. The structural summaries are extracted from those exact files. They do not establish provider approval or runtime compatibility; no example in this catalog has yet been verified against the target development Neuron. 42 original files pass local XML/schema checks with the [extended example dependency set](/resources/schemas#additional-legallab-example-schemas). Twelve of them require this extended set; the base eight schemas cover the other 30. Some files are payload or layout examples rather than complete contract templates; inspect the root and required dependencies before submission. Before adapting an example, [validate its complete schema set](/resources/validate-xml), review every role and parameter, and confirm the intended behavior with your provider. Additional namespaces listed on an entry need their own schemas. Submit the resulting template through the [Agent API](/contracts/agent-api-quickstart). ## Browse the original contracts ### Construction **Original file:** `BimExample1.xml`. **Document kind:** payload-example. **Declared result:** Supplies example `BIMProject` data for its matching schema. It is not a complete contract template. [View original XML](https://github.com/Trust-Anchor-Group/LegalLab/blob/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Construction/BimExample1.xml) · [Download XML](https://raw.githubusercontent.com/Trust-Anchor-Group/LegalLab/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Construction/BimExample1.xml) **Additional example schemas:** `https://lab.tagroot.io/Downloads/BimRegister.xsd`. Load these dependencies alongside the base schemas using the [validation guide](/resources/validate-xml). **Local XML validation:** Passes the selected schema and explicit machine-reference checks. **Required roles:** See the original document. **Structural preview** (an outline, not copy-paste XML): ```text theme={null} BIMProject BIMApplication BIMSite ``` **Element namespaces:** `https://lab.tagroot.io/Downloads/BimRegister.xsd`. To adapt this file, update its schema-defined data or layout fields. Do not submit it directly to ProposeTemplate: that operation requires a complete contract envelope. **Tested Neuron runtime:** not yet recorded. Local XML validity does not establish the declared result. **Original file:** `BimExample2.xml`. **Document kind:** payload-example. **Declared result:** Supplies example `BIMProject` data for its matching schema. It is not a complete contract template. [View original XML](https://github.com/Trust-Anchor-Group/LegalLab/blob/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Construction/BimExample2.xml) · [Download XML](https://raw.githubusercontent.com/Trust-Anchor-Group/LegalLab/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Construction/BimExample2.xml) **Additional example schemas:** `https://lab.tagroot.io/Downloads/BimRegister.xsd`. Load these dependencies alongside the base schemas using the [validation guide](/resources/validate-xml). **Local XML validation:** Passes the selected schema and explicit machine-reference checks. **Required roles:** See the original document. **Structural preview** (an outline, not copy-paste XML): ```text theme={null} BIMProject BIMApplication BIMSite ``` **Element namespaces:** `https://lab.tagroot.io/Downloads/BimRegister.xsd`. To adapt this file, update its schema-defined data or layout fields. Do not submit it directly to ProposeTemplate: that operation requires a complete contract envelope. **Tested Neuron runtime:** not yet recorded. Local XML validity does not establish the declared result. **Original file:** `BimRegister.xml`. **Document kind:** contract-template. **Declared result:** Declares creation for 1 token identifier. Provider approval, signatures, and execution must be verified separately. [View original XML](https://github.com/Trust-Anchor-Group/LegalLab/blob/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Construction/BimRegister.xml) · [Download XML](https://raw.githubusercontent.com/Trust-Anchor-Group/LegalLab/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Construction/BimRegister.xml) **Local XML validation:** Passes the selected schema and explicit machine-reference checks. **Required roles:** `Creator` (1–1 signers), `TrustProvider` (1–1 signers). **Structural preview** (an outline, not copy-paste XML): ```text theme={null} Create TokenID Creator Owner TrustProvider Value Currency CommissionPercent Expires CreatorCanDestroy OwnerCanDestroyBatch OwnerCanDestroyIndividual CertifierCanDestroy Definition Tag FriendlyName Category Description Glyph ``` **Token ID definitions:** `Random`. | Parameter | XML type | | ------------------- | -------------------- | | `BuildingId` | `stringParameter` | | `Value` | `numericalParameter` | | `Currency` | `stringParameter` | | `CommissionPercent` | `numericalParameter` | | `Expires` | `dateParameter` | **Machine states:** `Registering`, `Done`. **Element namespaces:** `https://paiwise.tagroot.io/Schema/NeuroFeatures.xsd`, `https://paiwise.tagroot.io/Schema/StateMachines.xsd`, `urn:nf:iot:leg:sc:1.0`. To adapt this template, supply the exact role assignments and parameter names above, review fixed values in the original XML, and align the human-readable terms with every changed machine rule. Validate before provider review. **Tested Neuron runtime:** not yet recorded. Local XML validity does not establish the declared result. ### Logistics **Original file:** `SimpleOrder.xml`. **Document kind:** contract-template. **Declared result:** Declares creation for 1 token identifier. Provider approval, signatures, and execution must be verified separately. [View original XML](https://github.com/Trust-Anchor-Group/LegalLab/blob/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Logistics/SimpleOrder.xml) · [Download XML](https://raw.githubusercontent.com/Trust-Anchor-Group/LegalLab/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Logistics/SimpleOrder.xml) **Local XML validation:** Passes the selected schema and explicit machine-reference checks. **Required roles:** `Buyer` (1–1 signers), `TrustProvider` (1–1 signers). **Structural preview** (an outline, not copy-paste XML): ```text theme={null} Create TokenID Creator Owner TrustProvider Value Currency CommissionPercent Expires CreatorCanDestroy OwnerCanDestroyIndividual Definition FriendlyName Category Description Glyph ``` **Token ID definitions:** `Random`. | Parameter | XML type | | ------------------ | -------------------- | | `NrItems` | `numericalParameter` | | `ItemName` | `calcParameter` | | `PricePerItem` | `calcParameter` | | `PriceUnit` | `calcParameter` | | `VatPercent` | `calcParameter` | | `TotalNoVat` | `calcParameter` | | `Vat` | `calcParameter` | | `Transport` | `calcParameter` | | `Total` | `calcParameter` | | `DeliveryDays` | `calcParameter` | | `Expires` | `calcParameter` | | `ReferenceName` | `roleParameter` | | `ReferencePNr` | `roleParameter` | | `ReferenceCountry` | `roleParameter` | | `ReferencePhoneNr` | `roleParameter` | | `OrgName` | `roleParameter` | | `OrgNr` | `roleParameter` | | `OrgAddress` | `roleParameter` | | `OrgZip` | `roleParameter` | | `OrgCity` | `roleParameter` | | `OrgCountry` | `roleParameter` | **Element namespaces:** `https://paiwise.tagroot.io/Schema/NeuroFeatures.xsd`, `https://paiwise.tagroot.io/Schema/PaymentInstructions.xsd`, `urn:nf:iot:leg:sc:1.0`. To adapt this template, supply the exact role assignments and parameter names above, review fixed values in the original XML, and align the human-readable terms with every changed machine rule. Validate before provider review. **Tested Neuron runtime:** not yet recorded. Local XML validity does not establish the declared result. ### Marketplace **Original file:** `BuyService.xml`. **Document kind:** contract-template. **Declared result:** Declares a `ToBuy` contract instruction. Its marketplace/provider outcome requires separate approval and execution verification. [View original XML](https://github.com/Trust-Anchor-Group/LegalLab/blob/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Marketplace/Buying/BuyService.xml) · [Download XML](https://raw.githubusercontent.com/Trust-Anchor-Group/LegalLab/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Marketplace/Buying/BuyService.xml) **Additional example schemas:** `https://paiwise.tagroot.io/Schema/Marketplace.xsd`. Load these dependencies alongside the base schemas using the [validation guide](/resources/validate-xml). **Local XML validation:** Passes the selected schema and explicit machine-reference checks. **Required roles:** `Buyer` (1–1 signers), `Auctioneer` (1–1 signers). **Structural preview** (an outline, not copy-paste XML): ```text theme={null} ToBuy Description Price Score AvailableDays ``` | Parameter | XML type | | ------------------- | -------------------- | | `ProductNumber` | `stringParameter` | | `Quantity` | `numericalParameter` | | `Description` | `stringParameter` | | `AskingPrice` | `numericalParameter` | | `RejectPrice` | `numericalParameter` | | `AcceptPrice` | `numericalParameter` | | `CommissionPercent` | `numericalParameter` | | `Currency` | `stringParameter` | | `AvailableDays` | `numericalParameter` | | `FromAddress1` | `stringParameter` | | `FromAddress2` | `stringParameter` | | `FromAddress3` | `stringParameter` | | `FromPostalCode` | `stringParameter` | | `FromCity` | `stringParameter` | | `FromCountry` | `stringParameter` | | `ToAddress1` | `stringParameter` | | `ToAddress2` | `stringParameter` | | `ToAddress3` | `stringParameter` | | `ToPostalCode` | `stringParameter` | | `ToCity` | `stringParameter` | | `ToCountry` | `stringParameter` | **Element namespaces:** `https://paiwise.tagroot.io/Schema/Marketplace.xsd`, `urn:nf:iot:leg:sc:1.0`. To adapt this template, supply the exact role assignments and parameter names above, review fixed values in the original XML, and align the human-readable terms with every changed machine rule. Validate before provider review. **Tested Neuron runtime:** not yet recorded. Local XML validity does not establish the declared result. **Original file:** `OfferService.xml`. **Document kind:** contract-template. **Declared result:** Declares a `Offer` contract instruction. Its marketplace/provider outcome requires separate approval and execution verification. [View original XML](https://github.com/Trust-Anchor-Group/LegalLab/blob/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Marketplace/Buying/OfferService.xml) · [Download XML](https://raw.githubusercontent.com/Trust-Anchor-Group/LegalLab/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Marketplace/Buying/OfferService.xml) **Additional example schemas:** `https://paiwise.tagroot.io/Schema/Marketplace.xsd`. Load these dependencies alongside the base schemas using the [validation guide](/resources/validate-xml). **Local XML validation:** Passes the selected schema and explicit machine-reference checks. **Required roles:** `Seller` (1–1 signers), `Auctioneer` (1–1 signers). **Structural preview** (an outline, not copy-paste XML): ```text theme={null} Offer ItemReference Price Currency ``` | Parameter | XML type | | --------------------- | -------------------- | | `RequestForTendersId` | `stringParameter` | | `Price` | `numericalParameter` | | `Currency` | `stringParameter` | **Element namespaces:** `https://paiwise.tagroot.io/Schema/Marketplace.xsd`, `urn:nf:iot:leg:sc:1.0`. To adapt this template, supply the exact role assignments and parameter names above, review fixed values in the original XML, and align the human-readable terms with every changed machine rule. Validate before provider review. **Tested Neuron runtime:** not yet recorded. Local XML validity does not establish the declared result. **Original file:** `OfferItem.xml`. **Document kind:** contract-template. **Declared result:** Declares a `Offer` contract instruction. Its marketplace/provider outcome requires separate approval and execution verification. [View original XML](https://github.com/Trust-Anchor-Group/LegalLab/blob/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Marketplace/Selling/OfferItem.xml) · [Download XML](https://raw.githubusercontent.com/Trust-Anchor-Group/LegalLab/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Marketplace/Selling/OfferItem.xml) **Additional example schemas:** `https://paiwise.tagroot.io/Schema/Marketplace.xsd`. Load these dependencies alongside the base schemas using the [validation guide](/resources/validate-xml). **Local XML validation:** Passes the selected schema and explicit machine-reference checks. **Required roles:** `Buyer` (1–1 signers), `Auctioneer` (1–1 signers). **Structural preview** (an outline, not copy-paste XML): ```text theme={null} Offer ItemReference Price Currency ``` | Parameter | XML type | | --------------------- | -------------------- | | `RequestForTendersId` | `stringParameter` | | `Price` | `numericalParameter` | | `Currency` | `stringParameter` | | `ToAddress1` | `stringParameter` | | `ToAddress2` | `stringParameter` | | `ToAddress3` | `stringParameter` | | `ToPostalCode` | `stringParameter` | | `ToCity` | `stringParameter` | | `ToCountry` | `stringParameter` | **Element namespaces:** `https://paiwise.tagroot.io/Schema/Marketplace.xsd`, `urn:nf:iot:leg:sc:1.0`. To adapt this template, supply the exact role assignments and parameter names above, review fixed values in the original XML, and align the human-readable terms with every changed machine rule. Validate before provider review. **Tested Neuron runtime:** not yet recorded. Local XML validity does not establish the declared result. **Original file:** `SellItem.xml`. **Document kind:** contract-template. **Declared result:** Declares a `ForSale` contract instruction. Its marketplace/provider outcome requires separate approval and execution verification. [View original XML](https://github.com/Trust-Anchor-Group/LegalLab/blob/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Marketplace/Selling/SellItem.xml) · [Download XML](https://raw.githubusercontent.com/Trust-Anchor-Group/LegalLab/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Marketplace/Selling/SellItem.xml) **Additional example schemas:** `https://paiwise.tagroot.io/Schema/Marketplace.xsd`. Load these dependencies alongside the base schemas using the [validation guide](/resources/validate-xml). **Local XML validation:** Passes the selected schema and explicit machine-reference checks. **Required roles:** `Seller` (1–1 signers), `Auctioneer` (1–1 signers). **Structural preview** (an outline, not copy-paste XML): ```text theme={null} ForSale Description Price Score AvailableDays ``` | Parameter | XML type | | ------------------- | -------------------- | | `ProductNumber` | `stringParameter` | | `Quantity` | `numericalParameter` | | `Description` | `stringParameter` | | `AskingPrice` | `numericalParameter` | | `RejectPrice` | `numericalParameter` | | `AcceptPrice` | `numericalParameter` | | `CommissionPercent` | `numericalParameter` | | `Currency` | `stringParameter` | | `AvailableDays` | `numericalParameter` | | `FromAddress1` | `stringParameter` | | `FromAddress2` | `stringParameter` | | `FromAddress3` | `stringParameter` | | `FromPostalCode` | `stringParameter` | | `FromCity` | `stringParameter` | | `FromCountry` | `stringParameter` | **Element namespaces:** `https://paiwise.tagroot.io/Schema/Marketplace.xsd`, `urn:nf:iot:leg:sc:1.0`. To adapt this template, supply the exact role assignments and parameter names above, review fixed values in the original XML, and align the human-readable terms with every changed machine rule. Validate before provider review. **Tested Neuron runtime:** not yet recorded. Local XML validity does not establish the declared result. **Original file:** `SellToken.xml`. **Document kind:** contract-template. **Declared result:** Declares a `ForSale` contract instruction. Its marketplace/provider outcome requires separate approval and execution verification. [View original XML](https://github.com/Trust-Anchor-Group/LegalLab/blob/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Marketplace/Selling/SellToken.xml) · [Download XML](https://raw.githubusercontent.com/Trust-Anchor-Group/LegalLab/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Marketplace/Selling/SellToken.xml) **Additional example schemas:** `https://paiwise.tagroot.io/Schema/Marketplace.xsd`. Load these dependencies alongside the base schemas using the [validation guide](/resources/validate-xml). **Local XML validation:** Passes the selected schema and explicit machine-reference checks. **Required roles:** `Seller` (1–1 signers), `Auctioneer` (1–1 signers). **Structural preview** (an outline, not copy-paste XML): ```text theme={null} ForSale Description Price AvailableDays ``` | Parameter | XML type | | ------------------- | -------------------- | | `TokenID` | `stringParameter` | | `Category` | `stringParameter` | | `FriendlyName` | `stringParameter` | | `AskingPrice` | `numericalParameter` | | `RejectPrice` | `numericalParameter` | | `AcceptPrice` | `numericalParameter` | | `CommissionPercent` | `numericalParameter` | | `Currency` | `stringParameter` | | `AvailableDays` | `numericalParameter` | **Element namespaces:** `https://paiwise.tagroot.io/Schema/Marketplace.xsd`, `urn:nf:iot:leg:sc:1.0`. To adapt this template, supply the exact role assignments and parameter names above, review fixed values in the original XML, and align the human-readable terms with every changed machine rule. Validate before provider review. **Tested Neuron runtime:** not yet recorded. Local XML validity does not establish the declared result. ### Memberships **Original file:** `Membership.xml`. **Document kind:** contract-template. **Declared result:** Declares creation for 1 token identifier. Provider approval, signatures, and execution must be verified separately. [View original XML](https://github.com/Trust-Anchor-Group/LegalLab/blob/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Memberships/Simple/Membership.xml) · [Download XML](https://raw.githubusercontent.com/Trust-Anchor-Group/LegalLab/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Memberships/Simple/Membership.xml) **Additional example schemas:** `http://waher.se/Schema/Layout2D.xsd`, `https://lab.tagroot.io/Downloads/SimpleOrganization.xsd`. Load these dependencies alongside the base schemas using the [validation guide](/resources/validate-xml). **Local XML validation:** Passes the selected schema and explicit machine-reference checks. **Required roles:** `Member` (1–1 signers), `Owner` (1–1 signers), `TrustProvider` (1–1 signers). **Structural preview** (an outline, not copy-paste XML): ```text theme={null} Create TokenID Creator Owner Certifier TrustProvider Value Currency CommissionPercent Expires CreatorCanDestroy OwnerCanDestroyBatch OwnerCanDestroyIndividual CertifierCanDestroy Definition Tag x 8 FriendlyName Category Description Glyph ``` **Token ID definitions:** `Random`. | Parameter | XML type | | ----------------------- | ---------------------------- | | `OrganizationReference` | `contractReferenceParameter` | | `Value` | `numericalParameter` | | `Currency` | `stringParameter` | | `CommissionPercent` | `numericalParameter` | | `Expires` | `dateParameter` | | `MemberName` | `roleParameter` | | `MemberAddress` | `roleParameter` | | `MemberCountryCode` | `roleParameter` | | `MemberCountry` | `calcParameter` | | `MemberPnr` | `roleParameter` | | `ProfilePhoto` | `roleParameter` | **Element namespaces:** `http://waher.se/Schema/Layout2D.xsd`, `https://lab.tagroot.io/Downloads/SimpleOrganization.xsd`, `https://paiwise.tagroot.io/Schema/NeuroFeatures.xsd`, `urn:nf:iot:leg:sc:1.0`. To adapt this template, supply the exact role assignments and parameter names above, review fixed values in the original XML, and align the human-readable terms with every changed machine rule. Validate before provider review. **Tested Neuron runtime:** not yet recorded. Local XML validity does not establish the declared result. **Original file:** `MembershipLayout.xml`. **Document kind:** layout. **Declared result:** Defines a display layout. It is not a complete contract or an asset creation request. [View original XML](https://github.com/Trust-Anchor-Group/LegalLab/blob/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Memberships/Simple/MembershipLayout.xml) · [Download XML](https://raw.githubusercontent.com/Trust-Anchor-Group/LegalLab/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Memberships/Simple/MembershipLayout.xml) **Additional example schemas:** `http://waher.se/Schema/Layout2D.xsd`. Load these dependencies alongside the base schemas using the [validation guide](/resources/validate-xml). **Local XML validation:** Passes the selected schema and explicit machine-reference checks. **Required roles:** See the original document. **Structural preview** (an outline, not copy-paste XML): ```text theme={null} Layout2D SolidPen x 4 SolidBackground x 5 Font x 6 Rectangle Overlays ``` **Element namespaces:** `http://waher.se/Schema/Layout2D.xsd`. To adapt this file, update its schema-defined data or layout fields. Do not submit it directly to ProposeTemplate: that operation requires a complete contract envelope. **Tested Neuron runtime:** not yet recorded. Local XML validity does not establish the declared result. **Original file:** `SimpleOrganization.xml`. **Document kind:** contract-template. **Declared result:** Declares creation for 1 token identifier. Provider approval, signatures, and execution must be verified separately. [View original XML](https://github.com/Trust-Anchor-Group/LegalLab/blob/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Memberships/Simple/SimpleOrganization.xml) · [Download XML](https://raw.githubusercontent.com/Trust-Anchor-Group/LegalLab/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Memberships/Simple/SimpleOrganization.xml) **Local XML validation:** Passes the selected schema and explicit machine-reference checks. **Required roles:** `Creator` (1–1 signers), `Owner` (1–1 signers), `Auditor` (1–1 signers), `TrustProvider` (1–1 signers). **Structural preview** (an outline, not copy-paste XML): ```text theme={null} Create TokenID Creator Owner Certifier TrustProvider Value Currency CommissionPercent Expires CreatorCanDestroy OwnerCanDestroyBatch OwnerCanDestroyIndividual CertifierCanDestroy Definition Tag x 2 FriendlyName Category Description Glyph ``` **Token ID definitions:** `Random`. | Parameter | XML type | | ------------------- | -------------------- | | `OrgName` | `stringParameter` | | `OrgDescription` | `stringParameter` | | `Value` | `numericalParameter` | | `Currency` | `stringParameter` | | `CommissionPercent` | `numericalParameter` | | `Expires` | `dateParameter` | **Machine states:** `Preparing`, `Inactive`, `Active`, `Closed`. **Element namespaces:** `https://paiwise.tagroot.io/Schema/NeuroFeatures.xsd`, `https://paiwise.tagroot.io/Schema/StateMachines.xsd`, `urn:nf:iot:leg:sc:1.0`. To adapt this template, supply the exact role assignments and parameter names above, review fixed values in the original XML, and align the human-readable terms with every changed machine rule. Validate before provider review. **Tested Neuron runtime:** not yet recorded. Local XML validity does not establish the declared result. **Original file:** `SimpleOrganizationLayout.xml`. **Document kind:** layout. **Declared result:** Defines a display layout. It is not a complete contract or an asset creation request. [View original XML](https://github.com/Trust-Anchor-Group/LegalLab/blob/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Memberships/Simple/SimpleOrganizationLayout.xml) · [Download XML](https://raw.githubusercontent.com/Trust-Anchor-Group/LegalLab/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Memberships/Simple/SimpleOrganizationLayout.xml) **Additional example schemas:** `http://waher.se/Schema/Layout2D.xsd`. Load these dependencies alongside the base schemas using the [validation guide](/resources/validate-xml). **Local XML validation:** Passes the selected schema and explicit machine-reference checks. **Required roles:** See the original document. **Structural preview** (an outline, not copy-paste XML): ```text theme={null} Layout2D SolidPen x 10 SolidBackground x 6 Font x 17 Rectangle Overlays ``` **Element namespaces:** `http://waher.se/Schema/Layout2D.xsd`. To adapt this file, update its schema-defined data or layout fields. Do not submit it directly to ProposeTemplate: that operation requires a complete contract envelope. **Tested Neuron runtime:** not yet recorded. Local XML validity does not establish the declared result. ### StateMachines **Original file:** `BuyTransferSellEDaler.xml`. **Document kind:** contract-template. **Declared result:** Declares creation for 1 token identifier. Provider approval, signatures, and execution must be verified separately. [View original XML](https://github.com/Trust-Anchor-Group/LegalLab/blob/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/StateMachines/BuyTransferSellEDaler.xml) · [Download XML](https://raw.githubusercontent.com/Trust-Anchor-Group/LegalLab/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/StateMachines/BuyTransferSellEDaler.xml) **Local XML validation:** Passes the selected schema and explicit machine-reference checks. **Required roles:** `Creator` (1–1 signers), `Buyer` (1–1 signers), `Seller` (1–1 signers), `TrustProvider` (1–1 signers). **Structural preview** (an outline, not copy-paste XML): ```text theme={null} Create TokenID Creator Owner TrustProvider Value Currency CommissionPercent Expires CreatorCanDestroy OwnerCanDestroyIndividual Definition Tag x 4 FriendlyName Category Description Glyph ``` **Token ID definitions:** `Random`. | Parameter | XML type | | ------------------- | -------------------- | | `Value` | `numericalParameter` | | `Currency` | `stringParameter` | | `CommissionPercent` | `numericalParameter` | | `Expires` | `dateParameter` | **Machine states:** `Active`, `Done`. **Element namespaces:** `https://paiwise.tagroot.io/Schema/NeuroFeatures.xsd`, `https://paiwise.tagroot.io/Schema/StateMachines.xsd`, `urn:nf:iot:leg:sc:1.0`. To adapt this template, supply the exact role assignments and parameter names above, review fixed values in the original XML, and align the human-readable terms with every changed machine rule. Validate before provider review. **Tested Neuron runtime:** not yet recorded. Local XML validity does not establish the declared result. **Original file:** `Calculator.xml`. **Document kind:** contract-template. Inspect a note-driven machine with calculation actions and stored values. Its custom XML-note namespace is an additional schema dependency. **Declared result:** Declares creation for 1 token identifier. Provider approval, signatures, and execution must be verified separately. [View original XML](https://github.com/Trust-Anchor-Group/LegalLab/blob/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/StateMachines/Calculator.xml) · [Download XML](https://raw.githubusercontent.com/Trust-Anchor-Group/LegalLab/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/StateMachines/Calculator.xml) **Local XML validation:** Passes the selected schema and explicit machine-reference checks. **Required roles:** `Creator` (1–1 signers), `Certifier` (1–1 signers), `TrustProvider` (1–1 signers). **Structural preview** (an outline, not copy-paste XML): ```text theme={null} Create TokenID Creator Owner Certifier TrustProvider Value Currency CommissionPercent Expires CreatorCanDestroy OwnerCanDestroyBatch OwnerCanDestroyIndividual CertifierCanDestroy Definition FriendlyName Category Description Glyph ``` **Token ID definitions:** `Random`. | Parameter | XML type | | ------------------- | -------------------- | | `Value` | `numericalParameter` | | `Currency` | `stringParameter` | | `CommissionPercent` | `numericalParameter` | | `Expires` | `dateParameter` | **Machine states:** `Calculating`, `Done`. **Element namespaces:** `https://paiwise.tagroot.io/Schema/NeuroFeatures.xsd`, `https://paiwise.tagroot.io/Schema/StateMachines.xsd`, `urn:nf:iot:leg:sc:1.0`. To adapt this template, supply the exact role assignments and parameter names above, review fixed values in the original XML, and align the human-readable terms with every changed machine rule. Validate before provider review. **Tested Neuron runtime:** not yet recorded. Local XML validity does not establish the declared result. **Original file:** `CrowdFunding.xml`. **Document kind:** contract-template. **Declared result:** Declares creation for 5 token identifiers. Provider approval, signatures, and execution must be verified separately. [View original XML](https://github.com/Trust-Anchor-Group/LegalLab/blob/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/StateMachines/CrowdFunding.xml) · [Download XML](https://raw.githubusercontent.com/Trust-Anchor-Group/LegalLab/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/StateMachines/CrowdFunding.xml) **Local XML validation:** Passes the selected schema and explicit machine-reference checks. **Required roles:** `Creator` (1–1 signers), `ProjectOwner` (1–1 signers), `EscrowAgent` (1–1 signers), `TrustProvider` (1–1 signers). **Structural preview** (an outline, not copy-paste XML): ```text theme={null} Create TokenID x 5 Creator Owner Certifier TrustProvider Value Currency CommissionPercent Expires CreatorCanDestroy OwnerCanDestroyBatch OwnerCanDestroyIndividual CertifierCanDestroy Definition Tag x 8 FriendlyName Category Description Glyph ``` **Token ID definitions:** `Random`, `Random`, `Random`, `Random`, `Random`. | Parameter | XML type | | ------------------- | -------------------- | | `MachineID` | `stringParameter` | | `Value` | `numericalParameter` | | `Currency` | `stringParameter` | | `CommissionPercent` | `numericalParameter` | | `Expires` | `dateParameter` | | `ThresholdAmount` | `numericalParameter` | | `MaxIntervalAmount` | `numericalParameter` | | `MaxInterval` | `durationParameter` | | `ProjectStart` | `dateTimeParameter` | **Machine states:** `OpenForInvestment`, `ThresholdNotReached`, `ProjectStarted`, `Done`. **Element namespaces:** `https://paiwise.tagroot.io/Schema/NeuroFeatures.xsd`, `https://paiwise.tagroot.io/Schema/StateMachines.xsd`, `urn:nf:iot:leg:sc:1.0`. To adapt this template, supply the exact role assignments and parameter names above, review fixed values in the original XML, and align the human-readable terms with every changed machine rule. Validate before provider review. **Tested Neuron runtime:** not yet recorded. Local XML validity does not establish the declared result. **Original file:** `DigitalSensorTwin.xml`. **Document kind:** contract-template. **Declared result:** Declares creation for 1 token identifier. Provider approval, signatures, and execution must be verified separately. [View original XML](https://github.com/Trust-Anchor-Group/LegalLab/blob/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/StateMachines/DigitalSensorTwin.xml) · [Download XML](https://raw.githubusercontent.com/Trust-Anchor-Group/LegalLab/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/StateMachines/DigitalSensorTwin.xml) **Local XML validation:** Passes the selected schema and explicit machine-reference checks. **Required roles:** `Creator` (1–1 signers), `Owner` (1–1 signers), `TrustProvider` (1–1 signers). **Structural preview** (an outline, not copy-paste XML): ```text theme={null} Create TokenID Creator Owner TrustProvider Value Currency CommissionPercent Expires CreatorCanDestroy OwnerCanDestroyBatch OwnerCanDestroyIndividual CertifierCanDestroy Definition Tag x 11 FriendlyName Category Description Glyph ``` **Token ID definitions:** `Random`. | Parameter | XML type | | ------------------- | -------------------- | | `NodeID` | `stringParameter` | | `SourceID` | `stringParameter` | | `PartitionID` | `stringParameter` | | `JID` | `stringParameter` | | `Momentary` | `booleanParameter` | | `Identity` | `booleanParameter` | | `Status` | `booleanParameter` | | `Computed` | `booleanParameter` | | `Peak` | `booleanParameter` | | `PollingInterval` | `durationParameter` | | `Value` | `numericalParameter` | | `Currency` | `stringParameter` | | `CommissionPercent` | `numericalParameter` | | `Expires` | `dateParameter` | **Machine states:** `Active`, `Paused`, `Reconfiguring`, `Done`. **Element namespaces:** `https://paiwise.tagroot.io/Schema/NeuroFeatures.xsd`, `https://paiwise.tagroot.io/Schema/StateMachines.xsd`, `urn:nf:iot:leg:sc:1.0`. To adapt this template, supply the exact role assignments and parameter names above, review fixed values in the original XML, and align the human-readable terms with every changed machine rule. Validate before provider review. **Tested Neuron runtime:** not yet recorded. Local XML validity does not establish the declared result. **Original file:** `MicroLoan.xml`. **Document kind:** contract-template. **Declared result:** Declares creation for 1 token identifier. Provider approval, signatures, and execution must be verified separately. [View original XML](https://github.com/Trust-Anchor-Group/LegalLab/blob/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/StateMachines/MicroLoan.xml) · [Download XML](https://raw.githubusercontent.com/Trust-Anchor-Group/LegalLab/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/StateMachines/MicroLoan.xml) **Local XML validation:** Passes the selected schema and explicit machine-reference checks. **Required roles:** `Creator` (1–1 signers), `Lender` (1–1 signers), `Borrower` (1–1 signers), `TrustProvider` (1–1 signers). **Structural preview** (an outline, not copy-paste XML): ```text theme={null} Create TokenID Creator Owner Certifier TrustProvider Value Currency CommissionPercent Expires CreatorCanDestroy OwnerCanDestroyBatch OwnerCanDestroyIndividual CertifierCanDestroy Definition Tag x 23 FriendlyName Category Description Glyph ``` **Token ID definitions:** `Random`. | Parameter | XML type | | ------------------------ | -------------------- | | `Amount` | `numericalParameter` | | `Currency` | `stringParameter` | | `InstallmentInterval` | `durationParameter` | | `InterestPerInstallment` | `numericalParameter` | | `DebtLimit` | `numericalParameter` | | `InstallmentAmount` | `numericalParameter` | | `CommissionPercent` | `numericalParameter` | | `Cost` | `calcParameter` | | `RoI` | `calcParameter` | | `NrInstallments` | `calcParameter` | | `EstimatedCompletion` | `calcParameter` | | `Expires` | `calcParameter` | | `LenderCountry` | `calcParameter` | | `BorrowerCountry` | `calcParameter` | | `CreatorCountry` | `calcParameter` | | `LenderName` | `roleParameter` | | `LenderAddress` | `roleParameter` | | `LenderCountryCode` | `roleParameter` | | `LenderPnr` | `roleParameter` | | `BorrowerName` | `roleParameter` | | `BorrowerAddress` | `roleParameter` | | `BorrowerCountryCode` | `roleParameter` | | `BorrowerPnr` | `roleParameter` | | `CreatorName` | `roleParameter` | | `CreatorAddress` | `roleParameter` | | `CreatorCountryCode` | `roleParameter` | | `CreatorPnr` | `roleParameter` | **Machine states:** `Setup`, `Paying`, `Paid`. **Element namespaces:** `https://paiwise.tagroot.io/Schema/NeuroFeatures.xsd`, `https://paiwise.tagroot.io/Schema/StateMachines.xsd`, `urn:nf:iot:leg:sc:1.0`. To adapt this template, supply the exact role assignments and parameter names above, review fixed values in the original XML, and align the human-readable terms with every changed machine rule. Validate before provider review. **Tested Neuron runtime:** not yet recorded. Local XML validity does not establish the declared result. **Original file:** `ProjectEscrow.xml`. **Document kind:** contract-template. Explore an advanced contract involving funds and staged actions. Provider rules and payment behavior must be reviewed before execution. **Declared result:** Declares creation for 1 token identifier. Provider approval, signatures, and execution must be verified separately. [View original XML](https://github.com/Trust-Anchor-Group/LegalLab/blob/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/StateMachines/ProjectEscrow.xml) · [Download XML](https://raw.githubusercontent.com/Trust-Anchor-Group/LegalLab/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/StateMachines/ProjectEscrow.xml) **Local XML validation:** Passes the selected schema and explicit machine-reference checks. **Required roles:** `Creator` (1–1 signers), `ProjectOwner` (1–1 signers), `EscrowAgent` (1–1 signers), `TrustProvider` (1–1 signers). **Structural preview** (an outline, not copy-paste XML): ```text theme={null} Create TokenID Creator Owner Certifier TrustProvider Value Currency CommissionPercent Expires CreatorCanDestroy OwnerCanDestroyBatch OwnerCanDestroyIndividual CertifierCanDestroy Definition Tag x 7 FriendlyName Category Description Glyph ``` **Token ID definitions:** `Random`. | Parameter | XML type | | ------------------- | -------------------- | | `Value` | `numericalParameter` | | `Currency` | `stringParameter` | | `CommissionPercent` | `numericalParameter` | | `Expires` | `dateParameter` | | `ThresholdAmount` | `numericalParameter` | | `MaxIntervalAmount` | `numericalParameter` | | `MaxInterval` | `durationParameter` | | `ProjectStart` | `dateTimeParameter` | **Machine states:** `OpenForInvestment`, `ThresholdNotReached`, `ProjectStarted`, `Done`. **Element namespaces:** `https://paiwise.tagroot.io/Schema/NeuroFeatures.xsd`, `https://paiwise.tagroot.io/Schema/StateMachines.xsd`, `urn:nf:iot:leg:sc:1.0`. To adapt this template, supply the exact role assignments and parameter names above, review fixed values in the original XML, and align the human-readable terms with every changed machine rule. Validate before provider review. **Tested Neuron runtime:** not yet recorded. Local XML validity does not establish the declared result. ### Syntax **Original file:** `CalculatedParameters.xml`. **Document kind:** contract-template. Learn how instance inputs feed calculated contract parameters. Compare the machine values with the human-readable parameter references. **Declared result:** Defines contract syntax and human-readable terms with a no-operation machine instruction. [View original XML](https://github.com/Trust-Anchor-Group/LegalLab/blob/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Syntax/CalculatedParameters.xml) · [Download XML](https://raw.githubusercontent.com/Trust-Anchor-Group/LegalLab/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Syntax/CalculatedParameters.xml) **Local XML validation:** Passes the selected schema and explicit machine-reference checks. **Required roles:** `Author` (1–1 signers). **Structural preview** (an outline, not copy-paste XML): ```text theme={null} Nop ``` | Parameter | XML type | | --------- | -------------------- | | `A` | `numericalParameter` | | `B` | `numericalParameter` | | `Sum` | `calcParameter` | | `Prod` | `calcParameter` | | `Pow` | `calcParameter` | **Element namespaces:** `https://paiwise.tagroot.io/Schema/PaymentInstructions.xsd`, `urn:nf:iot:leg:sc:1.0`. To adapt this template, supply the exact role assignments and parameter names above, review fixed values in the original XML, and align the human-readable terms with every changed machine rule. Validate before provider review. **Tested Neuron runtime:** not yet recorded. Local XML validity does not establish the declared result. **Original file:** `GeoSpatialParameters.xml`. **Document kind:** contract-template. **Declared result:** Defines contract syntax and human-readable terms with a no-operation machine instruction. [View original XML](https://github.com/Trust-Anchor-Group/LegalLab/blob/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Syntax/GeoSpatialParameters.xml) · [Download XML](https://raw.githubusercontent.com/Trust-Anchor-Group/LegalLab/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Syntax/GeoSpatialParameters.xml) **Local XML validation:** Passes the selected schema and explicit machine-reference checks. **Required roles:** `Author` (1–1 signers). **Structural preview** (an outline, not copy-paste XML): ```text theme={null} Nop ``` | Parameter | XML type | | --------------------- | ----------------- | | `Observation` | `stringParameter` | | `ObservationLocation` | `geoParameter` | | `ObservationTime` | `calcParameter` | **Element namespaces:** `https://paiwise.tagroot.io/Schema/PaymentInstructions.xsd`, `urn:nf:iot:leg:sc:1.0`. To adapt this template, supply the exact role assignments and parameter names above, review fixed values in the original XML, and align the human-readable terms with every changed machine rule. Validate before provider review. **Tested Neuron runtime:** not yet recorded. Local XML validity does not establish the declared result. **Original file:** `Markdown.xml`. **Document kind:** contract-template. **Declared result:** Defines contract syntax and human-readable terms with a no-operation machine instruction. [View original XML](https://github.com/Trust-Anchor-Group/LegalLab/blob/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Syntax/Markdown.xml) · [Download XML](https://raw.githubusercontent.com/Trust-Anchor-Group/LegalLab/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Syntax/Markdown.xml) **Local XML validation:** Passes the selected schema and explicit machine-reference checks. **Required roles:** `Author` (1–1 signers). **Structural preview** (an outline, not copy-paste XML): ```text theme={null} Nop ``` | Parameter | XML type | | --------- | ----------------- | | `Example` | `stringParameter` | **Element namespaces:** `https://paiwise.tagroot.io/Schema/PaymentInstructions.xsd`, `urn:nf:iot:leg:sc:1.0`. To adapt this template, supply the exact role assignments and parameter names above, review fixed values in the original XML, and align the human-readable terms with every changed machine rule. Validate before provider review. **Tested Neuron runtime:** not yet recorded. Local XML validity does not establish the declared result. **Original file:** `ParameterTypes.xml`. **Document kind:** contract-template. Compare typed parameter definitions and their constraints before defining your own contract inputs. **Declared result:** Defines contract syntax and human-readable terms with a no-operation machine instruction. [View original XML](https://github.com/Trust-Anchor-Group/LegalLab/blob/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Syntax/ParameterTypes.xml) · [Download XML](https://raw.githubusercontent.com/Trust-Anchor-Group/LegalLab/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Syntax/ParameterTypes.xml) **Local XML validation:** Passes the selected schema and explicit machine-reference checks. **Required roles:** `Creator` (1–1 signers). **Structural preview** (an outline, not copy-paste XML): ```text theme={null} Nop ``` | Parameter | XML type | | ----------- | -------------------- | | `Numeric1` | `numericalParameter` | | `String1` | `stringParameter` | | `Boolean1` | `booleanParameter` | | `Date1` | `dateParameter` | | `DateTime1` | `dateTimeParameter` | | `Time1` | `timeParameter` | | `Duration1` | `durationParameter` | | `Calc1` | `calcParameter` | **Element namespaces:** `https://paiwise.tagroot.io/Schema/PaymentInstructions.xsd`, `urn:nf:iot:leg:sc:1.0`. To adapt this template, supply the exact role assignments and parameter names above, review fixed values in the original XML, and align the human-readable terms with every changed machine rule. Validate before provider review. **Tested Neuron runtime:** not yet recorded. Local XML validity does not establish the declared result. **Original file:** `RoleReferenceParameters.xml`. **Document kind:** contract-template. **Declared result:** Defines contract syntax and human-readable terms with a no-operation machine instruction. [View original XML](https://github.com/Trust-Anchor-Group/LegalLab/blob/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Syntax/RoleReferenceParameters.xml) · [Download XML](https://raw.githubusercontent.com/Trust-Anchor-Group/LegalLab/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Syntax/RoleReferenceParameters.xml) **Local XML validation:** Passes the selected schema and explicit machine-reference checks. **Required roles:** `Seller` (1–1 signers), `Buyer` (1–1 signers). **Structural preview** (an outline, not copy-paste XML): ```text theme={null} Nop ``` | Parameter | XML type | | ----------------- | ----------------- | | `Reference` | `stringParameter` | | `SellerFirstName` | `roleParameter` | | `SellerLastName` | `roleParameter` | | `BuyerFirstName` | `roleParameter` | | `BuyerLastName` | `roleParameter` | **Element namespaces:** `https://paiwise.tagroot.io/Schema/PaymentInstructions.xsd`, `urn:nf:iot:leg:sc:1.0`. To adapt this template, supply the exact role assignments and parameter names above, review fixed values in the original XML, and align the human-readable terms with every changed machine rule. Validate before provider review. **Tested Neuron runtime:** not yet recorded. Local XML validity does not establish the declared result. ### Tokens **Original file:** `CreateTokenContract1.xml`. **Document kind:** contract-template. **Declared result:** Declares creation for 1 token identifier. Provider approval, signatures, and execution must be verified separately. [View original XML](https://github.com/Trust-Anchor-Group/LegalLab/blob/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Tokens/Create/CreateTokenContract1.xml) · [Download XML](https://raw.githubusercontent.com/Trust-Anchor-Group/LegalLab/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Tokens/Create/CreateTokenContract1.xml) **Local XML validation:** Passes the selected schema and explicit machine-reference checks. **Required roles:** `Creator` (1–1 signers), `Owner` (1–1 signers), `TrustProvider` (1–1 signers). **Structural preview** (an outline, not copy-paste XML): ```text theme={null} Create TokenID Creator Owner TrustProvider Value Currency CommissionPercent Expires CreatorCanDestroy OwnerCanDestroyIndividual Definition FriendlyName Category Description Glyph ``` **Token ID definitions:** `ParameterReference (parameter=TokenID)`. | Parameter | XML type | | --------------------------- | -------------------- | | `TokenID` | `stringParameter` | | `Value` | `numericalParameter` | | `Currency` | `stringParameter` | | `CommissionPercent` | `numericalParameter` | | `Expires` | `dateParameter` | | `CreatorCanDestroy` | `booleanParameter` | | `OwnerCanDestroyIndividual` | `booleanParameter` | | `FriendlyName` | `stringParameter` | **Element namespaces:** `https://paiwise.tagroot.io/Schema/NeuroFeatures.xsd`, `https://paiwise.tagroot.io/Schema/PaymentInstructions.xsd`, `urn:nf:iot:leg:sc:1.0`. To adapt this template, supply the exact role assignments and parameter names above, review fixed values in the original XML, and align the human-readable terms with every changed machine rule. Validate before provider review. **Tested Neuron runtime:** not yet recorded. Local XML validity does not establish the declared result. **Original file:** `CreateTokenContract1RandomId.xml`. **Document kind:** contract-template. **Declared result:** Declares creation for 1 token identifier. Provider approval, signatures, and execution must be verified separately. [View original XML](https://github.com/Trust-Anchor-Group/LegalLab/blob/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Tokens/Create/CreateTokenContract1RandomId.xml) · [Download XML](https://raw.githubusercontent.com/Trust-Anchor-Group/LegalLab/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Tokens/Create/CreateTokenContract1RandomId.xml) **Local XML validation:** Passes the selected schema and explicit machine-reference checks. **Required roles:** `Creator` (1–1 signers), `Owner` (1–1 signers), `TrustProvider` (1–1 signers). **Structural preview** (an outline, not copy-paste XML): ```text theme={null} Create TokenID Creator Owner TrustProvider Value Currency CommissionPercent Expires CreatorCanDestroy OwnerCanDestroyIndividual Definition FriendlyName Category Description Glyph ``` **Token ID definitions:** `Random`. | Parameter | XML type | | --------------------------- | -------------------- | | `Value` | `numericalParameter` | | `Currency` | `stringParameter` | | `CommissionPercent` | `numericalParameter` | | `Expires` | `dateParameter` | | `CreatorCanDestroy` | `booleanParameter` | | `OwnerCanDestroyIndividual` | `booleanParameter` | | `FriendlyName` | `stringParameter` | **Element namespaces:** `https://paiwise.tagroot.io/Schema/NeuroFeatures.xsd`, `https://paiwise.tagroot.io/Schema/PaymentInstructions.xsd`, `urn:nf:iot:leg:sc:1.0`. To adapt this template, supply the exact role assignments and parameter names above, review fixed values in the original XML, and align the human-readable terms with every changed machine rule. Validate before provider review. **Tested Neuron runtime:** not yet recorded. Local XML validity does not establish the declared result. **Original file:** `CreateTokenContract1UniqueId.xml`. **Document kind:** contract-template. **Declared result:** Declares creation for 1 token identifier. Provider approval, signatures, and execution must be verified separately. [View original XML](https://github.com/Trust-Anchor-Group/LegalLab/blob/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Tokens/Create/CreateTokenContract1UniqueId.xml) · [Download XML](https://raw.githubusercontent.com/Trust-Anchor-Group/LegalLab/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Tokens/Create/CreateTokenContract1UniqueId.xml) **Local XML validation:** Passes the selected schema and explicit machine-reference checks. **Required roles:** `Creator` (1–1 signers), `Owner` (1–1 signers), `TrustProvider` (1–1 signers). **Structural preview** (an outline, not copy-paste XML): ```text theme={null} Create TokenID Creator Owner TrustProvider Value Currency CommissionPercent Expires CreatorCanDestroy OwnerCanDestroyIndividual Definition FriendlyName Category Description Glyph ``` **Token ID definitions:** `Unique`. | Parameter | XML type | | --------------------------- | -------------------- | | `Value` | `numericalParameter` | | `Currency` | `stringParameter` | | `CommissionPercent` | `numericalParameter` | | `Expires` | `dateParameter` | | `CreatorCanDestroy` | `booleanParameter` | | `OwnerCanDestroyIndividual` | `booleanParameter` | | `FriendlyName` | `stringParameter` | **Element namespaces:** `https://paiwise.tagroot.io/Schema/NeuroFeatures.xsd`, `https://paiwise.tagroot.io/Schema/PaymentInstructions.xsd`, `urn:nf:iot:leg:sc:1.0`. To adapt this template, supply the exact role assignments and parameter names above, review fixed values in the original XML, and align the human-readable terms with every changed machine rule. Validate before provider review. **Tested Neuron runtime:** not yet recorded. Local XML validity does not establish the declared result. **Original file:** `CreateTokenContract5.xml`. **Document kind:** contract-template. **Declared result:** Declares creation for 5 token identifiers. Provider approval, signatures, and execution must be verified separately. [View original XML](https://github.com/Trust-Anchor-Group/LegalLab/blob/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Tokens/Create/CreateTokenContract5.xml) · [Download XML](https://raw.githubusercontent.com/Trust-Anchor-Group/LegalLab/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Tokens/Create/CreateTokenContract5.xml) **Local XML validation:** Passes the selected schema and explicit machine-reference checks. **Required roles:** `Creator` (1–1 signers), `Owner` (1–1 signers), `TrustProvider` (1–1 signers). **Structural preview** (an outline, not copy-paste XML): ```text theme={null} Create TokenID x 5 Creator Owner TrustProvider Value Currency CommissionPercent Expires CreatorCanDestroy OwnerCanDestroyBatch Definition FriendlyName Category Description Glyph ``` **Token ID definitions:** `ParameterReference (parameter=TokenID1)`, `ParameterReference (parameter=TokenID2)`, `ParameterReference (parameter=TokenID3)`, `ParameterReference (parameter=TokenID4)`, `ParameterReference (parameter=TokenID5)`. | Parameter | XML type | | ---------------------- | -------------------- | | `TokenID1` | `stringParameter` | | `TokenID2` | `stringParameter` | | `TokenID3` | `stringParameter` | | `TokenID4` | `stringParameter` | | `TokenID5` | `stringParameter` | | `Value` | `numericalParameter` | | `Currency` | `stringParameter` | | `CommissionPercent` | `numericalParameter` | | `Expires` | `dateParameter` | | `CreatorCanDestroy` | `booleanParameter` | | `OwnerCanDestroyBatch` | `booleanParameter` | | `FriendlyName` | `stringParameter` | | `TotalValue` | `calcParameter` | **Element namespaces:** `https://paiwise.tagroot.io/Schema/NeuroFeatures.xsd`, `https://paiwise.tagroot.io/Schema/PaymentInstructions.xsd`, `urn:nf:iot:leg:sc:1.0`. To adapt this template, supply the exact role assignments and parameter names above, review fixed values in the original XML, and align the human-readable terms with every changed machine rule. Validate before provider review. **Tested Neuron runtime:** not yet recorded. Local XML validity does not establish the declared result. **Original file:** `CreateTokenContract5RandomId.xml`. **Document kind:** contract-template. **Declared result:** Declares creation for 5 token identifiers. Provider approval, signatures, and execution must be verified separately. [View original XML](https://github.com/Trust-Anchor-Group/LegalLab/blob/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Tokens/Create/CreateTokenContract5RandomId.xml) · [Download XML](https://raw.githubusercontent.com/Trust-Anchor-Group/LegalLab/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Tokens/Create/CreateTokenContract5RandomId.xml) **Local XML validation:** Passes the selected schema and explicit machine-reference checks. **Required roles:** `Creator` (1–1 signers), `Owner` (1–1 signers), `TrustProvider` (1–1 signers). **Structural preview** (an outline, not copy-paste XML): ```text theme={null} Create TokenID x 5 Creator Owner TrustProvider Value Currency CommissionPercent Expires CreatorCanDestroy OwnerCanDestroyBatch Definition FriendlyName Category Description Glyph ``` **Token ID definitions:** `Random`, `Random`, `Random`, `Random`, `Random`. | Parameter | XML type | | ---------------------- | -------------------- | | `Value` | `numericalParameter` | | `Currency` | `stringParameter` | | `CommissionPercent` | `numericalParameter` | | `Expires` | `dateParameter` | | `CreatorCanDestroy` | `booleanParameter` | | `OwnerCanDestroyBatch` | `booleanParameter` | | `FriendlyName` | `stringParameter` | | `TotalValue` | `calcParameter` | **Element namespaces:** `https://paiwise.tagroot.io/Schema/NeuroFeatures.xsd`, `https://paiwise.tagroot.io/Schema/PaymentInstructions.xsd`, `urn:nf:iot:leg:sc:1.0`. To adapt this template, supply the exact role assignments and parameter names above, review fixed values in the original XML, and align the human-readable terms with every changed machine rule. Validate before provider review. **Tested Neuron runtime:** not yet recorded. Local XML validity does not establish the declared result. **Original file:** `CreateTokenContract5UniqueId.xml`. **Document kind:** contract-template. **Declared result:** Declares creation for 5 token identifiers. Provider approval, signatures, and execution must be verified separately. [View original XML](https://github.com/Trust-Anchor-Group/LegalLab/blob/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Tokens/Create/CreateTokenContract5UniqueId.xml) · [Download XML](https://raw.githubusercontent.com/Trust-Anchor-Group/LegalLab/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Tokens/Create/CreateTokenContract5UniqueId.xml) **Local XML validation:** Passes the selected schema and explicit machine-reference checks. **Required roles:** `Creator` (1–1 signers), `Owner` (1–1 signers), `TrustProvider` (1–1 signers). **Structural preview** (an outline, not copy-paste XML): ```text theme={null} Create TokenID x 5 Creator Owner TrustProvider Value Currency CommissionPercent Expires CreatorCanDestroy OwnerCanDestroyBatch Definition FriendlyName Category Description Glyph ``` **Token ID definitions:** `Unique`, `Unique`, `Unique`, `Unique`, `Unique`. | Parameter | XML type | | ---------------------- | -------------------- | | `Value` | `numericalParameter` | | `Currency` | `stringParameter` | | `CommissionPercent` | `numericalParameter` | | `Expires` | `dateParameter` | | `CreatorCanDestroy` | `booleanParameter` | | `OwnerCanDestroyBatch` | `booleanParameter` | | `FriendlyName` | `stringParameter` | | `TotalValue` | `calcParameter` | **Element namespaces:** `https://paiwise.tagroot.io/Schema/NeuroFeatures.xsd`, `https://paiwise.tagroot.io/Schema/PaymentInstructions.xsd`, `urn:nf:iot:leg:sc:1.0`. To adapt this template, supply the exact role assignments and parameter names above, review fixed values in the original XML, and align the human-readable terms with every changed machine rule. Validate before provider review. **Tested Neuron runtime:** not yet recorded. Local XML validity does not establish the declared result. **Original file:** `Achievement.xml`. **Document kind:** contract-template. **Declared result:** Declares creation for 1 token identifier. Provider approval, signatures, and execution must be verified separately. [View original XML](https://github.com/Trust-Anchor-Group/LegalLab/blob/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Tokens/Create/Specific/Achievement.xml) · [Download XML](https://raw.githubusercontent.com/Trust-Anchor-Group/LegalLab/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Tokens/Create/Specific/Achievement.xml) **Local XML validation:** Passes the selected schema and explicit machine-reference checks. **Required roles:** `Creator` (1–1 signers), `TrustProvider` (1–1 signers), `Recipient` (1–1 signers). **Structural preview** (an outline, not copy-paste XML): ```text theme={null} Create TokenID Creator Owner TrustProvider Value Currency CommissionPercent CommissionPaidBy Expires CreatorCanDestroy OwnerCanDestroyIndividual Definition FriendlyName Category Description Glyph ``` **Token ID definitions:** `Unique`. | Parameter | XML type | | ------------------- | -------------------- | | `Value` | `numericalParameter` | | `Currency` | `stringParameter` | | `CommissionPercent` | `numericalParameter` | | `Achievement` | `stringParameter` | | `Reference` | `stringParameter` | **Element namespaces:** `https://paiwise.tagroot.io/Schema/NeuroFeatures.xsd`, `https://paiwise.tagroot.io/Schema/PaymentInstructions.xsd`, `urn:nf:iot:leg:sc:1.0`. To adapt this template, supply the exact role assignments and parameter names above, review fixed values in the original XML, and align the human-readable terms with every changed machine rule. Validate before provider review. **Tested Neuron runtime:** not yet recorded. Local XML validity does not establish the declared result. **Original file:** `DemoToken.xml`. **Document kind:** contract-template. Start with one token whose creator is also its initial owner. Review the value, commission, expiry, permissions, and friendly-name parameters. **Declared result:** Declares creation for 1 token identifier. Provider approval, signatures, and execution must be verified separately. [View original XML](https://github.com/Trust-Anchor-Group/LegalLab/blob/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Tokens/Create/Specific/DemoToken.xml) · [Download XML](https://raw.githubusercontent.com/Trust-Anchor-Group/LegalLab/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Tokens/Create/Specific/DemoToken.xml) **Local XML validation:** Passes the selected schema and explicit machine-reference checks. **Required roles:** `Creator` (1–1 signers), `TrustProvider` (1–1 signers). **Structural preview** (an outline, not copy-paste XML): ```text theme={null} Create TokenID Creator Owner TrustProvider Value Currency CommissionPercent Expires CreatorCanDestroy OwnerCanDestroyIndividual Definition FriendlyName Category Description Glyph ``` **Token ID definitions:** `Random`. | Parameter | XML type | | --------------------------- | -------------------- | | `Value` | `numericalParameter` | | `Currency` | `stringParameter` | | `CommissionPercent` | `numericalParameter` | | `Expires` | `dateParameter` | | `CreatorCanDestroy` | `booleanParameter` | | `OwnerCanDestroyIndividual` | `booleanParameter` | | `FriendlyName` | `stringParameter` | **Element namespaces:** `https://paiwise.tagroot.io/Schema/NeuroFeatures.xsd`, `https://paiwise.tagroot.io/Schema/PaymentInstructions.xsd`, `urn:nf:iot:leg:sc:1.0`. To adapt this template, supply the exact role assignments and parameter names above, review fixed values in the original XML, and align the human-readable terms with every changed machine rule. Validate before provider review. **Tested Neuron runtime:** not yet recorded. Local XML validity does not establish the declared result. **Original file:** `DemoTokens5.xml`. **Document kind:** contract-template. **Declared result:** Declares creation for 5 token identifiers. Provider approval, signatures, and execution must be verified separately. [View original XML](https://github.com/Trust-Anchor-Group/LegalLab/blob/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Tokens/Create/Specific/DemoTokens5.xml) · [Download XML](https://raw.githubusercontent.com/Trust-Anchor-Group/LegalLab/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Tokens/Create/Specific/DemoTokens5.xml) **Local XML validation:** Passes the selected schema and explicit machine-reference checks. **Required roles:** `Creator` (1–1 signers), `TrustProvider` (1–1 signers). **Structural preview** (an outline, not copy-paste XML): ```text theme={null} Create TokenID x 5 Creator Owner TrustProvider Value Currency CommissionPercent Expires CreatorCanDestroy OwnerCanDestroyBatch OwnerCanDestroyIndividual Definition FriendlyName Category Description Glyph ``` **Token ID definitions:** `Random`, `Random`, `Random`, `Random`, `Random`. | Parameter | XML type | | --------------------------- | -------------------- | | `Value` | `numericalParameter` | | `Currency` | `stringParameter` | | `CommissionPercent` | `numericalParameter` | | `Expires` | `dateParameter` | | `CreatorCanDestroy` | `booleanParameter` | | `OwnerCanDestroyBatch` | `booleanParameter` | | `OwnerCanDestroyIndividual` | `booleanParameter` | | `FriendlyName` | `stringParameter` | | `TotalValue` | `calcParameter` | **Element namespaces:** `https://paiwise.tagroot.io/Schema/NeuroFeatures.xsd`, `https://paiwise.tagroot.io/Schema/PaymentInstructions.xsd`, `urn:nf:iot:leg:sc:1.0`. To adapt this template, supply the exact role assignments and parameter names above, review fixed values in the original XML, and align the human-readable terms with every changed machine rule. Validate before provider review. **Tested Neuron runtime:** not yet recorded. Local XML validity does not establish the declared result. **Original file:** `DestroyTokenContract1.xml`. **Document kind:** contract-template. **Declared result:** Declares destruction for 1 token identifier. Provider approval, signatures, and execution must be verified separately. [View original XML](https://github.com/Trust-Anchor-Group/LegalLab/blob/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Tokens/Destroy/DestroyTokenContract1.xml) · [Download XML](https://raw.githubusercontent.com/Trust-Anchor-Group/LegalLab/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Tokens/Destroy/DestroyTokenContract1.xml) **Local XML validation:** Passes the selected schema and explicit machine-reference checks. **Required roles:** `Owner` (1–1 signers), `TrustProvider` (1–1 signers). **Structural preview** (an outline, not copy-paste XML): ```text theme={null} Destroy TokenID Owner TrustProvider ``` **Token ID definitions:** `ParameterReference (parameter=TokenID)`. | Parameter | XML type | | --------- | ----------------- | | `TokenID` | `stringParameter` | **Element namespaces:** `https://paiwise.tagroot.io/Schema/NeuroFeatures.xsd`, `urn:nf:iot:leg:sc:1.0`. To adapt this template, supply the exact role assignments and parameter names above, review fixed values in the original XML, and align the human-readable terms with every changed machine rule. Validate before provider review. **Tested Neuron runtime:** not yet recorded. Local XML validity does not establish the declared result. **Original file:** `DestroyTokenContract5.xml`. **Document kind:** contract-template. **Declared result:** Declares destruction for 5 token identifiers. Provider approval, signatures, and execution must be verified separately. [View original XML](https://github.com/Trust-Anchor-Group/LegalLab/blob/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Tokens/Destroy/DestroyTokenContract5.xml) · [Download XML](https://raw.githubusercontent.com/Trust-Anchor-Group/LegalLab/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Tokens/Destroy/DestroyTokenContract5.xml) **Local XML validation:** Passes the selected schema and explicit machine-reference checks. **Required roles:** `Owner` (1–1 signers), `TrustProvider` (1–1 signers). **Structural preview** (an outline, not copy-paste XML): ```text theme={null} Destroy TokenID x 5 Owner TrustProvider ``` **Token ID definitions:** `ParameterReference (parameter=TokenID1)`, `ParameterReference (parameter=TokenID2)`, `ParameterReference (parameter=TokenID3)`, `ParameterReference (parameter=TokenID4)`, `ParameterReference (parameter=TokenID5)`. | Parameter | XML type | | ---------- | ----------------- | | `TokenID1` | `stringParameter` | | `TokenID2` | `stringParameter` | | `TokenID3` | `stringParameter` | | `TokenID4` | `stringParameter` | | `TokenID5` | `stringParameter` | **Element namespaces:** `https://paiwise.tagroot.io/Schema/NeuroFeatures.xsd`, `urn:nf:iot:leg:sc:1.0`. To adapt this template, supply the exact role assignments and parameter names above, review fixed values in the original XML, and align the human-readable terms with every changed machine rule. Validate before provider review. **Tested Neuron runtime:** not yet recorded. Local XML validity does not establish the declared result. **Original file:** `DonateTokenContract1.xml`. **Document kind:** contract-template. **Declared result:** Declares donation for 1 token identifier. Provider approval, signatures, and execution must be verified separately. [View original XML](https://github.com/Trust-Anchor-Group/LegalLab/blob/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Tokens/Donate/DonateTokenContract1.xml) · [Download XML](https://raw.githubusercontent.com/Trust-Anchor-Group/LegalLab/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Tokens/Donate/DonateTokenContract1.xml) **Local XML validation:** Passes the selected schema and explicit machine-reference checks. **Required roles:** `Donor` (1–1 signers), `Recipient` (1–1 signers), `TrustProvider` (1–1 signers). **Structural preview** (an outline, not copy-paste XML): ```text theme={null} Donate TokenID Donor Recipient TrustProvider OwnershipContract ``` **Token ID definitions:** `ParameterReference (parameter=TokenID)`. | Parameter | XML type | | ------------------- | ----------------- | | `TokenID` | `stringParameter` | | `OwnershipContract` | `stringParameter` | **Element namespaces:** `https://paiwise.tagroot.io/Schema/NeuroFeatures.xsd`, `urn:nf:iot:leg:sc:1.0`. To adapt this template, supply the exact role assignments and parameter names above, review fixed values in the original XML, and align the human-readable terms with every changed machine rule. Validate before provider review. **Tested Neuron runtime:** not yet recorded. Local XML validity does not establish the declared result. **Original file:** `DonateTokenContract5.xml`. **Document kind:** contract-template. **Declared result:** Declares donation for 5 token identifiers. Provider approval, signatures, and execution must be verified separately. [View original XML](https://github.com/Trust-Anchor-Group/LegalLab/blob/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Tokens/Donate/DonateTokenContract5.xml) · [Download XML](https://raw.githubusercontent.com/Trust-Anchor-Group/LegalLab/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Tokens/Donate/DonateTokenContract5.xml) **Local XML validation:** Passes the selected schema and explicit machine-reference checks. **Required roles:** `Donor` (1–1 signers), `Recipient` (1–1 signers), `TrustProvider` (1–1 signers). **Structural preview** (an outline, not copy-paste XML): ```text theme={null} Donate TokenID x 5 Donor Recipient TrustProvider OwnershipContract ``` **Token ID definitions:** `ParameterReference (parameter=TokenID1)`, `ParameterReference (parameter=TokenID2)`, `ParameterReference (parameter=TokenID3)`, `ParameterReference (parameter=TokenID4)`, `ParameterReference (parameter=TokenID5)`. | Parameter | XML type | | ------------------- | ----------------- | | `TokenID1` | `stringParameter` | | `TokenID2` | `stringParameter` | | `TokenID3` | `stringParameter` | | `TokenID4` | `stringParameter` | | `TokenID5` | `stringParameter` | | `OwnershipContract` | `stringParameter` | **Element namespaces:** `https://paiwise.tagroot.io/Schema/NeuroFeatures.xsd`, `urn:nf:iot:leg:sc:1.0`. To adapt this template, supply the exact role assignments and parameter names above, review fixed values in the original XML, and align the human-readable terms with every changed machine rule. Validate before provider review. **Tested Neuron runtime:** not yet recorded. Local XML validity does not establish the declared result. **Original file:** `TransferTokenContract1.xml`. **Document kind:** contract-template. **Declared result:** Declares ownership transfer for 1 token identifier. Provider approval, signatures, and execution must be verified separately. [View original XML](https://github.com/Trust-Anchor-Group/LegalLab/blob/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Tokens/Transfer/TransferTokenContract1.xml) · [Download XML](https://raw.githubusercontent.com/Trust-Anchor-Group/LegalLab/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Tokens/Transfer/TransferTokenContract1.xml) **Local XML validation:** Passes the selected schema and explicit machine-reference checks. **Required roles:** `Seller` (1–1 signers), `Buyer` (1–1 signers), `TrustProvider` (1–1 signers). **Structural preview** (an outline, not copy-paste XML): ```text theme={null} Transfer TokenID Seller Buyer TrustProvider Value Currency CommissionPercent OwnershipContract ``` **Token ID definitions:** `ParameterReference (parameter=TokenID)`. | Parameter | XML type | | ------------------- | -------------------- | | `TokenID` | `stringParameter` | | `Value` | `numericalParameter` | | `Currency` | `stringParameter` | | `CommissionPercent` | `numericalParameter` | | `OwnershipContract` | `stringParameter` | **Element namespaces:** `https://paiwise.tagroot.io/Schema/NeuroFeatures.xsd`, `urn:nf:iot:leg:sc:1.0`. To adapt this template, supply the exact role assignments and parameter names above, review fixed values in the original XML, and align the human-readable terms with every changed machine rule. Validate before provider review. **Tested Neuron runtime:** not yet recorded. Local XML validity does not establish the declared result. **Original file:** `TransferTokenContract5.xml`. **Document kind:** contract-template. **Declared result:** Declares ownership transfer for 5 token identifiers. Provider approval, signatures, and execution must be verified separately. [View original XML](https://github.com/Trust-Anchor-Group/LegalLab/blob/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Tokens/Transfer/TransferTokenContract5.xml) · [Download XML](https://raw.githubusercontent.com/Trust-Anchor-Group/LegalLab/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Tokens/Transfer/TransferTokenContract5.xml) **Local XML validation:** Passes the selected schema and explicit machine-reference checks. **Required roles:** `Seller` (1–1 signers), `Buyer` (1–1 signers), `TrustProvider` (1–1 signers). **Structural preview** (an outline, not copy-paste XML): ```text theme={null} Transfer TokenID x 5 Seller Buyer TrustProvider Value Currency CommissionPercent OwnershipContract ``` **Token ID definitions:** `ParameterReference (parameter=TokenID1)`, `ParameterReference (parameter=TokenID2)`, `ParameterReference (parameter=TokenID3)`, `ParameterReference (parameter=TokenID4)`, `ParameterReference (parameter=TokenID5)`. | Parameter | XML type | | ------------------- | -------------------- | | `TokenID1` | `stringParameter` | | `TokenID2` | `stringParameter` | | `TokenID3` | `stringParameter` | | `TokenID4` | `stringParameter` | | `TokenID5` | `stringParameter` | | `Value` | `numericalParameter` | | `Currency` | `stringParameter` | | `CommissionPercent` | `numericalParameter` | | `OwnershipContract` | `stringParameter` | | `TotalValue` | `calcParameter` | **Element namespaces:** `https://paiwise.tagroot.io/Schema/NeuroFeatures.xsd`, `urn:nf:iot:leg:sc:1.0`. To adapt this template, supply the exact role assignments and parameter names above, review fixed values in the original XML, and align the human-readable terms with every changed machine rule. Validate before provider review. **Tested Neuron runtime:** not yet recorded. Local XML validity does not establish the declared result. ### Voting **Original file:** `OpenBallotYesNoAbstain.xml`. **Document kind:** contract-template. **Declared result:** Declares a `Ballot` contract instruction. Its marketplace/provider outcome requires separate approval and execution verification. [View original XML](https://github.com/Trust-Anchor-Group/LegalLab/blob/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Voting/OpenBallotYesNoAbstain.xml) · [Download XML](https://raw.githubusercontent.com/Trust-Anchor-Group/LegalLab/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Voting/OpenBallotYesNoAbstain.xml) **Additional example schemas:** `https://paiwise.tagroot.io/Schema/OpenVote.xsd`. Load these dependencies alongside the base schemas using the [validation guide](/resources/validate-xml). **Local XML validation:** Passes the selected schema and explicit machine-reference checks. **Required roles:** `Voter` (1–1 signers). **Structural preview** (an outline, not copy-paste XML): ```text theme={null} Ballot Option x 3 ``` | Parameter | XML type | | ---------------- | ---------------------------- | | `VoteReference` | `contractReferenceParameter` | | `Yes` | `booleanParameter` | | `No` | `booleanParameter` | | `Abstain` | `booleanParameter` | | `Comment` | `stringParameter` | | `FullName` | `roleParameter` | | `PersonalNumber` | `roleParameter` | | `Country` | `roleParameter` | **Element namespaces:** `https://paiwise.tagroot.io/Schema/OpenVote.xsd`, `urn:nf:iot:leg:sc:1.0`. To adapt this template, supply the exact role assignments and parameter names above, review fixed values in the original XML, and align the human-readable terms with every changed machine rule. Validate before provider review. **Tested Neuron runtime:** not yet recorded. Local XML validity does not establish the declared result. **Original file:** `OpenVoteResultLayout.xml`. **Document kind:** layout. **Declared result:** Defines a display layout. It is not a complete contract or an asset creation request. [View original XML](https://github.com/Trust-Anchor-Group/LegalLab/blob/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Voting/OpenVoteResultLayout.xml) · [Download XML](https://raw.githubusercontent.com/Trust-Anchor-Group/LegalLab/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Voting/OpenVoteResultLayout.xml) **Additional example schemas:** `http://waher.se/Schema/Layout2D.xsd`. Load these dependencies alongside the base schemas using the [validation guide](/resources/validate-xml). **Local XML validation:** Passes the selected schema and explicit machine-reference checks. **Required roles:** See the original document. **Structural preview** (an outline, not copy-paste XML): ```text theme={null} Layout2D SolidPen x 9 SolidBackground x 5 Font x 16 Rectangle Overlays ``` **Element namespaces:** `http://waher.se/Schema/Layout2D.xsd`. To adapt this file, update its schema-defined data or layout fields. Do not submit it directly to ProposeTemplate: that operation requires a complete contract envelope. **Tested Neuron runtime:** not yet recorded. Local XML validity does not establish the declared result. **Original file:** `OpenVoteYesNoAbstain.xml`. **Document kind:** contract-template. **Declared result:** Declares creation for 1 token identifier. Provider approval, signatures, and execution must be verified separately. [View original XML](https://github.com/Trust-Anchor-Group/LegalLab/blob/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Voting/OpenVoteYesNoAbstain.xml) · [Download XML](https://raw.githubusercontent.com/Trust-Anchor-Group/LegalLab/d6fac7d837fe244a0c057cd527635deebfc5088d/ExampleContracts/Voting/OpenVoteYesNoAbstain.xml) **Local XML validation:** Passes the selected schema and explicit machine-reference checks. **Required roles:** `Creator` (1–1 signers), `Certifier` (1–1 signers), `TrustProvider` (1–1 signers). **Structural preview** (an outline, not copy-paste XML): ```text theme={null} Create TokenID Creator Owner Certifier TrustProvider Value Currency CommissionPercent Expires CreatorCanDestroy OwnerCanDestroyBatch OwnerCanDestroyIndividual CertifierCanDestroy Definition Tag x 9 FriendlyName Category Description Glyph ``` **Token ID definitions:** `Unique`. | Parameter | XML type | | ------------------- | ------------------- | | `Question` | `stringParameter` | | `ChangeVoteAllowed` | `booleanParameter` | | `LedgerCollection` | `stringParameter` | | `From` | `dateTimeParameter` | | `To` | `dateTimeParameter` | | `Expires` | `dateParameter` | | `CreatorFullName` | `roleParameter` | | `CreatorJid` | `roleParameter` | | `CreatorEMail` | `roleParameter` | **Machine states:** `Preparing`, `Pending`, `Open`, `Closed`, `Terminated`. **Element namespaces:** `https://paiwise.tagroot.io/Schema/NeuroFeatures.xsd`, `https://paiwise.tagroot.io/Schema/StateMachines.xsd`, `urn:nf:iot:leg:sc:1.0`. To adapt this template, supply the exact role assignments and parameter names above, review fixed values in the original XML, and align the human-readable terms with every changed machine rule. Validate before provider review. **Tested Neuron runtime:** not yet recorded. Local XML validity does not establish the declared result. ## Adapt an example deliberately Replace template-specific identifiers, role assignments, provider attributes, and parameter values. Explain each machine rule in the human-readable terms. Revalidate after changes; changing a reviewed template can require a new approval. The originals remain published by LegalLab's authors. Their presence in this gallery does not grant additional redistribution rights. The [machine-readable catalog](/downloads/contract-examples.json) records provenance, hashes, and structure for each file. The [local validation results](/downloads/legal-lab-validation.json) identify the exact schema set, original hashes, and unresolved dependencies. These checks do not execute expressions inside escaped XML, approve a template, or test provider behavior. # Author a custom contract schema Source: https://docs.neuro-tech.io/resources/custom-schemas Define your own machine-readable XML, validate a complete contract locally, and prepare schema resolution for provider review Define a custom schema when your contract needs a domain-specific XML vocabulary. Use the existing token, payment, and state-machine schemas when they already express the required behavior. This example adds an `Acknowledgement` element with a required positive `policyVersion`. It describes contract data. An XSD does not install executable behavior or create a new Agent API operation. ## 1. Choose a namespace and version Download [Acknowledgement-v1.xsd](/downloads/examples/Acknowledgement-v1.xsd). The file uses a reserved example address: ```text theme={null} https://schemas.example.com/neuro/Acknowledgement-v1.xsd ``` This address is a placeholder, not a published schema service. It works locally because you supply an explicit namespace-to-file map. Before provider submission, use a versioned namespace you control and the resolution method accepted by your provider. Unlike an upstream namespace, which you must preserve, this example's custom namespace is yours to replace. Change it consistently in the XSD's `targetNamespace`, the contract element's `xmlns`, and your local map. ## 2. Define the allowed XML ```xml theme={null} ``` The declaration allows one global `Acknowledgement` element. Its `policyVersion` attribute is required and must be a positive integer. It permits neither child elements nor additional attributes. `elementFormDefault="qualified"` places locally declared elements in this namespace. `attributeFormDefault="unqualified"` leaves ordinary attributes without a namespace. The XSD itself uses the standard XML Schema namespace, separate from your contract vocabulary. For more complex structures, use `xs:sequence` for ordered children, `minOccurs`/`maxOccurs` for cardinality, and explicit types for values. Add `xs:import` when a dependency belongs to another namespace. Load that dependency in your local schema set too, so validation can resolve it offline. ## 3. Embed the element in a complete contract Download [custom-acknowledgement.xml](/downloads/examples/custom-acknowledgement.xml). It extends the [acknowledgement tutorial](/contracts/from-scratch) with custom machine-readable data: ```xml theme={null} ``` The rest of the contract still uses `urn:nf:iot:leg:sc:1.0`. Its human-readable terms also name policy version 1. ```xml theme={null} The participant acknowledging the stated subject. The subject the participant will review. Under policy version 1, the participant acknowledges reviewing: . This demonstration records an acknowledgement under policy version 1. The custom machine-readable element declares data; it does not define a payment or token action. The instance lasts one month, followed by one month of required archival and one month of optional archival. ``` `policyVersion` is a static value in this template. Defining a contract parameter with the same name would not establish a substitution rule in your custom vocabulary. Use a documented parameter-reference mechanism in a supported instruction when a machine value must come from instance inputs. ## 4. Create a local schema set Save the base dependencies from [the validation guide](/resources/validate-xml) and your custom XSD in a local directory. Add this association to your validator's schema-set or catalog configuration: | Namespace | Local file | | ---------------------------------------------------------- | ------------------------ | | `https://schemas.example.com/neuro/Acknowledgement-v1.xsd` | `Acknowledgement-v1.xsd` | Keep the eight base namespace associations as well. Load the resulting nine schemas and validate the complete `custom-acknowledgement.xml` file. The custom XSD's `targetNamespace` must exactly match the namespace of the embedded `Acknowledgement` element. Expected result: the complete XML passes. Confirm that your validator also catches these changes, then restore the original document: | Change | Expected result | | -------------------------------- | ---------------------------------------------------------- | | Set `policyVersion` to `0` | Fail the positive-integer constraint. | | Remove `policyVersion` | Fail the required-attribute check. | | Use an unknown element namespace | Report a missing schema; do not accept skipped validation. | If your vocabulary imports more namespaces, add each dependency to the same schema set before validating. Retain the exact files and hashes with your contract revision. ## 5. Prepare provider schema resolution The selected server implementation checks machine-content namespaces and their imports. It first looks for a stored schema; for an uncached namespace, its normal loader attempts to retrieve the schema using the namespace URI. A namespace that cannot be fetched can produce `Schema not downloadable` or `Unable to get schema file`. Before submitting your template: 1. Replace the example namespace with your controlled, versioned identifier in all three locations described above. 2. Arrange an XSD location the provider can retrieve. For the normal URI-based loader, serve the XSD at the namespace URI with XML content, without an interactive login page. 3. Make all imported namespace schemas available through the provider's supported resolution method. 4. Give the provider the exact namespace, schema bytes/hash, dependencies, complete contract, and intended data/behavior for review. 5. Confirm the supported Neuron build resolves and validates the complete contract. Local success alone does not pass this step. The current Agent API reference does not provide a general schema-registration operation. If you need a non-fetchable identifier or a provider-specific registration process, obtain that supported handoff from the provider. Do not invent a registration request or add an XMPP client connection. The published schema manifest uses SHA-256 to identify files. The selected server records schema references using its own hash metadata; these are distinct records. Do not copy a local checksum into a signed contract field. ## 6. Submit and verify the template After the provider confirms schema access and intended support, use the [HTTP authoring workflow](/contracts/from-scratch#3-propose-the-template) with your final custom contract file. Observe proposal validation, approval, instance creation, and signatures separately. Keep the exact XSD, namespace, dependency versions, approved template ID, and resulting contract IDs together. A changed schema can change which documents validate. Use a new versioned namespace for breaking changes and obtain a new template review when required. Provider resolution and the custom contract's live lifecycle have not yet been verified for this example. The supplied tests prove local XML structure and rejection of invalid values only. ## Original references * [Neuro Foundation documentation](https://neuro-foundation.io/Index.md): specifications and technical reference material. * [Script syntax and function reference](https://lab.tagroot.io/Script.md): the full language reference. # Token contract operations XML structure reference Source: https://docs.neuro-tech.io/resources/neuro-features-reference Look up exact token contract operations elements, content models, required attributes, and schema types Use this reference to check XML spelling, ordering, occurrence counts, and attribute types. It is generated from the exact XSD selected in the [schema catalog](/resources/schemas). Namespace: `https://paiwise.tagroot.io/Schema/NeuroFeatures.xsd`. [Download the original XSD](https://paiwise.tagroot.io/Schema/NeuroFeatures.xsd). SHA-256: `68ecc7cd689c5bfa57052ad692287bea2a48cac0661a3262902a01c4ebe07bfc`. ## Read the structural notation * `sequence(A, B)` requires the listed order; `choice(A, B)` selects an allowed alternative. * `[0..1]` means optional; `[1..1]` means exactly one; `unbounded` removes the upper count. * `group(Name)`, element types, and `extension(Base)` refer to declarations elsewhere in this reference or an imported schema. Inherited fields are not repeated. * Names separated by `/` identify a declaration's containing element or type. They are lookup labels, not XML element names. * Structural validity does not establish provider support, execution permissions, or successful Script evaluation. The original XSD and [validator](/resources/validate-xml) determine XML validity. For complete construction steps, use [contract authoring](/contracts/from-scratch) or [the token and machine example](/build/tokenized-assets/from-scratch). ```text theme={null} sequence(TokenID:TokenID[1..unbounded], Creator:Part[1..1], Owner:Part[0..1], Valuator:Part[0..unbounded], Assessor:Part[0..unbounded], Certifier:Part[0..unbounded], Witness:Part[0..unbounded], TrustProvider:Part[1..1], Value:Value[1..1], Currency:Value[1..1], CommissionPercent:Value[1..1], CommissionPaidBy:CommissionPaidBy[0..1], Expires:Value[1..1], CreatorCanDestroy:Value[0..1], OwnerCanDestroyBatch:Value[0..1], OwnerCanDestroyIndividual:Value[0..1], CertifierCanDestroy:Value[0..1], Reference:Value[0..1], Definition[1..1], Tag[0..unbounded], FriendlyName:Value[1..1], Category:Value[0..1], Description:Value[0..1], Glyph[1..1])[1..1] ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `TokenID`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Part`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Part`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Part`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Part`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Part`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Part`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Part`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `CommissionPaidBy`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} sequence(any(namespace=##any, processContents=strict)[1..unbounded])[1..1] ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} extension(Value) ``` | Attribute | Type | Use | Default or fixed value | | --------- | ----------- | -------- | ---------------------- | | `name` | `xs:string` | required | — | Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} extension(xs:base64Binary) ``` | Attribute | Type | Use | Default or fixed value | | ------------- | -------------------- | -------- | ---------------------- | | `contentType` | `inline type` | optional | — | | `width` | `xs:positiveInteger` | optional | — | | `height` | `xs:positiveInteger` | optional | — | ```text theme={null} sequence(TokenID:Value[1..unbounded], Owner:Part[1..1], TrustProvider:Part[1..1])[1..1] ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Part`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Part`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} sequence(TokenID:TokenID[1..unbounded], Seller:Part[1..1], Buyer:Part[1..1], TrustProvider:Part[1..1], Value:Value[1..1], Currency:Value[1..1], CommissionPercent:Value[1..1], OwnershipContract:Value[1..1])[1..1] ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `TokenID`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Part`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Part`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Part`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} sequence(TokenID:TokenID[1..unbounded], Donor:Part[1..1], Recipient:Part[1..1], TrustProvider:Part[1..1], OwnershipContract:Value[1..1])[1..1] ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `TokenID`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Part`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Part`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Part`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} choice(RoleReference:RoleReference[1..1])[1..1] ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `RoleReference`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. | Attribute | Type | Use | Default or fixed value | | --------- | ----------- | -------- | ---------------------- | | `role` | `xs:string` | required | — | ```text theme={null} choice(group(ValueTypes)[1..1])[1..1] ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} choice(ParameterReference:ParameterReference[1..1], RoleReference:RoleReference[1..1], String:xs:string[1..1], Number:xs:decimal[1..1], Boolean:xs:boolean[1..1], Uri:xs:anyURI[1..1], Binary:xs:base64Binary[1..1], Date:xs:date[1..1], DateTime:xs:dateTime[1..1], Time:xs:time[1..1])[1..1] ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `ParameterReference`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `RoleReference`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:string`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:decimal`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:boolean`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:anyURI`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:base64Binary`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:date`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:dateTime`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:time`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} choice(group(ValueTypes)[1..1], Random:Empty[1..1], Unique:Empty[1..1])[1..1] ``` | Attribute | Type | Use | Default or fixed value | | ----------------- | -------------------- | -------- | ---------------------- | | `shortIdLength` | `xs:positiveInteger` | optional | — | | `shortIdAlphabet` | `xs:string` | optional | 0123456789 | Type: `Empty`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Empty`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} complexType(name=Empty) ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. | Attribute | Type | Use | Default or fixed value | | ----------- | ----------- | -------- | ---------------------- | | `parameter` | `xs:string` | required | — | ```text theme={null} restriction(xs:string) value=Creator value=Owner ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} complexType() ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. # Developer resources Source: https://docs.neuro-tech.io/resources/overview Find schemas, Script reference, and contract examples for your Agent API application Use these resources when a build guide asks you to define contract XML, customize token behavior, or inspect an exact language feature. Start with the [Agent API quickstart](/neuron-api/quickstart) if you have not connected yet. Find the exact namespaces, source files, and validation dependencies. Choose an example by purpose and download its original XML. Learn the expression language used in contracts and state machines. Understand states, events, actions, and persisted values. Use [LegalLab](/contracts/legallab-quickstart) as an optional XML editor. Applications submit and read contracts through the [Agent API contract guide](/contracts/agent-api-quickstart). ## Original references * [Original reference documentation](https://lab.tagroot.io/Documentation/Index.md): browse the complete reference index for Agent API, MCP, contracts, and other Neuro capabilities. * [Neuro Foundation documentation](https://neuro-foundation.io/Index.md): specifications and technical reference material. * [Script syntax and function reference](https://lab.tagroot.io/Script.md): the full language reference. # Payment contract instructions XML structure reference Source: https://docs.neuro-tech.io/resources/payment-instructions-reference Look up exact payment contract instructions elements, content models, required attributes, and schema types Use this reference to check XML spelling, ordering, occurrence counts, and attribute types. It is generated from the exact XSD selected in the [schema catalog](/resources/schemas). Namespace: `https://paiwise.tagroot.io/Schema/PaymentInstructions.xsd`. [Download the original XSD](https://paiwise.tagroot.io/Schema/PaymentInstructions.xsd). SHA-256: `2a31a75fff11e5372c8cbaf4f595fa89227a37b02871dc5e47475f4cd1c84e55`. ## Read the structural notation * `sequence(A, B)` requires the listed order; `choice(A, B)` selects an allowed alternative. * `[0..1]` means optional; `[1..1]` means exactly one; `unbounded` removes the upper count. * `group(Name)`, element types, and `extension(Base)` refer to declarations elsewhere in this reference or an imported schema. Inherited fields are not repeated. * Names separated by `/` identify a declaration's containing element or type. They are lookup labels, not XML element names. * Structural validity does not establish provider support, execution permissions, or successful Script evaluation. The original XSD and [validator](/resources/validate-xml) determine XML validity. For complete construction steps, use [contract authoring](/contracts/from-scratch) or [the token and machine example](/build/tokenized-assets/from-scratch). ```text theme={null} choice(Payment[1..1])[1..unbounded] ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. | Attribute | Type | Use | Default or fixed value | | --------- | ----------- | -------- | ---------------------- | | `comment` | `xs:string` | optional | — | ```text theme={null} sequence(Amount:Value[1..1], Currency:Value[1..1])[1..1] ``` | Attribute | Type | Use | Default or fixed value | | ----------------- | ----------- | -------- | ---------------------- | | `serviceProvider` | `xs:string` | required | — | | `serviceId` | `xs:string` | required | — | Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} sequence(Amount:Value[1..1], Currency:Value[1..1])[1..1] ``` | Attribute | Type | Use | Default or fixed value | | ----------------- | ----------- | -------- | ---------------------- | | `serviceProvider` | `xs:string` | required | — | | `serviceId` | `xs:string` | required | — | Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} sequence(From:Part[1..1], To:Part[1..1], Amount:Value[1..1], AmountExtra:Value[0..1], Currency:Value[1..1], ValidDays:Value[1..1], Reference:Value[1..1], Condition:Value[0..1])[1..1] ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Part`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Part`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} choice(RoleReference:RoleReference[1..1])[1..1] ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `RoleReference`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. | Attribute | Type | Use | Default or fixed value | | --------- | ----------- | -------- | ---------------------- | | `role` | `xs:string` | required | — | ```text theme={null} choice(ParameterReference:ParameterReference[1..1], Expression:xs:string[1..1], ContractID[1..1], String:xs:string[1..1], Number:xs:decimal[1..1], Boolean:xs:boolean[1..1], Uri:xs:anyURI[1..1], Binary:xs:base64Binary[1..1], Date:xs:date[1..1], DateTime:xs:dateTime[1..1], Time:xs:time[1..1])[1..1] ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `ParameterReference`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:string`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:string`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:decimal`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:boolean`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:anyURI`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:base64Binary`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:date`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:dateTime`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:time`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. | Attribute | Type | Use | Default or fixed value | | ----------- | ----------- | -------- | ---------------------- | | `parameter` | `xs:string` | required | — | # XML schema catalog Source: https://docs.neuro-tech.io/resources/schemas Download contract, token, and state-machine XSD files with exact namespaces and validation dependencies Choose a schema by its exact namespace. Contract XML, token creation XML, and embedded state-machine XML use different namespaces, even when they appear in one file. For specifications and further reference, see the [Neuro Foundation documentation](https://neuro-foundation.io/Index.md). For expressions inside contracts and state machines, see the [original Script reference](https://lab.tagroot.io/Script.md). ## Download the contract authoring schema set | Schema | Exact namespace | Local filename | Original file | | ----------------------------- | ----------------------------------------------------------- | ------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Smart contracts | `urn:nf:iot:leg:sc:1.0` | `SmartContracts.xsd` | [Download XSD](https://raw.githubusercontent.com/PeterWaher/IoTGateway/43705bab39e89da8f2e5e4d72c55cba6f2a43bbd/Networking/Waher.Networking.XMPP.Contracts/Schema/SmartContracts.xsd) | | Legal Identities | `urn:nf:iot:leg:id:1.0` | `LegalIdentities.xsd` | [Download XSD](https://raw.githubusercontent.com/PeterWaher/IoTGateway/43705bab39e89da8f2e5e4d72c55cba6f2a43bbd/Networking/Waher.Networking.XMPP.Contracts/Schema/LegalIdentities.xsd) | | Identity key formats | `urn:nf:iot:e2e:1.0` | `E2E.xsd` | [Download XSD](https://raw.githubusercontent.com/PeterWaher/IoTGateway/43705bab39e89da8f2e5e4d72c55cba6f2a43bbd/Networking/Waher.Networking.XMPP.Contracts/Schema/E2E.xsd) | | Imported peer address types | `urn:nf:iot:p2p:1.0` | `P2P.xsd` | [Download XSD](https://raw.githubusercontent.com/PeterWaher/IoTGateway/43705bab39e89da8f2e5e4d72c55cba6f2a43bbd/Networking/Waher.Networking.XMPP.Contracts/Schema/P2P.xsd) | | XML language attributes | `http://www.w3.org/XML/1998/namespace` | `Xml.xsd` | [Download XSD](https://www.w3.org/2001/xml.xsd) | | Token contract operations | `https://paiwise.tagroot.io/Schema/NeuroFeatures.xsd` | `NeuroFeatures.xsd` | [Download XSD](https://paiwise.tagroot.io/Schema/NeuroFeatures.xsd) | | Token state machines | `https://paiwise.tagroot.io/Schema/StateMachines.xsd` | `StateMachines.xsd` | [Download XSD](https://paiwise.tagroot.io/Schema/StateMachines.xsd) | | Payment contract instructions | `https://paiwise.tagroot.io/Schema/PaymentInstructions.xsd` | `PaymentInstructions.xsd` | [Download XSD](https://paiwise.tagroot.io/Schema/PaymentInstructions.xsd) | ## Validate a complete document Use [the XML validation guide](/resources/validate-xml) to load all eight dependencies into your XML validator and check a complete document offline. Check state, action, and event references as a separate step. XML validation does not establish Script behavior, signature validity, provider approval, or live execution. The [schema manifest](/downloads/xml-tools/schema-manifest.json) records exact revisions, SHA-256 checksums, and dependencies. Download the original publisher files above and compare their checksums. Consult the publisher's terms before redistributing their files. ## Understand the dependencies The contract schema imports identity, key, and XML attribute definitions. Identity imports key definitions; the key schema imports peer-address types. These imports do not all contain file locations. Associate every namespace above with its local file in your validator; opening one XSD in isolation is insufficient. The XML-attribute dependency uses the [W3C XML schema](https://www.w3.org/2001/xml.xsd). Load it alongside the other schema dependencies. ## Match the namespace to your service This set uses `urn:nf:iot:leg:sc:1.0`. Other published material includes `urn:nfi:iot:leg:sc:1.0` and older `urn:ieee:iot:leg:sc:1.0` interfaces. They are distinct identifiers. Ask your provider which set its supported build accepts before submitting a template. Local compilation of this set has been checked. Compatibility with your Neuron and approval of a particular template require separate verification. ## Additional LegalLab example schemas Twelve gallery files also use one or more of these dependencies. The optional example set combines these five XSDs with the eight base schemas; all 42 pinned gallery files pass its local XML checks. | Purpose | Exact namespace | Local filename | Original file | | --------------------------- | --------------------------------------------------------- | ------------------------ | ----------------------------------------------------------------------- | | BIM register example | `https://lab.tagroot.io/Downloads/BimRegister.xsd` | `BimRegister.xsd` | [Download XSD](https://lab.tagroot.io/Downloads/BimRegister.xsd) | | Marketplace examples | `https://paiwise.tagroot.io/Schema/Marketplace.xsd` | `Marketplace.xsd` | [Download XSD](https://paiwise.tagroot.io/Schema/Marketplace.xsd) | | Layout2D display content | `http://waher.se/Schema/Layout2D.xsd` | `Layout2D.xsd` | [Download XSD](https://waher.se/Schema/Layout2D.xsd) | | Organization layout example | `https://lab.tagroot.io/Downloads/SimpleOrganization.xsd` | `SimpleOrganization.xsd` | [Download XSD](https://lab.tagroot.io/Downloads/SimpleOrganization.xsd) | | Open vote examples | `https://paiwise.tagroot.io/Schema/OpenVote.xsd` | `OpenVote.xsd` | [Download XSD](https://paiwise.tagroot.io/Schema/OpenVote.xsd) | Add these five schemas to the same local schema set as the eight base files, using the exact namespace-to-file associations above. The [additional dependency manifest](/downloads/xml-tools/example-schema-additions.json) pins the original bytes. The organization schema imports Layout2D. Its namespace remains `http://waher.se/Schema/Layout2D.xsd` even though the file downloads over HTTPS. Never change a namespace merely to match the download protocol. ## Continue authoring * [Author a custom schema](/resources/custom-schemas). * [Look up contract elements](/resources/smart-contracts-reference). * [Look up token creation elements](/resources/neuro-features-reference). * [Look up state-machine elements](/resources/state-machines-reference). * [Look up payment instruction elements](/resources/payment-instructions-reference). * [Choose a LegalLab example](/resources/contract-examples). * [Understand the contract data model](/contracts/data-model). * [Define token state machines](/contracts/state-machines). * [Write Neuron Script](/script/overview). # Smart contracts XML structure reference Source: https://docs.neuro-tech.io/resources/smart-contracts-reference Look up exact smart contracts elements, content models, required attributes, and schema types Use this reference to check XML spelling, ordering, occurrence counts, and attribute types. It is generated from the exact XSD selected in the [schema catalog](/resources/schemas). Namespace: `urn:nf:iot:leg:sc:1.0`. [Download the original XSD](https://raw.githubusercontent.com/PeterWaher/IoTGateway/43705bab39e89da8f2e5e4d72c55cba6f2a43bbd/Networking/Waher.Networking.XMPP.Contracts/Schema/SmartContracts.xsd). SHA-256: `e98ab8dab423abad4b5cda0d2e506d9466b8afd1882bded40fb68754d6143196`. ## Read the structural notation * `sequence(A, B)` requires the listed order; `choice(A, B)` selects an allowed alternative. * `[0..1]` means optional; `[1..1]` means exactly one; `unbounded` removes the upper count. * `group(Name)`, element types, and `extension(Base)` refer to declarations elsewhere in this reference or an imported schema. Inherited fields are not repeated. * Names separated by `/` identify a declaration's containing element or type. They are lookup labels, not XML element names. * Structural validity does not establish provider support, execution permissions, or successful Script evaluation. The original XSD and [validator](/resources/validate-xml) determine XML validity. For complete construction steps, use [contract authoring](/contracts/from-scratch) or [the token and machine example](/build/tokenized-assets/from-scratch). ```text theme={null} sequence(choice(contract[1..1], template[1..1])[1..1], transient[0..1])[1..1] ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} sequence(parts[0..1], parameters[0..1])[1..1] ``` | Attribute | Type | Use | Default or fixed value | | --------- | ----------------- | -------- | ---------------------- | | `id` | `xs:string` | required | — | | `nonce` | `xs:base64Binary` | optional | — | ```text theme={null} sequence(any(namespace=##any, processContents=lax)[1..1], role[0..unbounded], parts[0..1], parameters[0..1], humanReadableText:HumanReadableText[1..unbounded], signature[0..unbounded], attachment[0..unbounded], status[0..1], serverSignature[0..1], attachmentRef[0..unbounded])[1..1] ``` | Attribute | Type | Use | Default or fixed value | | --------- | ----------------- | -------- | ---------------------- | | `id` | `xs:string` | optional | — | | `nonce` | `xs:base64Binary` | optional | — | ```text theme={null} sequence(description:HumanReadableText[1..unbounded])[1..1] ``` | Attribute | Type | Use | Default or fixed value | | ----------- | ----------------------- | -------- | ---------------------- | | `name` | `NonEmptyString` | required | — | | `minCount` | `xs:nonNegativeInteger` | required | — | | `maxCount` | `xs:nonNegativeInteger` | required | — | | `canRevoke` | `xs:boolean` | optional | false | Type: `HumanReadableText`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `HumanReadableText`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} extension(xs:base64Binary) ``` | Attribute | Type | Use | Default or fixed value | | ----------- | ---------------- | -------- | ---------------------- | | `legalId` | `NonEmptyString` | required | — | | `bareJid` | `NonEmptyString` | required | — | | `role` | `NonEmptyString` | required | — | | `timestamp` | `xs:dateTime` | required | — | ```text theme={null} sequence(roleParameters[0..1])[1..1] ``` | Attribute | Type | Use | Default or fixed value | | -------------------- | ----------------- | -------- | ---------------------- | | `provider` | `NonEmptyString` | required | — | | `state` | `ContractState` | required | — | | `created` | `xs:dateTime` | required | — | | `updated` | `xs:dateTime` | optional | — | | `from` | `xs:dateTime` | optional | — | | `to` | `xs:dateTime` | optional | — | | `templateId` | `NonEmptyString` | optional | — | | `schemaDigest` | `xs:base64Binary` | optional | — | | `schemaHashFunction` | `HashFunction` | optional | — | ```text theme={null} sequence(parameter[0..unbounded])[1..1] ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} extension(xs:base64Binary) ``` | Attribute | Type | Use | Default or fixed value | | ------------- | ----------------- | -------- | ---------------------- | | `name` | `xs:string` | required | — | | `value` | `xs:string` | required | — | | `contentType` | `xs:string` | optional | — | | `legalId` | `xs:string` | optional | — | | `fileName` | `xs:string` | optional | — | | `signature` | `xs:base64Binary` | optional | — | | `timestamp` | `xs:dateTime` | optional | — | | `url` | `xs:anyURI` | optional | — | ```text theme={null} extension(xs:base64Binary) ``` | Attribute | Type | Use | Default or fixed value | | ----------- | ------------- | -------- | ---------------------- | | `timestamp` | `xs:dateTime` | required | — | Type: `Parameters`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Parameters`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} choice(stringParameter:StringParameter[1..1], numericalParameter:NumericalParameter[1..1], booleanParameter:BooleanParameter[1..1], dateParameter:DateParameter[1..1], timeParameter:TimeParameter[1..1], dateTimeParameter:DateTimeParameter[1..1], durationParameter:DurationParameter[1..1], geoParameter:GeoParameter[1..1], calcParameter:CalcParameter[1..1], roleParameter:RoleParameter[1..1], contractReferenceParameter:ContractReferenceParameter[1..1], attachmentParameter:AttachmentParameter[1..1], recordSet:RecordSet[1..1])[1..unbounded] ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `StringParameter`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `NumericalParameter`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `BooleanParameter`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `DateParameter`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `TimeParameter`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `DateTimeParameter`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `DurationParameter`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `GeoParameter`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `CalcParameter`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `RoleParameter`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `ContractReferenceParameter`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `AttachmentParameter`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `RecordSet`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} sequence(description:HumanReadableText[0..unbounded], recordDefinition:Parameters[1..1], record:Parameters[0..unbounded])[1..1] ``` | Attribute | Type | Use | Default or fixed value | | ------------ | ----------------------- | -------- | ---------------------- | | `name` | `NonEmptyString` | required | — | | `exp` | `xs:string` | optional | — | | `maxRecords` | `xs:positiveInteger` | required | — | | `minRecords` | `xs:nonNegativeInteger` | required | — | Type: `HumanReadableText`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Parameters`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Parameters`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} sequence(description:HumanReadableText[0..unbounded])[1..1] ``` | Attribute | Type | Use | Default or fixed value | | ------------ | ----------------- | -------- | ---------------------- | | `name` | `NonEmptyString` | required | — | | `guide` | `xs:string` | optional | — | | `exp` | `xs:string` | optional | — | | `protection` | `ProtectionLevel` | optional | — | | `protected` | `xs:base64Binary` | optional | — | Type: `HumanReadableText`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} restriction(xs:string) value=Encrypted value=Transient ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} extension(Parameter) ``` | Attribute | Type | Use | Default or fixed value | | ------------- | ----------------------- | -------- | ---------------------- | | `value` | `xs:string` | optional | — | | `regEx` | `xs:string` | optional | — | | `min` | `xs:string` | optional | — | | `minIncluded` | `xs:boolean` | optional | true | | `max` | `xs:string` | optional | — | | `maxIncluded` | `xs:boolean` | optional | true | | `minLength` | `xs:nonNegativeInteger` | optional | — | | `maxLength` | `xs:positiveInteger` | optional | — | ```text theme={null} extension(Parameter) ``` | Attribute | Type | Use | Default or fixed value | | ------------- | ------------ | -------- | ---------------------- | | `value` | `xs:decimal` | optional | — | | `min` | `xs:decimal` | optional | — | | `minIncluded` | `xs:boolean` | optional | true | | `max` | `xs:decimal` | optional | — | | `maxIncluded` | `xs:boolean` | optional | true | ```text theme={null} extension(Parameter) ``` | Attribute | Type | Use | Default or fixed value | | --------- | ------------ | -------- | ---------------------- | | `value` | `xs:boolean` | optional | — | ```text theme={null} extension(Parameter) ``` | Attribute | Type | Use | Default or fixed value | | ------------- | ------------ | -------- | ---------------------- | | `value` | `xs:date` | optional | — | | `min` | `xs:date` | optional | — | | `minIncluded` | `xs:boolean` | optional | true | | `max` | `xs:date` | optional | — | | `maxIncluded` | `xs:boolean` | optional | true | ```text theme={null} extension(Parameter) ``` | Attribute | Type | Use | Default or fixed value | | ------------- | ------------- | -------- | ---------------------- | | `value` | `xs:dateTime` | optional | — | | `min` | `xs:dateTime` | optional | — | | `minIncluded` | `xs:boolean` | optional | true | | `max` | `xs:dateTime` | optional | — | | `maxIncluded` | `xs:boolean` | optional | true | ```text theme={null} extension(Parameter) ``` | Attribute | Type | Use | Default or fixed value | | ------------- | ------------ | -------- | ---------------------- | | `value` | `xs:time` | optional | — | | `min` | `xs:time` | optional | — | | `minIncluded` | `xs:boolean` | optional | true | | `max` | `xs:time` | optional | — | | `maxIncluded` | `xs:boolean` | optional | true | ```text theme={null} extension(Parameter) ``` | Attribute | Type | Use | Default or fixed value | | ------------- | ------------- | -------- | ---------------------- | | `value` | `xs:duration` | optional | — | | `min` | `xs:duration` | optional | — | | `minIncluded` | `xs:boolean` | optional | true | | `max` | `xs:duration` | optional | — | | `maxIncluded` | `xs:boolean` | optional | true | ```text theme={null} extension(Parameter) ``` | Attribute | Type | Use | Default or fixed value | | ------------------ | ------------- | -------- | ---------------------- | | `value` | `GeoSpatial` | optional | — | | `contractLocation` | `xs:boolean` | optional | false | | `min` | `GeoSpatial` | optional | — | | `minIncluded` | `xs:boolean` | optional | true | | `max` | `GeoSpatial` | optional | — | | `maxIncluded` | `xs:boolean` | optional | true | | `altitude` | `inline type` | optional | optional | ```text theme={null} restriction(xs:string) pattern=(?'Lat'-?\d+(\.\d+)?),(?'Long'-?\d+(\.\d+)?)(,(?'Alt'-?\d+(\.\d+)?))? ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} extension(Parameter) ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} extension(Parameter) ``` | Attribute | Type | Use | Default or fixed value | | ------------- | -------------------- | -------- | ---------------------- | | `role` | `xs:string` | required | — | | `index` | `xs:positiveInteger` | required | — | | `property` | `xs:string` | required | — | | `required` | `xs:boolean` | optional | false | | `contentType` | `xs:string` | optional | — | ```text theme={null} extension(Parameter) sequence(label[0..unbounded])[1..1] ``` | Attribute | Type | Use | Default or fixed value | | ------------- | ------------ | -------- | ---------------------- | | `value` | `xs:string` | optional | — | | `required` | `xs:boolean` | optional | false | | `localName` | `xs:string` | optional | — | | `namespace` | `xs:string` | optional | — | | `templateId` | `xs:string` | optional | — | | `provider` | `xs:string` | optional | — | | `creatorRole` | `xs:string` | optional | — | ```text theme={null} group(InlineElements)[1..unbounded] ``` | Attribute | Type | Use | Default or fixed value | | ---------- | ------------- | -------- | ---------------------- | | `xml:lang` | `inline type` | optional | — | ```text theme={null} extension(Parameter) ``` | Attribute | Type | Use | Default or fixed value | | ------------- | -------------------- | -------- | ---------------------- | | `value` | `xs:string` | optional | — | | `required` | `xs:boolean` | optional | false | | `contentType` | `xs:string` | optional | — | | `minSize` | `xs:positiveInteger` | optional | — | | `maxSize` | `xs:positiveInteger` | optional | — | | `minWidth` | `xs:positiveInteger` | optional | — | | `maxWidth` | `xs:positiveInteger` | optional | — | | `minHeight` | `xs:positiveInteger` | optional | — | | `maxHeight` | `xs:positiveInteger` | optional | — | ```text theme={null} choice(open[1..1], templateOnly[1..1], part[1..unbounded])[1..1] ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} complexType() ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} complexType() ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. | Attribute | Type | Use | Default or fixed value | | --------- | ---------------- | -------- | ---------------------- | | `legalId` | `NonEmptyString` | required | — | | `role` | `NonEmptyString` | required | — | ```text theme={null} restriction(xs:string) value=Proposed value=Rejected value=Approved value=BeingSigned value=Signed value=Failed value=Obsoleted ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} restriction(xs:string) value=SHA256 value=SHA384 value=SHA512 ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} restriction(xs:string) value=CreatorAndParts value=DomainAndParts value=Public value=PublicSearchable ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} group(BlockElements)[1..unbounded] ``` | Attribute | Type | Use | Default or fixed value | | ---------- | ------------- | -------- | ---------------------- | | `xml:lang` | `inline type` | optional | — | ```text theme={null} choice(paragraph[1..1], section[1..1], bulletItems[1..1], numberedItems[1..1], imageStandalone:ImageType[1..1], separator:Empty[1..1], table[1..1])[1..1] ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} group(InlineElements)[1..unbounded] ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} sequence(header[1..1], body[1..1])[1..1] ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} group(InlineElements)[1..unbounded] ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} group(BlockElements)[1..unbounded] ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} sequence(item[1..unbounded])[1..1] ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} choice(group(InlineElements)[1..unbounded], group(BlockElements)[1..unbounded])[1..1] ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} sequence(item[1..unbounded])[1..1] ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} choice(group(InlineElements)[1..unbounded], group(BlockElements)[1..unbounded])[1..1] ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `ImageType`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Empty`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} sequence(row[1..unbounded])[1..1] ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} sequence(cell[1..unbounded])[1..1] ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} choice(group(InlineElements)[0..unbounded], group(BlockElements)[0..unbounded])[1..1] ``` | Attribute | Type | Use | Default or fixed value | | ----------- | -------------------- | -------- | ---------------------- | | `alignment` | `inline type` | required | — | | `colSpan` | `xs:positiveInteger` | required | — | | `header` | `xs:boolean` | required | — | ```text theme={null} choice(text:NonEmptyString[1..1], parameter[1..1], bold[1..1], italic[1..1], underline[1..1], strikeThrough[1..1], super[1..1], sub[1..1], lineBreak:Empty[1..1], imageInline:ImageType[1..1])[1..1] ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `NonEmptyString`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. | Attribute | Type | Use | Default or fixed value | | --------- | ---------------- | -------- | ---------------------- | | `name` | `NonEmptyString` | required | — | ```text theme={null} group(InlineElements)[1..unbounded] ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} group(InlineElements)[1..unbounded] ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} group(InlineElements)[1..unbounded] ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} group(InlineElements)[1..unbounded] ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} group(InlineElements)[1..unbounded] ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} group(InlineElements)[1..unbounded] ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Empty`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `ImageType`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} complexType(name=Empty) ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} restriction(xs:string) minLength=1 ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} sequence(binary:xs:base64Binary[1..1], caption[1..1])[1..1] ``` | Attribute | Type | Use | Default or fixed value | | ------------- | ------------- | -------- | ---------------------- | | `contentType` | `inline type` | required | — | | `width` | `ImageSize` | required | — | | `height` | `ImageSize` | required | — | Type: `xs:base64Binary`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} group(InlineElements)[1..unbounded] ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} restriction(xs:positiveInteger) maxInclusive=2048 ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. | Attribute | Type | Use | Default or fixed value | | ------------ | ----------------------- | -------- | ---------------------- | | `offset` | `xs:nonNegativeInteger` | optional | — | | `maxCount` | `xs:positiveInteger` | optional | — | | `references` | `xs:boolean` | optional | true | | Attribute | Type | Use | Default or fixed value | | -------------- | ----------------- | -------- | ---------------------- | | `id` | `xs:string` | required | — | | `role` | `NonEmptyString` | required | — | | `transferable` | `xs:boolean` | optional | false | | `s` | `xs:base64Binary` | required | — | ```text theme={null} sequence(contract[1..1])[1..1] ``` | Attribute | Type | Use | Default or fixed value | | ------------ | ------------ | -------- | ---------------------- | | `contractId` | `xs:string` | required | — | | `legalId` | `xs:string` | required | — | | `role` | `xs:string` | required | — | | `signed` | `xs:boolean` | optional | false | | Attribute | Type | Use | Default or fixed value | | --------- | ----------- | -------- | ---------------------- | | `jid` | `xs:string` | required | — | | Attribute | Type | Use | Default or fixed value | | ------------ | ----------------------- | -------- | ---------------------- | | `offset` | `xs:nonNegativeInteger` | optional | — | | `maxCount` | `xs:positiveInteger` | optional | — | | `references` | `xs:boolean` | optional | true | ```text theme={null} sequence(ref[0..unbounded])[1..1] ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. | Attribute | Type | Use | Default or fixed value | | --------- | ----------- | -------- | ---------------------- | | `id` | `xs:string` | required | — | ```text theme={null} choice(contract[1..1], ref[1..1])[0..unbounded] ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. | Attribute | Type | Use | Default or fixed value | | --------- | ----------- | -------- | ---------------------- | | `id` | `xs:string` | required | — | | Attribute | Type | Use | Default or fixed value | | --------- | ----------- | -------- | ---------------------- | | `id` | `xs:string` | required | — | ```text theme={null} sequence(ref[0..unbounded])[1..1] ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. | Attribute | Type | Use | Default or fixed value | | --------- | ----------- | -------- | ---------------------- | | `id` | `xs:string` | required | — | ```text theme={null} sequence(idRef[1..unbounded])[1..1] ``` | Attribute | Type | Use | Default or fixed value | | --------- | ---------------- | -------- | ---------------------- | | `bareJid` | `NonEmptyString` | required | — | | Attribute | Type | Use | Default or fixed value | | --------- | ---------------- | -------- | ---------------------- | | `id` | `NonEmptyString` | required | — | Type: `xs:boolean`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. | Attribute | Type | Use | Default or fixed value | | --------- | ----------- | -------- | ---------------------- | | `id` | `xs:string` | required | — | | Attribute | Type | Use | Default or fixed value | | --------- | ----------- | -------- | ---------------------- | | `id` | `xs:string` | required | — | | Attribute | Type | Use | Default or fixed value | | ------------ | ----------- | -------- | ---------------------- | | `contractId` | `xs:string` | required | — | | Attribute | Type | Use | Default or fixed value | | ------------ | ----------- | -------- | ---------------------- | | `contractId` | `xs:string` | required | — | | Attribute | Type | Use | Default or fixed value | | ------------ | ----------- | -------- | ---------------------- | | `contractId` | `xs:string` | required | — | ```text theme={null} sequence(contract[1..1])[1..1] ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} complexType() ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} sequence(schemaRef[0..unbounded])[1..1] ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} sequence(digest[1..unbounded])[1..1] ``` | Attribute | Type | Use | Default or fixed value | | ----------- | ----------- | -------- | ---------------------- | | `namespace` | `xs:string` | required | — | ```text theme={null} extension(xs:base64Binary) ``` | Attribute | Type | Use | Default or fixed value | | ---------- | -------------- | -------- | ---------------------- | | `function` | `HashFunction` | required | — | ```text theme={null} sequence(digest[0..1])[1..1] ``` | Attribute | Type | Use | Default or fixed value | | ----------- | ----------- | -------- | ---------------------- | | `namespace` | `xs:string` | required | — | Type: `xs:base64Binary`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. | Attribute | Type | Use | Default or fixed value | | ------------ | ------------ | -------- | ---------------------- | | `contractId` | `xs:string` | required | — | | `current` | `xs:boolean` | optional | false | | `historic` | `xs:boolean` | optional | true | | Attribute | Type | Use | Default or fixed value | | ------------ | ----------- | -------- | ---------------------- | | `contractId` | `xs:string` | required | — | ```text theme={null} sequence(networkIdentity[1..1])[0..unbounded] ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. | Attribute | Type | Use | Default or fixed value | | --------- | ----------- | -------- | ---------------------- | | `bareJid` | `xs:string` | required | — | | `legalId` | `xs:string` | required | — | ```text theme={null} sequence(localName[0..1], namespace[0..1], template[0..1], role[0..unbounded], parameter[0..unbounded], created:DateTimeSearchParameter[0..1], updated:DateTimeSearchParameter[0..1], from:DateTimeSearchParameter[0..1], to:DateTimeSearchParameter[0..1], duration:DurationSearchParameter[0..1])[1..1] ``` | Attribute | Type | Use | Default or fixed value | | ---------- | ----------------------- | -------- | ---------------------- | | `offset` | `xs:nonNegativeInteger` | optional | — | | `maxCount` | `xs:positiveInteger` | optional | — | ```text theme={null} choice(eq:xs:string[1..1], like:xs:string[1..1])[1..1] ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:string`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:string`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} choice(eq:xs:string[1..1], like:xs:string[1..1])[1..1] ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:string`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:string`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} choice(eq:xs:string[1..1], like:xs:string[1..1])[1..1] ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:string`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:string`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} choice(eq:xs:string[1..1], like:xs:string[1..1])[1..1] ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:string`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:string`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} choice(eqStr:xs:string[1..1], neqStr:xs:string[1..1], gtStr:xs:string[1..1], gteStr:xs:string[1..1], ltStr:xs:string[1..1], lteStr:xs:string[1..1], like:xs:string[1..1], eqNum:xs:decimal[1..1], neqNum:xs:decimal[1..1], gtNum:xs:decimal[1..1], gteNum:xs:decimal[1..1], ltNum:xs:decimal[1..1], lteNum:xs:decimal[1..1], eqB:xs:boolean[1..1], neqB:xs:boolean[1..1], eqD:xs:date[1..1], neqD:xs:date[1..1], gtD:xs:date[1..1], gteD:xs:date[1..1], ltD:xs:date[1..1], lteD:xs:date[1..1], eqDT:xs:dateTime[1..1], neqDT:xs:dateTime[1..1], gtDT:xs:dateTime[1..1], gteDT:xs:dateTime[1..1], ltDT:xs:dateTime[1..1], lteDT:xs:dateTime[1..1], eqT:xs:time[1..1], neqT:xs:time[1..1], gtT:xs:time[1..1], gteT:xs:time[1..1], ltT:xs:time[1..1], lteT:xs:time[1..1], eqDr:xs:duration[1..1], neqDr:xs:duration[1..1], gtDr:xs:duration[1..1], gteDr:xs:duration[1..1], ltDr:xs:duration[1..1], lteDr:xs:duration[1..1])[1..unbounded] ``` | Attribute | Type | Use | Default or fixed value | | --------- | ----------- | -------- | ---------------------- | | `name` | `xs:string` | required | — | Type: `xs:string`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:string`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:string`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:string`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:string`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:string`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:string`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:decimal`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:decimal`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:decimal`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:decimal`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:decimal`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:decimal`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:boolean`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:boolean`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:date`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:date`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:date`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:date`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:date`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:date`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:dateTime`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:dateTime`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:dateTime`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:dateTime`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:dateTime`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:dateTime`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:time`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:time`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:time`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:time`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:time`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:time`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:duration`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:duration`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:duration`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:duration`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:duration`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:duration`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `DateTimeSearchParameter`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `DateTimeSearchParameter`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `DateTimeSearchParameter`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `DateTimeSearchParameter`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `DurationSearchParameter`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} sequence(ref[0..unbounded])[1..1] ``` | Attribute | Type | Use | Default or fixed value | | --------- | ------------ | -------- | ---------------------- | | `more` | `xs:boolean` | optional | false | | Attribute | Type | Use | Default or fixed value | | --------- | ----------- | -------- | ---------------------- | | `id` | `xs:string` | required | — | ```text theme={null} choice(eq:xs:dateTime[1..1], neq:xs:dateTime[1..1], gt:xs:dateTime[1..1], gte:xs:dateTime[1..1], lt:xs:dateTime[1..1], lte:xs:dateTime[1..1])[1..unbounded] ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:dateTime`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:dateTime`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:dateTime`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:dateTime`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:dateTime`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:dateTime`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} choice(eq:xs:duration[1..1], neq:xs:duration[1..1], gt:xs:duration[1..1], gte:xs:duration[1..1], lt:xs:duration[1..1], lte:xs:duration[1..1])[1..unbounded] ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:duration`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:duration`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:duration`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:duration`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:duration`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:duration`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} extension(PetitionRequest) sequence(any(namespace=##other, processContents=strict)[0..1])[1..1] ``` | Attribute | Type | Use | Default or fixed value | | --------- | ----------- | -------- | ---------------------- | | `id` | `xs:string` | required | — | ```text theme={null} sequence(properties[0..1], attachments[0..1])[1..1] ``` | Attribute | Type | Use | Default or fixed value | | --------- | ----------- | -------- | ---------------------- | | `pid` | `xs:string` | required | — | | `purpose` | `xs:string` | required | — | ```text theme={null} sequence(property:xs:string[0..unbounded])[1..1] ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:string`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} sequence(attachment:xs:string[0..unbounded])[1..1] ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:string`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} extension(Petition) ``` | Attribute | Type | Use | Default or fixed value | | --------- | ----------------- | -------- | ---------------------- | | `nonce` | `xs:string` | required | — | | `s` | `xs:base64Binary` | required | — | ```text theme={null} extension(Petition) sequence(id:identity[1..1], any(namespace=##other, processContents=strict)[0..1])[1..1] ``` | Attribute | Type | Use | Default or fixed value | | --------- | ----------- | -------- | ---------------------- | | `from` | `xs:string` | required | — | Type: `PetitionMessage`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} sequence(any(namespace=##other, processContents=strict)[0..1])[1..1] ``` | Attribute | Type | Use | Default or fixed value | | ---------- | ------------ | -------- | ---------------------- | | `id` | `xs:string` | required | — | | `pid` | `xs:string` | required | — | | `jid` | `xs:string` | required | — | | `response` | `xs:boolean` | optional | false | ```text theme={null} sequence(contract[0..1], any(namespace=##other, processContents=strict)[0..1])[1..1] ``` | Attribute | Type | Use | Default or fixed value | | ---------- | ------------ | -------- | ---------------------- | | `pid` | `xs:string` | required | — | | `response` | `xs:boolean` | required | — | | Attribute | Type | Use | Default or fixed value | | ------------ | ----------------- | -------- | ---------------------- | | `contractId` | `xs:string` | required | — | | `getUrl` | `xs:string` | required | — | | `s` | `xs:base64Binary` | required | — | | Attribute | Type | Use | Default or fixed value | | -------------- | ----------- | -------- | ---------------------- | | `attachmentId` | `xs:string` | required | — | | Attribute | Type | Use | Default or fixed value | | ------------- | ----------------- | -------- | ---------------------- | | `id` | `xs:string` | required | — | | `legalId` | `xs:string` | required | — | | `contentType` | `xs:string` | required | — | | `fileName` | `xs:string` | required | — | | `s` | `xs:base64Binary` | required | — | | `timestamp` | `xs:dateTime` | required | — | | Attribute | Type | Use | Default or fixed value | | -------------- | ----------- | -------- | ---------------------- | | `attachmentId` | `xs:string` | required | — | | `url` | `xs:anyURI` | required | — | ```text theme={null} sequence(sharedSecret[0..1])[1..1] ``` | Attribute | Type | Use | Default or fixed value | | ------------ | ----------- | -------- | ---------------------- | | `contractId` | `xs:string` | required | — | | `role` | `xs:string` | required | — | | `message` | `xs:string` | optional | — | | Attribute | Type | Use | Default or fixed value | | ----------- | ----------------- | -------- | ---------------------- | | `key` | `xs:base64Binary` | required | — | | `algorithm` | `inline type` | required | — | | Attribute | Type | Use | Default or fixed value | | ------------ | ----------- | -------- | ---------------------- | | `contractId` | `xs:string` | required | — | | `reason` | `xs:string` | required | — | # Token state machines XML structure reference Source: https://docs.neuro-tech.io/resources/state-machines-reference Look up exact token state machines elements, content models, required attributes, and schema types Use this reference to check XML spelling, ordering, occurrence counts, and attribute types. It is generated from the exact XSD selected in the [schema catalog](/resources/schemas). Namespace: `https://paiwise.tagroot.io/Schema/StateMachines.xsd`. [Download the original XSD](https://paiwise.tagroot.io/Schema/StateMachines.xsd). SHA-256: `9e0401637ec0e957ef8934b5aa83b5250f6e5235585d01c7283150ef32c583e4`. ## Read the structural notation * `sequence(A, B)` requires the listed order; `choice(A, B)` selects an allowed alternative. * `[0..1]` means optional; `[1..1]` means exactly one; `unbounded` removes the upper count. * `group(Name)`, element types, and `extension(Base)` refer to declarations elsewhere in this reference or an imported schema. Inherited fields are not repeated. * Names separated by `/` identify a declaration's containing element or type. They are lookup labels, not XML element names. * Structural validity does not establish provider support, execution permissions, or successful Script evaluation. The original XSD and [validator](/resources/validate-xml) determine XML validity. For complete construction steps, use [contract authoring](/contracts/from-scratch) or [the token and machine example](/build/tokenized-assets/from-scratch). ```text theme={null} sequence(SingletonMachineId:TagReference[0..1], Variable[0..unbounded], State[1..unbounded], Event[0..unbounded], Action[0..unbounded], NoteCommand[0..unbounded], ReportPresent:xs:string[0..1], ReportHistory:xs:string[0..1])[1..1] ``` | Attribute | Type | Use | Default or fixed value | | ------------ | ----------- | -------- | ---------------------- | | `startState` | `xs:string` | required | — | Type: `TagReference`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} extension(Value) ``` | Attribute | Type | Use | Default or fixed value | | --------- | ------- | -------- | ---------------------- | | `id` | `xs:ID` | required | — | ```text theme={null} sequence(OnEnter:ActionReference[0..unbounded], OnLeave:ActionReference[0..unbounded], OnEvent[0..unbounded])[1..1] ``` | Attribute | Type | Use | Default or fixed value | | --------- | ------- | -------- | ---------------------- | | `id` | `xs:ID` | required | — | Type: `ActionReference`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `ActionReference`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} choice(EventReference[1..1], group(EventTypes)[1..1])[1..1] ``` | Attribute | Type | Use | Default or fixed value | | -------------------- | ------------ | -------- | ---------------------- | | `actionRef` | `xs:string` | optional | — | | `beforeActionScript` | `xs:string` | optional | — | | `newState` | `xs:string` | optional | — | | `failureState` | `xs:string` | optional | — | | `suppressSample` | `xs:boolean` | optional | — | | Attribute | Type | Use | Default or fixed value | | ---------- | ----------- | -------- | ---------------------- | | `eventRef` | `xs:string` | required | — | ```text theme={null} choice(group(EventTypes)[1..1])[1..1] ``` | Attribute | Type | Use | Default or fixed value | | --------- | ------- | -------- | ---------------------- | | `id` | `xs:ID` | required | — | ```text theme={null} extension(Actions) ``` | Attribute | Type | Use | Default or fixed value | | --------- | ------- | -------- | ---------------------- | | `id` | `xs:ID` | required | — | ```text theme={null} sequence(Title:HumanReadableText[1..unbounded], ToolTip:HumanReadableText[0..unbounded], Confirmation:HumanReadableText[0..unbounded], Success:HumanReadableText[0..unbounded], Failure:HumanReadableText[0..unbounded], Parameters[0..1], NoteContextScript:xs:string[0..1], NoteGenerationScript:xs:string[1..1])[1..1] ``` | Attribute | Type | Use | Default or fixed value | | -------------- | ------------ | -------- | ---------------------- | | `id` | `xs:string` | required | — | | `ownerNote` | `xs:boolean` | optional | false | | `externalNote` | `xs:boolean` | optional | false | | `personal` | `xs:boolean` | optional | false | Type: `HumanReadableText`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `HumanReadableText`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `HumanReadableText`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `HumanReadableText`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `HumanReadableText`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} choice(StringParameter:StringParameter[1..1], NumericalParameter:NumericalParameter[1..1], BooleanParameter:BooleanParameter[1..1], DateParameter:DateParameter[1..1], TimeParameter:TimeParameter[1..1], DateTimeParameter:DateTimeParameter[1..1], DurationParameter:DurationParameter[1..1])[1..unbounded] ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `StringParameter`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `NumericalParameter`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `BooleanParameter`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `DateParameter`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `TimeParameter`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `DateTimeParameter`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `DurationParameter`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:string`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:string`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:string`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:string`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. | Attribute | Type | Use | Default or fixed value | | -------------------- | ----------- | -------- | ---------------------- | | `actionRef` | `xs:string` | required | — | | `beforeActionScript` | `xs:string` | optional | — | ```text theme={null} sequence(group(ActionTypes)[1..unbounded])[1..1] ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} choice(group(ValueTypes)[0..1])[1..1] ``` | Attribute | Type | Use | Default or fixed value | | --------- | ----------- | -------- | ---------------------- | | `value` | `xs:string` | optional | — | ```text theme={null} choice(TagReference:TagReference[1..1], TokenProperty:TokenProperty[1..1], String:xs:string[1..1], Number:xs:decimal[1..1], Boolean:xs:boolean[1..1], Uri:xs:anyURI[1..1], Binary:xs:base64Binary[1..1], Date:xs:date[1..1], DateTime:xs:dateTime[1..1], Time:xs:time[1..1], Duration:xs:duration[1..1], Calc:xs:string[1..1])[1..1] ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `TagReference`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `TokenProperty`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:string`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:decimal`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:boolean`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:anyURI`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:base64Binary`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:date`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:dateTime`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:time`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:duration`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:string`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. | Attribute | Type | Use | Default or fixed value | | --------- | ----------- | -------- | ---------------------- | | `tag` | `xs:string` | required | — | ```text theme={null} restriction(xs:string) value=TokenId value=TokenIdMethod value=Visibility value=Creator value=CreatorJid value=Owner value=OwnerJid value=TrustProvider value=TrustProviderJid value=Currency value=Reference value=Definition value=DefinitionNamespace value=CreationContract value=CreationContractTemplate value=OwnershipContract value=Value value=Created value=Updated value=Expires value=ArchiveRequired value=ArchiveOptional value=SignatureTimestamp value=Signature value=DefinitionSchemaDigest value=DefinitionSchemaHashFunction value=CreatorCanDestroy value=OwnerCanDestroyBatch value=OwnerCanDestroyIndividual value=CertifierCanDestroy value=FriendlyName value=Glyph value=GlyphContentType value=GlyphWidth value=GlyphHeight value=Ordinal value=BatchSize ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} choice(OnCondition:xs:string[1..1], OnDuration:xs:string[1..1], OnTime[1..1], OnDateTime[1..1], OnPaymentReceived[1..1], OnPaymentSent[1..1], OnTextNote[1..1], OnXmlNote[1..1], OnExternalTextNote[1..1], OnExternalXmlNote[1..1], OnContractSignature[1..1], OnContractSigned[1..1], OnContractTemplateApproved[1..1], OnDestroyed:Empty[1..1], OnTransferred[1..1], OnEntryAdded[1..1], OnEntryUpdated[1..1], OnEntryDeleted[1..1])[1..1] ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:string`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:string`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} extension(xs:string) ``` | Attribute | Type | Use | Default or fixed value | | ----------------- | ----------- | -------- | ---------------------- | | `timeCoordinates` | `xs:string` | optional | — | ```text theme={null} extension(xs:string) ``` | Attribute | Type | Use | Default or fixed value | | ----------------- | ----------- | -------- | ---------------------- | | `timeCoordinates` | `xs:string` | optional | — | | Attribute | Type | Use | Default or fixed value | | --------------------- | ----------- | -------- | ---------------------- | | `fromVariable` | `xs:string` | optional | — | | `amountVariable` | `xs:string` | optional | — | | `amountExtraVariable` | `xs:string` | optional | — | | `amountTotalVariable` | `xs:string` | optional | — | | `currencyVariable` | `xs:string` | optional | — | | `referenceVariable` | `xs:string` | optional | — | | `conditionVariable` | `xs:string` | optional | — | | Attribute | Type | Use | Default or fixed value | | --------------------- | ----------- | -------- | ---------------------- | | `toVariable` | `xs:string` | optional | — | | `amountVariable` | `xs:string` | optional | — | | `amountExtraVariable` | `xs:string` | optional | — | | `amountTotalVariable` | `xs:string` | optional | — | | `currencyVariable` | `xs:string` | optional | — | | `referenceVariable` | `xs:string` | optional | — | | `conditionVariable` | `xs:string` | optional | — | | Attribute | Type | Use | Default or fixed value | | ------------------ | ----------- | -------- | ---------------------- | | `noteVariable` | `xs:string` | optional | — | | `personalVariable` | `xs:string` | optional | — | | Attribute | Type | Use | Default or fixed value | | ------------------ | ----------- | -------- | ---------------------- | | `noteVariable` | `xs:string` | optional | — | | `personalVariable` | `xs:string` | optional | — | | `localName` | `xs:string` | optional | — | | `namespace` | `xs:string` | optional | — | | Attribute | Type | Use | Default or fixed value | | ------------------ | ----------- | -------- | ---------------------- | | `noteVariable` | `xs:string` | optional | — | | `personalVariable` | `xs:string` | optional | — | | `sourceVariable` | `xs:string` | optional | — | | `privilege` | `xs:string` | optional | — | | Attribute | Type | Use | Default or fixed value | | ------------------ | ----------- | -------- | ---------------------- | | `noteVariable` | `xs:string` | optional | — | | `personalVariable` | `xs:string` | optional | — | | `sourceVariable` | `xs:string` | optional | — | | `localName` | `xs:string` | optional | — | | `namespace` | `xs:string` | optional | — | | `privilege` | `xs:string` | optional | — | | Attribute | Type | Use | Default or fixed value | | ------------------------- | ------------------- | -------- | ---------------------- | | `contractIdVariable` | `xs:string` | optional | — | | `contractXmlVariable` | `xs:string` | optional | — | | `parametersVariable` | `xs:string` | optional | — | | `rolesVariable` | `xs:string` | optional | — | | `machineReadableVariable` | `xs:string` | optional | — | | `legalIdVariable` | `xs:string` | optional | — | | `roleVariable` | `xs:string` | optional | — | | `condition` | `xs:string` | optional | — | | `localName` | `xs:string` | optional | — | | `namespace` | `xs:string` | optional | — | | `nameType` | `SecondaryNameType` | optional | None | | Attribute | Type | Use | Default or fixed value | | ------------------------- | ------------------- | -------- | ---------------------- | | `contractIdVariable` | `xs:string` | optional | — | | `contractXmlVariable` | `xs:string` | optional | — | | `parametersVariable` | `xs:string` | optional | — | | `rolesVariable` | `xs:string` | optional | — | | `machineReadableVariable` | `xs:string` | optional | — | | `condition` | `xs:string` | optional | — | | `localName` | `xs:string` | optional | — | | `namespace` | `xs:string` | optional | — | | `nameType` | `SecondaryNameType` | optional | None | | Attribute | Type | Use | Default or fixed value | | ------------------------- | ------------------- | -------- | ---------------------- | | `contractIdVariable` | `xs:string` | optional | — | | `contractXmlVariable` | `xs:string` | optional | — | | `parametersVariable` | `xs:string` | optional | — | | `machineReadableVariable` | `xs:string` | optional | — | | `condition` | `xs:string` | optional | — | | `checkExisting` | `xs:string` | optional | — | | `localName` | `xs:string` | optional | — | | `namespace` | `xs:string` | optional | — | | `nameType` | `SecondaryNameType` | optional | None | Type: `Empty`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. | Attribute | Type | Use | Default or fixed value | | ------------------ | ----------- | -------- | ---------------------- | | `sellerVariable` | `xs:string` | optional | — | | `buyerVariable` | `xs:string` | optional | — | | `contractVariable` | `xs:string` | optional | — | | `valueVariable` | `xs:string` | optional | — | | `amountVariable` | `xs:string` | optional | — | | `currencyVariable` | `xs:string` | optional | — | | Attribute | Type | Use | Default or fixed value | | ---------------- | ----------- | -------- | ---------------------- | | `entryVariable` | `xs:string` | optional | — | | `collectionName` | `xs:string` | optional | — | | `typeName` | `xs:string` | optional | — | | Attribute | Type | Use | Default or fixed value | | ---------------- | ----------- | -------- | ---------------------- | | `entryVariable` | `xs:string` | optional | — | | `collectionName` | `xs:string` | optional | — | | `typeName` | `xs:string` | optional | — | | Attribute | Type | Use | Default or fixed value | | ---------------- | ----------- | -------- | ---------------------- | | `entryVariable` | `xs:string` | optional | — | | `collectionName` | `xs:string` | optional | — | | `typeName` | `xs:string` | optional | — | ```text theme={null} restriction(xs:string) pattern=^(Local|UTC|(\+?(0?\d|1[0-4]):(00|15|30|45))|(-(0?\d|1[0-2]):(00|15|30|45)))$ ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} choice(Payment[1..1], ReserveAmount[1..1], ReleaseAmount[1..1], BuyEDaler[1..1], SellEDaler[1..1], XmlNote[1..1], TextNote[1..1], AuthorizeSource[1..1], UnauthorizeSource[1..1], HttpPost[1..1], XmppMessage[1..1], XmppIqGet[1..1], XmppIqSet[1..1], MailMessage[1..1], PersistVariable[1..1], LogEvent[1..1], CreateEntry[1..1], PersistHash[1..1], If[1..1], IfHash[1..1], Switch[1..1], For[1..1], ForEach[1..1], While[1..1], Do[1..1], Try[1..1], Script:xs:string[1..1], CallAction:ActionReference[1..1], ScheduleAction[1..1], End:Empty[1..1], Destroy:Empty[1..1], Fail[1..1], Error[1..1])[1..1] ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} sequence(From:Value[0..1], To:Value[0..1], Amount:Value[0..1], AmountExtra:Value[0..1], Currency:Value[0..1], ValidDays:Value[0..1], Reference:Value[0..1], Contract:Value[0..1], Condition:Value[0..1])[1..1] ``` | Attribute | Type | Use | Default or fixed value | | --------------------- | ----------- | -------- | ---------------------- | | `from` | `xs:string` | optional | — | | `to` | `xs:string` | optional | — | | `amount` | `xs:string` | optional | — | | `amountExtra` | `xs:string` | optional | — | | `currency` | `xs:string` | optional | — | | `validDays` | `xs:string` | optional | — | | `reference` | `xs:string` | optional | — | | `contract` | `xs:string` | optional | — | | `condition` | `xs:string` | optional | — | | `transactionVariable` | `xs:string` | optional | — | Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} sequence(From:Value[0..1], Amount:Value[0..1], Currency:Value[0..1], ValidDays:Value[0..1], Reference:Value[0..1], Contract:Value[0..1])[1..1] ``` | Attribute | Type | Use | Default or fixed value | | --------------------- | ----------- | -------- | ---------------------- | | `from` | `xs:string` | optional | — | | `amount` | `xs:string` | optional | — | | `currency` | `xs:string` | optional | — | | `validDays` | `xs:string` | optional | — | | `reference` | `xs:string` | optional | — | | `contract` | `xs:string` | optional | — | | `transactionVariable` | `xs:string` | optional | — | Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} sequence(To:Value[0..1], Amount:Value[0..1], Currency:Value[0..1], ValidDays:Value[0..1], Reference:Value[0..1], Contract:Value[0..1])[1..1] ``` | Attribute | Type | Use | Default or fixed value | | --------------------- | ----------- | -------- | ---------------------- | | `to` | `xs:string` | optional | — | | `amount` | `xs:string` | optional | — | | `currency` | `xs:string` | optional | — | | `validDays` | `xs:string` | optional | — | | `reference` | `xs:string` | optional | — | | `contract` | `xs:string` | optional | — | | `transactionVariable` | `xs:string` | optional | — | Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} sequence(To:Value[0..1], Amount:Value[0..1], Currency:Value[0..1], Reference:Value[0..1], Contract:Value[0..1], ServiceProvider:Value[0..1], ServiceId:Value[0..1], Parameter:Parameter[0..unbounded])[1..1] ``` | Attribute | Type | Use | Default or fixed value | | ----------------- | ----------- | -------- | ---------------------- | | `to` | `xs:string` | optional | — | | `amount` | `xs:string` | optional | — | | `currency` | `xs:string` | optional | — | | `reference` | `xs:string` | optional | — | | `contract` | `xs:string` | optional | — | | `serviceProvider` | `xs:string` | optional | — | | `serviceId` | `xs:string` | optional | — | Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Parameter`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} sequence(From:Value[0..1], Amount:Value[0..1], Currency:Value[0..1], Reference:Value[0..1], Contract:Value[0..1], ServiceProvider:Value[0..1], ServiceId:Value[0..1], Parameter:Parameter[0..unbounded])[1..1] ``` | Attribute | Type | Use | Default or fixed value | | ----------------- | ----------- | -------- | ---------------------- | | `from` | `xs:string` | optional | — | | `amount` | `xs:string` | optional | — | | `currency` | `xs:string` | optional | — | | `reference` | `xs:string` | optional | — | | `contract` | `xs:string` | optional | — | | `serviceProvider` | `xs:string` | optional | — | | `serviceId` | `xs:string` | optional | — | Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Parameter`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} sequence(Content:Value[0..1], Personal:Value[0..1])[1..1] ``` | Attribute | Type | Use | Default or fixed value | | ---------- | ----------- | -------- | ---------------------- | | `content` | `xs:string` | optional | — | | `personal` | `xs:string` | optional | — | Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} sequence(Content:Value[0..1], Personal:Value[0..1])[1..1] ``` | Attribute | Type | Use | Default or fixed value | | ---------- | ----------- | -------- | ---------------------- | | `content` | `xs:string` | optional | — | | `personal` | `xs:string` | optional | — | Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} sequence(Source:Value[0..1])[1..1] ``` | Attribute | Type | Use | Default or fixed value | | --------- | ----------- | -------- | ---------------------- | | `source` | `xs:string` | optional | — | Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} sequence(Source:Value[0..1])[1..1] ``` | Attribute | Type | Use | Default or fixed value | | --------- | ----------- | -------- | ---------------------- | | `source` | `xs:string` | optional | — | Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} sequence(Header[0..unbounded], Resource:Value[0..1], Content:Value[0..1])[1..1] ``` | Attribute | Type | Use | Default or fixed value | | ------------------ | ----------- | -------- | ---------------------- | | `resource` | `xs:string` | required | — | | `content` | `xs:string` | required | — | | `responseVariable` | `xs:string` | optional | — | ```text theme={null} sequence(Key:Value[0..1], Value:Value[0..1])[1..1] ``` | Attribute | Type | Use | Default or fixed value | | --------- | ----------- | -------- | ---------------------- | | `key` | `xs:string` | optional | — | | `value` | `xs:string` | optional | — | Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} sequence(To:Value[0..1], Content:Value[0..1])[1..1] ``` | Attribute | Type | Use | Default or fixed value | | --------- | ----------- | -------- | ---------------------- | | `to` | `xs:string` | optional | — | | `content` | `xs:string` | optional | — | Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} sequence(To:Value[0..1], Content:Value[0..1])[1..1] ``` | Attribute | Type | Use | Default or fixed value | | ------------------ | ----------- | -------- | ---------------------- | | `to` | `xs:string` | optional | — | | `content` | `xs:string` | optional | — | | `responseVariable` | `xs:string` | optional | — | Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} sequence(To:Value[0..1], Content:Value[0..1])[1..1] ``` | Attribute | Type | Use | Default or fixed value | | ------------------ | ----------- | -------- | ---------------------- | | `to` | `xs:string` | optional | — | | `content` | `xs:string` | optional | — | | `responseVariable` | `xs:string` | optional | — | Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} sequence(To:Value[0..1], Subject:Value[0..1], Content:Value[0..1])[1..1] ``` | Attribute | Type | Use | Default or fixed value | | --------- | ----------- | -------- | ---------------------- | | `to` | `xs:string` | optional | — | | `subject` | `xs:string` | optional | — | | `content` | `xs:string` | optional | — | Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} sequence(Name:Value[0..1], Value:Value[0..1], OnlyIfChanged:Value[0..1])[1..1] ``` | Attribute | Type | Use | Default or fixed value | | ---------------- | ------------ | -------- | ---------------------- | | `name` | `xs:string` | optional | — | | `value` | `xs:string` | optional | — | | `onlyIfChanged` | `xs:boolean` | optional | false | | `suppressSample` | `xs:boolean` | optional | — | Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} sequence(Message:Value[0..1], Object:Value[0..1], Actor:Value[0..1], EventId:Value[0..1], Module:Value[0..1], Facility:Value[0..1], Tag[0..unbounded])[1..1] ``` | Attribute | Type | Use | Default or fixed value | | ---------- | ------------ | -------- | ---------------------- | | `message` | `xs:string` | optional | — | | `type` | `EventType` | optional | — | | `level` | `EventLevel` | optional | — | | `object` | `xs:string` | optional | — | | `actor` | `xs:string` | optional | — | | `eventId` | `xs:string` | optional | — | | `module` | `xs:string` | optional | — | | `facility` | `xs:string` | optional | — | Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} sequence(Key:Value[0..1], Value:Value[0..1])[1..1] ``` | Attribute | Type | Use | Default or fixed value | | --------- | ----------- | -------- | ---------------------- | | `key` | `xs:string` | optional | — | | `value` | `xs:string` | optional | — | Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} sequence(Collection:Value[0..1], Type:Value[0..1], Property[0..unbounded])[1..1] ``` | Attribute | Type | Use | Default or fixed value | | ------------ | ----------- | -------- | ---------------------- | | `collection` | `xs:string` | optional | — | | `type` | `xs:string` | optional | — | Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} sequence(Key:Value[0..1], Value:Value[0..1])[1..1] ``` | Attribute | Type | Use | Default or fixed value | | --------- | ----------- | -------- | ---------------------- | | `key` | `xs:string` | optional | — | | `value` | `xs:string` | optional | — | Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} sequence(Hash:Value[0..1], Expires:Value[0..1], Realm:Value[0..1], Object:Value[0..1])[1..1] ``` | Attribute | Type | Use | Default or fixed value | | --------- | ----------- | -------- | ---------------------- | | `hash` | `xs:string` | optional | — | | `expires` | `xs:string` | optional | — | | `realm` | `xs:string` | optional | — | | `object` | `xs:string` | optional | — | Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} sequence(Then:Actions[1..1], Else:Actions[0..1])[1..1] ``` | Attribute | Type | Use | Default or fixed value | | ----------- | ----------- | -------- | ---------------------- | | `condition` | `xs:string` | required | — | Type: `Actions`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Actions`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} sequence(Hash:Value[0..1], Realm:Value[0..1], Then:Actions[1..1], Else:Actions[0..1])[1..1] ``` | Attribute | Type | Use | Default or fixed value | | ---------------- | ----------- | -------- | ---------------------- | | `hash` | `xs:string` | optional | — | | `realm` | `xs:string` | optional | — | | `objectVariable` | `xs:string` | optional | — | Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Actions`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Actions`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} sequence(Case[1..unbounded], Else:Actions[0..1])[1..1] ``` | Attribute | Type | Use | Default or fixed value | | ---------- | ----------- | -------- | ---------------------- | | `selector` | `xs:string` | required | — | ```text theme={null} extension(Actions) ``` | Attribute | Type | Use | Default or fixed value | | ----------- | ----------- | -------- | ---------------------- | | `condition` | `xs:string` | required | — | Type: `Actions`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} extension(Actions) ``` | Attribute | Type | Use | Default or fixed value | | ---------- | ----------- | -------- | ---------------------- | | `variable` | `xs:string` | required | — | | `from` | `xs:string` | required | — | | `to` | `xs:string` | required | — | | `step` | `xs:string` | optional | — | ```text theme={null} extension(Actions) ``` | Attribute | Type | Use | Default or fixed value | | ---------- | ----------- | -------- | ---------------------- | | `variable` | `xs:string` | required | — | | `set` | `xs:string` | required | — | ```text theme={null} extension(Actions) ``` | Attribute | Type | Use | Default or fixed value | | ----------- | ----------- | -------- | ---------------------- | | `condition` | `xs:string` | required | — | ```text theme={null} extension(Actions) ``` | Attribute | Type | Use | Default or fixed value | | --------- | ----------- | -------- | ---------------------- | | `while` | `xs:string` | required | — | ```text theme={null} extension(Actions) sequence(Catch[0..1], Finally:Actions[0..1])[1..1] ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} extension(Actions) ``` | Attribute | Type | Use | Default or fixed value | | ------------------- | ----------- | -------- | ---------------------- | | `exceptionVariable` | `xs:string` | optional | — | Type: `Actions`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `xs:string`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `ActionReference`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} extension(ActionReference) sequence(When[1..1])[1..1] ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} extension(xs:string) ``` | Attribute | Type | Use | Default or fixed value | | ----------------- | ----------- | -------- | ---------------------- | | `timeCoordinates` | `xs:string` | optional | — | Type: `Empty`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Empty`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} sequence(Reason:Value[0..1])[1..1] ``` | Attribute | Type | Use | Default or fixed value | | ------------ | ----------- | -------- | ---------------------- | | `reason` | `xs:string` | optional | — | | `contractId` | `xs:string` | optional | — | Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} sequence(Reason:Value[0..1])[1..1] ``` | Attribute | Type | Use | Default or fixed value | | --------- | ----------- | -------- | ---------------------- | | `reason` | `xs:string` | optional | — | Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} sequence(Key:Value[0..1], Value:Value[0..1])[1..1] ``` | Attribute | Type | Use | Default or fixed value | | --------- | ----------- | -------- | ---------------------- | | `key` | `xs:string` | optional | — | | `value` | `xs:string` | optional | — | Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. Type: `Value`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} restriction(xs:string) value=Debug value=Informational value=Notice value=Warning value=Error value=Critical value=Alert value=Emergency ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} restriction(xs:string) value=Minor value=Medium value=Major ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} complexType(name=Empty) ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} restriction(xs:string) minLength=1 ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} sequence(Description:HumanReadableText[0..unbounded])[1..1] ``` | Attribute | Type | Use | Default or fixed value | | --------- | ---------------- | -------- | ---------------------- | | `name` | `NonEmptyString` | required | — | | `guide` | `xs:string` | optional | — | | `exp` | `xs:string` | optional | — | Type: `HumanReadableText`. No attributes declared directly here. Check the referenced type or base type for inherited attributes. ```text theme={null} extension(xs:string) ``` | Attribute | Type | Use | Default or fixed value | | --------- | ------------- | -------- | ---------------------- | | `lang` | `xs:language` | required | — | ```text theme={null} extension(NoteParameter) ``` | Attribute | Type | Use | Default or fixed value | | ------------- | ----------------------- | -------- | ---------------------- | | `value` | `xs:string` | optional | — | | `regEx` | `xs:string` | optional | — | | `min` | `xs:string` | optional | — | | `minIncluded` | `xs:boolean` | optional | true | | `max` | `xs:string` | optional | — | | `maxIncluded` | `xs:boolean` | optional | true | | `minLength` | `xs:nonNegativeInteger` | optional | — | | `maxLength` | `xs:positiveInteger` | optional | — | ```text theme={null} extension(NoteParameter) ``` | Attribute | Type | Use | Default or fixed value | | ------------- | ------------ | -------- | ---------------------- | | `value` | `xs:decimal` | optional | — | | `min` | `xs:decimal` | optional | — | | `minIncluded` | `xs:boolean` | optional | true | | `max` | `xs:decimal` | optional | — | | `maxIncluded` | `xs:boolean` | optional | true | ```text theme={null} extension(NoteParameter) ``` | Attribute | Type | Use | Default or fixed value | | --------- | ------------ | -------- | ---------------------- | | `value` | `xs:boolean` | optional | — | ```text theme={null} extension(NoteParameter) ``` | Attribute | Type | Use | Default or fixed value | | ------------- | ------------ | -------- | ---------------------- | | `value` | `xs:date` | optional | — | | `min` | `xs:date` | optional | — | | `minIncluded` | `xs:boolean` | optional | true | | `max` | `xs:date` | optional | — | | `maxIncluded` | `xs:boolean` | optional | true | ```text theme={null} extension(NoteParameter) ``` | Attribute | Type | Use | Default or fixed value | | ------------- | ------------- | -------- | ---------------------- | | `value` | `xs:dateTime` | optional | — | | `min` | `xs:dateTime` | optional | — | | `minIncluded` | `xs:boolean` | optional | true | | `max` | `xs:dateTime` | optional | — | | `maxIncluded` | `xs:boolean` | optional | true | ```text theme={null} extension(NoteParameter) ``` | Attribute | Type | Use | Default or fixed value | | ------------- | ------------ | -------- | ---------------------- | | `value` | `xs:time` | optional | — | | `min` | `xs:time` | optional | — | | `minIncluded` | `xs:boolean` | optional | true | | `max` | `xs:time` | optional | — | | `maxIncluded` | `xs:boolean` | optional | true | ```text theme={null} extension(NoteParameter) ``` | Attribute | Type | Use | Default or fixed value | | ------------- | ------------- | -------- | ---------------------- | | `value` | `xs:duration` | optional | — | | `min` | `xs:duration` | optional | — | | `minIncluded` | `xs:boolean` | optional | true | | `max` | `xs:duration` | optional | — | | `maxIncluded` | `xs:boolean` | optional | true | ```text theme={null} restriction(xs:string) value=None value=TokenCreation ``` No attributes declared directly here. Check the referenced type or base type for inherited attributes. # Validate contract XML locally Source: https://docs.neuro-tech.io/resources/validate-xml Load the contract schemas in your XML validator and check a complete document before submission Validate the complete contract against its XSD files before submitting it. Use an XML editor or validator that can load multiple schemas and resolve imports by namespace. ## 1. Save the schema dependencies Download the eight XSD files in the [contract authoring schema set](/resources/schemas#download-the-contract-authoring-schema-set) into one local directory. Use the filenames listed in the catalog. The [schema manifest](/downloads/xml-tools/schema-manifest.json) records each exact namespace, source URL, dependency, and SHA-256 checksum. Compare downloaded files with these checksums to confirm you have the documented revision. For a LegalLab example with extra namespaces, also save its listed [additional schemas](/resources/schemas#additional-legallab-example-schemas). A custom payload requires its own XSD; follow [custom schema authoring](/resources/custom-schemas). ## 2. Associate namespaces with local files In your validator's schema-set or XML-catalog settings, associate each namespace with the corresponding local XSD from the catalog. Load all dependencies before validating the contract. For example, associate `urn:nf:iot:leg:sc:1.0` with `SmartContracts.xsd`. That schema imports identity, key, and XML-attribute definitions; the key schema also imports peer-address types. Some imports omit a file location, so opening only `SmartContracts.xsd` is insufficient. Use the exact namespace strings. A namespace identifies the vocabulary; the downloaded file is its local schema location. Keep these associations in your validator configuration without changing the contract's namespaces. Disable DTD processing and external network resolution for an offline check. Configure the validator to report elements with missing schemas, including machine-readable content inside the contract. ## 3. Validate the complete XML Save the complete document as `MyContract.xml`, select the loaded schema set, and run XSD validation. Check the document root, required attributes, element ordering, and value types. Expected result: the schema set compiles and the document has no validation errors. A message that XML is merely well-formed does not establish XSD validity. As a check that your schema configuration is active, temporarily remove a required attribute such as `startState` from a state-machine definition. Validation should fail. Restore the original document before continuing. ## 4. Check machine references For a contract containing a state machine, check references separately from the XSD result: * `startState` and transition `newState` values must name defined states in the same machine. * Each `actionRef` must name a defined action in that machine. * Event references must match their declared event identifiers. Use the [state-machine reference](/resources/state-machines-reference) to inspect the relevant elements. A validator may need additional checks for these relationships beyond XSD validation. ## Diagnose validation failures | Symptom | What to check | | ---------------------------------- | ------------------------------------------------------------------------------------------------- | | Checksum mismatch | Obtain the documented revision or investigate a publisher change before updating your schema set. | | No schema supplied for an element | Associate its exact namespace with the correct XSD and load its imports. | | Invalid child or missing attribute | Compare element order, required fields, and types with the relevant XSD. | | Unresolved `actionRef` or state | Define the referenced identifier inside the same machine and check spelling. | | Unexpected contract namespace | Match the contract and all its dependencies to the selected schema generation. | ## Continue with the Agent API XML validation checks structure. It does not evaluate Script, verify signatures, approve templates, or execute a token's lifecycle. Submit the validated file through the [contract authoring workflow](/contracts/from-scratch#3-propose-the-template), then observe approval and execution separately. For a custom vocabulary, confirm the provider can resolve its schema before submission. Your local namespace-to-file associations do not configure the provider's schema resolver. ## Original references * [Neuro Foundation documentation](https://neuro-foundation.io/Index.md): specifications and technical reference material. * [Script syntax and function reference](https://lab.tagroot.io/Script.md): the full language reference. # Tested Script function reference Source: https://docs.neuro-tech.io/script/function-reference Use exact core Script signatures for numbers, strings, collections, and conversions with executable examples These examples have been checked using `Waher.Script` 2.15.0. They require no host variables or external service. Your Neuron still determines whether each function is allowed in a particular execution context. For the full syntax and function catalog, use the [original Script reference](https://lab.tagroot.io/Script.md). The entries describe tested input types. They are a focused application reference, not a claim that every runtime overload or extension is available. See [execution contexts and persistence](/script/runtime-functions) before embedding them in a contract. ## Abs(x) Real number; returns non-negative magnitude. ```text theme={null} Abs(-3) ``` Expected result: `3`. [Selected function source](https://github.com/PeterWaher/IoTGateway/blob/43705bab39e89da8f2e5e4d72c55cba6f2a43bbd/Script/Waher.Script/Functions/Scalar/Abs.cs). ## Round(x) Real number; returns the nearest integer-valued number, with midpoint ties to even. ```text theme={null} Round(2.5) ``` Expected result: `2`. [Selected function source](https://github.com/PeterWaher/IoTGateway/blob/43705bab39e89da8f2e5e4d72c55cba6f2a43bbd/Script/Waher.Script/Functions/Scalar/Round.cs). ## Floor(x) Real number; returns the greatest integer-valued number no larger than the input. ```text theme={null} Floor(-2.3) ``` Expected result: `-3`. [Selected function source](https://github.com/PeterWaher/IoTGateway/blob/43705bab39e89da8f2e5e4d72c55cba6f2a43bbd/Script/Waher.Script/Functions/Scalar/Floor.cs). ## Ceiling(x) Real number; returns the least integer-valued number no smaller than the input. ```text theme={null} Ceiling(-2.3) ``` Expected result: `-2`. [Selected function source](https://github.com/PeterWaher/IoTGateway/blob/43705bab39e89da8f2e5e4d72c55cba6f2a43bbd/Script/Waher.Script/Functions/Scalar/Ceiling.cs). ## Min(x, y) Two real numbers; returns the smaller value. ```text theme={null} Min(3,8) ``` Expected result: `3`. [Selected function source](https://github.com/PeterWaher/IoTGateway/blob/43705bab39e89da8f2e5e4d72c55cba6f2a43bbd/Script/Waher.Script/Functions/Scalar/Min.cs). ## Max(x, y) Two real numbers; returns the larger value. ```text theme={null} Max(3,8) ``` Expected result: `8`. [Selected function source](https://github.com/PeterWaher/IoTGateway/blob/43705bab39e89da8f2e5e4d72c55cba6f2a43bbd/Script/Waher.Script/Functions/Scalar/Max.cs). ## Number(x) Numeric text in the tested example; returns a number. Invalid numeric text raises an error. Alias: Num. ```text theme={null} Number("12.5") ``` Expected result: `12.5`. [Selected function source](https://github.com/PeterWaher/IoTGateway/blob/43705bab39e89da8f2e5e4d72c55cba6f2a43bbd/Script/Waher.Script/Functions/Scalar/Number.cs). ## String(x) Numeric value in the tested example; returns its text representation. Alias: Str. ```text theme={null} String(12.5) ``` Expected result: `"12.5"`. [Selected function source](https://github.com/PeterWaher/IoTGateway/blob/43705bab39e89da8f2e5e4d72c55cba6f2a43bbd/Script/Waher.Script/Functions/Scalar/String.cs). ## Length(s) String; returns the string length. The tested example is ASCII text. ```text theme={null} Length("Neuro") ``` Expected result: `5`. [Selected function source](https://github.com/PeterWaher/IoTGateway/blob/43705bab39e89da8f2e5e4d72c55cba6f2a43bbd/Script/Waher.Script/Functions/Strings/Length.cs). ## Trim(s) String; returns text with leading and trailing whitespace removed. ```text theme={null} Trim(" note ") ``` Expected result: `"note"`. [Selected function source](https://github.com/PeterWaher/IoTGateway/blob/43705bab39e89da8f2e5e4d72c55cba6f2a43bbd/Script/Waher.Script/Functions/Strings/Trim.cs). ## StartsWith(s, prefix) Two strings; returns whether the string begins with the prefix. ```text theme={null} StartsWith("Neuro", "Neu") ``` Expected result: `true`. [Selected function source](https://github.com/PeterWaher/IoTGateway/blob/43705bab39e89da8f2e5e4d72c55cba6f2a43bbd/Script/Waher.Script/Functions/Strings/StartsWith.cs). ## Sum(v) Vector of real numbers; returns their sum. ```text theme={null} Sum([1,2,3]) ``` Expected result: `6`. [Selected function source](https://github.com/PeterWaher/IoTGateway/blob/43705bab39e89da8f2e5e4d72c55cba6f2a43bbd/Script/Waher.Script/Functions/Vectors/Sum.cs). ## Count(v) Vector; returns the number of entries. ```text theme={null} Count([1,2,3]) ``` Expected result: `3`. [Selected function source](https://github.com/PeterWaher/IoTGateway/blob/43705bab39e89da8f2e5e4d72c55cba6f2a43bbd/Script/Waher.Script/Functions/Vectors/Count.cs). ## Handle invalid input `Number("not a number")` raises an evaluation error in the same test suite. Validate input types and choose a deliberate error or fallback policy. `Round` uses ties-to-even; a payment integration must define its own units and rounding requirements. The [reference metadata](/downloads/script-function-reference.json) records source revision and test-case identifiers. Each entry includes the expression and expected result; start with the [Script quickstart](/script/quickstart) for a worked calculation. # Script language reference Source: https://docs.neuro-tech.io/script/language-basics Look up values, names, operators, functions, control flow, collections, and XML embedding For the full syntax and function catalog, use the [original Script reference](https://lab.tagroot.io/Script.md). Function availability depends on the [execution context](/script/runtime-functions). Neuron Script evaluates expressions to values. A sequence returns its resulting value and may also change variables in its execution context. The examples below use the `Waher.Script` 2.15.0 language; the [quickstart](/script/quickstart) introduces expressions with their inputs and expected results. ## Find the syntax you need | Task | Syntax | Read more | | -------------------------------------- | ------------------------------ | ------------------------------------------------------- | | Assign or compare a value | `Count:=2`, `Count=2` | [Assignment and comparison](#assignment-and-comparison) | | Choose between two values | `condition ? yes : no` | [Conditions](#conditions) | | Supply a default for an optional value | `Label ?? "Untitled"` | [Null fallback](#null-fallback) | | Reuse a calculation | `Square(x):=x^2`, `x->x^2` | [Functions](#functions) | | Repeat an action | `for`, `foreach`, `while` | [Loops](#loops) | | Transform or filter a collection | `[q*12:q in Quantities]` | [Ranges and comprehensions](#ranges-and-comprehensions) | | Unpack a vector | `[Quantity,UnitPrice]:=[3,12]` | [Unpack values](#unpack-values) | | Use an expression in a contract | `value="{Count+1}"` | [Embed Script in XML](#embed-script-in-xml) | ## Values and names ```text theme={null} 42 3.5 true false "text" 'also text' null ``` Variable names are case-sensitive: `Count` and `count` can hold different values. Keep one spelling in your contract parameters, machine variables, and expressions. An unknown input is an error; define it before evaluation. The language also supports complex numbers, big integers, rational numbers, physical quantities, and host-provided objects. Check the receiving parameter or XML value type before using them. ## Assignment and comparison ```text theme={null} Count:=2; count:=3; Count+count ``` This returns `5`. `:=` assigns; `=` compares. Use semicolons between statements. A newline is formatting, not a substitute for an unambiguous statement separator. ## Operators | Purpose | Syntax | | ------------------ | ------------------------------------------- | | Arithmetic | `+`, `-`, `*`, `/`, `^` | | Remainder | `mod`, such as `7 mod 3`, which returns `1` | | Comparison | `=`, `!=`, `<`, `<=`, `>`, `>=` | | Boolean conditions | `AND`, `OR`, `NOT` | | Grouping | Parentheses, such as `(2+3)*4` | Multiplication binds more tightly than addition: `2+3*4` returns `14`. Use parentheses for mixed expressions when they make the intended order clearer. XML attributes must escape `<` as `<` and `&` as `&`. ## Conditions ```text theme={null} Count:=2; if Count>=2 then "Complete" else "Waiting" ``` This returns `"Complete"`. The condition chooses an expression result; it does not change the machine's state by itself. State transitions are defined by the machine XML. For a short expression, use `condition ? valueIfTrue : valueIfFalse`: ```text theme={null} Count:=2; Count>=2 ? "Complete" : "Waiting" ``` This also returns `"Complete"`. With `Count:=0`, it returns `"Waiting"`. Only the selected branch is evaluated. Prefer the longer `if` form when either branch needs a substantial calculation. ## Null fallback Use `??` to provide a default when an optional input contains `null`: ```text theme={null} Label:=null; Label ?? "Untitled" ``` This returns `"Untitled"`. A supplied `0` or `false` is retained: `Value:=0; Value ?? 10` returns `0`. Choose defaults that match your contract's meaning; required values should be validated rather than silently replaced. In this runtime, `??` also uses the fallback when evaluating its left side raises an error: `Number("bad") ?? 10` returns `10`. A missing variable can also trigger the fallback. Keep required-input validation explicit so a fallback does not conceal a misspelled name or invalid value. ## Functions ```text theme={null} Square(x):=x^2; Square(9) ``` This returns `81`. Built-in functions and package extensions have their own signatures and context requirements. See [functions and execution context](/script/runtime-functions). Built-in function names are case-insensitive: `abs(-3)` and `ABS(-3)` each return `3`. This differs from variable names. Use the documented function casing consistently. ### Lambda expressions A lambda defines a function with `->`. Put multiple arguments in parentheses: ```text theme={null} LineTotal:=(quantity,price)->quantity*price; LineTotal(3,12) ``` This returns `36`. Use a named function for a calculation you want readers to recognize; a lambda is useful when a function itself needs to be stored or passed as a value. See the original [lambda reference](https://lab.tagroot.io/Script.md#lambdaDefinition) for argument forms. ## Variable scope in a function A user-defined function evaluates with its own variable bindings. In the selected runtime, scalar assignments inside the function do not replace the caller's bindings: ```text theme={null} Count:=5; SetCount(x):=(Count:=x); SetCount(2); Count ``` This returns `5`. The function's argument and the assigned `Count` exist in the function call's scope. A new variable created only inside that call is not available to the caller afterward. Return a result and assign it in the caller when you want to update a value: ```text theme={null} Count:=5; Next(x):=x+1; Count:=Next(Count); Count ``` This returns `6`. Function variable scope is separate from [machine persistence](/script/runtime-functions#persist-a-value). It is not a transaction rollback mechanism for mutable host objects or external actions. The supplied scope tests cover scalar bindings. ## Loops ```text theme={null} Total:=0; for i:=1 to 4 do Total:=Total+i; Total ``` This returns `10`. Keep work bounded when expressions execute as part of a contract or event. Language support for a loop does not guarantee a host permits every use of it. Use `foreach` when you already have the values to process: ```text theme={null} Total:=0; foreach Quantity in [1,2,3] do Total:=Total+Quantity; Total ``` This returns `6`. Use `while` when the condition determines how many iterations are needed: ```text theme={null} x:=0; while x<3 do x:=x+1; x ``` This returns `3`. Update the condition's inputs so the loop can finish. ## Collections A vector groups ordered values. Indexes start at zero: ```text theme={null} v:=[10,20,30]; v[1] ``` This returns `20`. `Count(v)` returns the number of entries; `Sum(v)` adds numeric entries. Construct a matrix from row vectors. Matrix indexing uses column first, then row: ```text theme={null} m:=[[1,2],[3,4]]; m[1,0] ``` This returns `2`, the second column of the first row. Both indexes start at zero. An object groups named fields: ```text theme={null} o:={Count:2, Label:"Ready"}; o.Count ``` This returns `2`. Operators can apply across collection elements: `Sum([1,2,3]+10)` returns `36`. Confirm the returned shape when supplying a scalar contract parameter. ## Ranges and comprehensions A range supplies values to iterate over. `1..4` includes `1`, `2`, `3`, and `4`. Add a step with `|`: `1..7|2` includes `1`, `3`, `5`, and `7`. For example, `Sum(1..4)` returns `10`. A comprehension creates a vector by evaluating an expression for each input: ```text theme={null} Quantities:=[1,2,3]; Totals:=[q*12:q in Quantities]; Totals ``` This returns `[12,24,36]`. `Sum(Totals)` returns `72`. The expression before `:` produces each result; `q in Quantities` supplies its input. To select existing values, put the source before `:` and the condition after it: ```text theme={null} Quantities:=[0,2,-1,3]; Positive:=[q in Quantities:q>0]; Positive ``` This returns `[2,3]`. If no values match, the result is an empty vector. Filtering is useful for selecting values to process; it does not validate or reject the original input. Use bounded inputs in contract expressions. See the original reference for [comprehensions](https://lab.tagroot.io/Script.md#implicitVectorNotation) and [element selection](https://lab.tagroot.io/Script.md#selectingElements). ## Unpack values Assignment can match a vector pattern and bind its elements to names: ```text theme={null} [Quantity,UnitPrice]:=[3,12]; Quantity*UnitPrice ``` This returns `36`. The expected shape matters: assigning `[3]` to this two-element pattern fails. Check externally supplied data before unpacking it. See [assignment pattern matching](https://lab.tagroot.io/Script.md#assignmentPatternMatching) for more patterns. ## Convert values explicitly `Number("12.5")` returns numeric `12.5`; `String(12.5)` returns the text `"12.5"`. The aliases `Num` and `Str` are also tested in the selected core runtime. `Number("not a number")` raises an evaluation error. Validate user input before conversion and avoid evaluating input as executable Script. See the [tested function reference](/script/function-reference) for precise examples and supported argument cases. ## Errors Handle invalid input before using it. `2+` is a syntax error; `UnknownInput+1` fails if the variable is absent. A false validation result is different from a failure to evaluate the expression. The language supports `try`/`catch`/`finally`. For example: ```text theme={null} try Number("bad") catch 0 ``` This returns `0` in the selected core runtime. Only choose a fallback when it has the intended meaning; treating invalid payment input as zero can hide an error. A state machine also has XML-level failure controls. Verify the state reached after failure rather than suppressing an error that should reject an action. ## Comments Use `//` for a line comment and `/* ... */` for a block comment. Explain why a rule exists rather than restating the expression. Comments are language text and must still be escaped if placed in an XML attribute. ## Embed Script in XML For a scriptable action attribute, wrap the calculated expression in braces, as in `value="{Count+1}"`. A literal such as `content="Done"` is not a script. `Calc` and `Script` elements contain expression text directly. Use CDATA when it makes comparison operators easier to read: ```xml theme={null} ``` This fragment assigns an action variable; it does not persist it. Follow it with the appropriate `PersistVariable` action in a complete, validated machine. ## Keep evaluation context explicit Contract expressions see the values supplied by the contract context. Machine expressions may additionally see initialized variables and event data. .NET interoperation and package functions are subject to host restrictions. Use only documented inputs and functions, and test the complete contract on the target Neuron. # Neuron Script for contracts and tokens Source: https://docs.neuro-tech.io/script/overview Use expressions to validate contract parameters and define state-machine behavior For the full syntax and function catalog, use the [original Script reference](https://lab.tagroot.io/Script.md). Function availability depends on the [execution context](/script/runtime-functions). **Neuron Script** is the expression language implemented by `Waher.Script`. Contracts use it for validation and calculated values; token state machines use it for calculations and actions. JavaScript in an Agent API client is a different language. ## Choose the context you need | Context | Input | Result | | ----------------------------- | ------------------------------------------------ | ------------------------------------------------------------------ | | Contract parameter expression | Values exposed by the contract parameter context | A validation result or calculated parameter value. | | State-machine `Calc` | Variables available during evaluation | A value used by the enclosing XML element. | | State-machine `Script` action | Machine/action variables and event data | Executes a statement sequence; persist lasting changes explicitly. | | Scriptable action attribute | A literal or a braced expression | Supplies an action argument such as a calculated value. | | Note-generation expression | Command parameters supplied by the client | Generates a token note for a supported command. | Available variables and functions depend on the context and runtime. A function in the core language is not automatically permitted by a Neuron's expression restrictions. Calculate a value, validate it, and check the expression locally. Look up names, values, assignment, conditions, and control flow. Check exact function behavior and the scope of a script. Connect expressions to events, actions, and persisted values. Your application continues to use the [Agent API](/neuron-api/introduction). You do not need an administrative Script prompt to author contract expressions. # Write and check your first contract expression Source: https://docs.neuro-tech.io/script/quickstart Calculate a value and validate inputs with the same Script language used by contracts For the full syntax and function catalog, use the [original Script reference](https://lab.tagroot.io/Script.md). Function availability depends on the [execution context](/script/runtime-functions). This example calculates a line total and rejects a non-positive quantity. The examples below show the expression, inputs, and expected result before you embed it in a contract. ## 1. Calculate a value Assign values with `:=` and separate statements with semicolons: ```text theme={null} Quantity:=3; UnitPrice:=12; Quantity*UnitPrice ``` The result is `36`. In a contract, the parameter definitions supply the input values; do not overwrite those inputs with the quickstart's sample assignments. ## 2. Validate the inputs ```text theme={null} Quantity>0 AND UnitPrice>=0 ``` With the values above, this returns `true`. With `Quantity:=0`, it returns `false`. Use a validation expression where a contract parameter needs this constraint; see [contract parameters](/contracts/parameters). ## 3. Check the expected results These core expressions have been checked with `Waher.Script` 2.15.0: | Expression | Expected result | | --------------------------------------------------------- | --------------- | | `Quantity:=3; UnitPrice:=12; Quantity*UnitPrice` | `36` | | `Quantity:=3; UnitPrice:=12; Quantity>0 AND UnitPrice>=0` | `true` | | `Quantity:=0; UnitPrice:=12; Quantity>0 AND UnitPrice>=0` | `false` | Use these inputs when checking your own expression in its supported contract or state-machine context. A correct core calculation does not establish host permissions, available variables, signatures, or persistent state. ## 4. Embed a calculated machine value In a state-machine action, an expression-valued attribute uses braces: ```xml theme={null} ``` This is a fragment for an action with an existing numeric `Count` variable. Without braces, a scriptable attribute can be interpreted as a literal rather than a calculation. Validate the complete XML using [the validation guide](/resources/validate-xml), then test the machine on your development Neuron. Continue with [language basics](/script/language-basics) and [state machines](/contracts/state-machines). # Script functions and execution context Source: https://docs.neuro-tech.io/script/runtime-functions Check numeric function signatures, host restrictions, and state-machine variable persistence For the full syntax and function catalog, use the [original Script reference](https://lab.tagroot.io/Script.md). Function availability depends on the [execution context](/script/runtime-functions). The loaded runtime determines which Script functions exist. The Neuron also checks whether an expression is allowed in its contract or state-machine context. Local evaluation is not proof of permission to execute on a server. ## Find a function by task | Task | Local examples | Original reference | | --------------------------------------- | --------------------------------------------------------- | -------------------------------------------------------------------------------- | | Convert or round numbers | [Tested numeric functions](/script/function-reference) | [Scalar functions](https://lab.tagroot.io/Script.md#scalarFunctions) | | Clean or inspect text | [String helpers](/script/function-reference) | [String functions](https://lab.tagroot.io/Script.md#stringFunctions) | | Aggregate a collection | [Collection helpers](/script/function-reference) | [Vector functions](https://lab.tagroot.io/Script.md#vectorFunctions) | | Work with matrices | [Collections](/script/language-basics#collections) | [Matrix functions](https://lab.tagroot.io/Script.md#matrixFunctions) | | Work with dates and durations | [Contract expression context](#expressions-in-a-contract) | [Date and time functions](https://lab.tagroot.io/Script.md#dateAndTimeFunctions) | | Use powers, logarithms, or trigonometry | [Arithmetic operators](/script/language-basics#operators) | [Analytic functions](https://lab.tagroot.io/Script.md#analyticFunctions) | Use the original reference for additional signatures. Check that the chosen function is available in the contract or machine context where you will run it. ## Numeric functions used in these examples The following scalar cases were evaluated with `Waher.Script` 2.15.0. They require no context variables and have no external side effects. | Function | Argument | Return value | Example | | ---------- | ----------- | -------------------------------------------------------------------- | --------------------------------------------------- | | `Abs(x)` | Real number | Non-negative magnitude | `Abs(-3)` returns `3`. | | `Round(x)` | Real number | Nearest integer represented as a number; midpoint ties round to even | `Round(2.5)` returns `2`; `Round(3.5)` returns `4`. | These functions also implement complex scalar cases in the selected source. The table's tested examples cover real numbers. Confirm the supported type for the receiving contract parameter. Unsupported input types can fail evaluation. `Round` is not a complete monetary-rounding policy. A payment workflow must define its units, precision, and rounding rules explicitly. Use the [tested function reference](/script/function-reference) for numeric conversion, strings, collections, bounds, and rounding. It links each signature to an executable example and its expected value. ## Expressions in a contract A parameter's validation expression uses the values exposed by the contract context. Calculated parameters derive values from those inputs. See [contract parameters](/contracts/parameters) and the [CalculatedParameters example](/resources/contract-examples). The selected contract parser populates named parameters and `Duration` before validation. When a first signature exists, it also supplies `Now` and `NowUtc` from that signature's timestamp. These are not an instruction to read the current wall clock. Avoid assuming they exist in an unsigned template. Keep validation deterministic. A function that reads external mutable data can make the result depend on when or where evaluation occurs. ## Expressions in a state machine | XML location | Expression form | Context and result | | ---------------------- | ----------------------------------- | ------------------------------------------------------------------ | | `Calc` element | Expression text | Evaluates a value for its parent. | | `Script` action | Statement sequence | Changes variables during that action. | | Scriptable attribute | Expression enclosed in braces | Supplies a calculated argument to an action. | | `beforeActionScript` | Expression text in an XML attribute | Runs in the matching event's context before the referenced action. | | Note-generation script | Expression text | Generates the note content for the command. | Event data exists only when the selected event defines it. For example, a note event can assign the note to a variable named by its `noteVariable` setting. Initialize every variable your expression reads, and avoid colliding with event variable names. The selected machine implementation creates evaluation variables from saved values and supplies a `CurrentState` host object. Treat that object as host context, not as a portable API response schema. The complete example uses its own `Count` variable and does not depend on host-object members or note-data variables. ## Persist a value Ordinary assignment changes the evaluation variables. To retain a value across machine actions, use `PersistVariable`: ```xml theme={null} ``` This fragment requires an initialized numeric `Count`. Verify the new value and recorded history after triggering the complete machine. ## Optional functions and restrictions Functions such as XML selection, content conversion, networking, and provider-specific operations can require extra assemblies or services. Do not infer their signatures or availability from an administrative prompt or a different example. Record the exact package and permitted execution context before using them. The [LegalLab catalog](/resources/contract-examples) lists examples that may use such functions. Those examples need their own compatibility checks. The [Script quickstart](/script/quickstart) explains core expressions and their expected results; the [Agent API workflow](/contracts/agent-api-quickstart) handles contract submission and inspection.