Skip to main content
Use this guide for workflow design and integration choices. Use API reference pages for exact request/response contracts.

Before you start

  • Decide whether your claim operation runs at protocol layer or service layer.
  • Confirm endpoint and network values in /reference/networks-and-endpoints.
  • Confirm auth requirements in /reference/authentication-matrix.

Protocol vs service boundary

  • Protocol layer: claim module transactions and state queries through protocol gateways.
  • Service layer: product-specific reporting and workflow APIs (for example, Registry service endpoints).

Claim workflow outline

  1. Create or collect claim data.
  2. Submit to the target surface (protocol or service).
  3. Run evaluation and dispute handling.
  4. Track lifecycle transitions.

Example protocol message literal

const msg = {
  typeUrl: "/ixo.claims.v1beta1.MsgSubmitClaim",
  value: {
    creator,
    claimId,
    claimType,
    data: claimData
  }
};

Verify the result

Expected result:
  • accepted claim write or query response on the target surface;
  • clear traceability of whether execution happened through protocol gateways or a service API.

See also

Troubleshooting

  • Broadcast / transaction failures — Read rawLog or code from the node response. insufficient funds, unauthorized, and sequence mismatch are common: fix fees, signer, or account sequence. Compare your chainId and RPC URL with Networks and endpoints.
  • GraphQL partial failures — Blocksync may return errors alongside partial data. Treat the response as failed for downstream writes if any required field is null; re-check filters and IDs.
  • DID or entity not found — Confirm the entity is indexed on the network you query; registry vs indexer lag can produce temporary “not found” results.

Next steps

Use the API introduction matrix to pick RPC, REST, GraphQL, or Registry for each step of your workflow.