HYBRID DEVNET · PUBLIC EVIDENCE LIVEVerifiable infrastructure for value, markets, identity, and operational dataInspect the network

Access & support

What if an FAQ answer does not cover my exact operation?

3 min read

The FAQ explains concepts and next steps; it is not an operation contract or a live readiness check. The current API reference defines request details, while the relevant account and evidence views provide operation-specific context.

Use the FAQ to understand the idea

This FAQ is written to explain concepts, common situations, and useful next steps. It can help a business user understand why an observed deposit is not yet available or why an agent’s allowed proposal is not a payment. It is not a live account-status service and cannot grant access. Examples describe how to reason about a workflow, not a complete specification of every request or a guarantee about a particular deployment.

Use the operation contract to implement

When building software, follow the current reference for the exact operation and environment. It defines required inputs, permissions, responses, and errors in a level of detail that a general answer cannot provide. The implementation guide connects those details into a practical path. If a guide and the deployed contract appear inconsistent, ask for clarification rather than guessing which behavior to rely on, especially before a write or financial action.

Use the responsible record to establish an outcome

For an actual operation, inspect the authorized account or service state and the relevant evidence. A general explanation of a status is not proof that your particular request reached it. Keep the product, network, version, and operation reference attached to any question you send to the team. These three sources work together: the FAQ explains the meaning, the contract defines the interface, and the operation record establishes what was observed for the specific case.

In plain language

What an API contract tells your team

An API is a way for one application to ask another system for information or an action. The operation contract is the detailed description of that particular request: what information to send, what access is required, what a response means, and which errors can occur. It is more precise than a product overview. A read normally retrieves information; a write can create or change something and therefore needs more careful handling. Developers should use the current contract for the deployed environment rather than guessing from a similar endpoint or an old example. Business users can help by stating the outcome in ordinary language and naming who may authorize it. Both sides should agree how to identify the request later, what happens if a response is delayed, and which record establishes completion. These details turn a demonstration into an integration that people can operate responsibly.

In plain language

A public record is evidence with a specific scope

An Explorer record is closer to a receipt or an entry in a logbook than to a live control panel. It describes something published about a particular event, object, or process. Some entries include links that let you examine the earlier steps or the underlying transaction. A record can remain useful after it becomes old: it may establish what was recorded at that time. It does not necessarily describe what the system can do now. Look at the record type, network, time, source, and stated verification result together. Missing information means the public view cannot establish that fact; it is not a reason to invent a positive or negative result. Private account records may contain additional context that is deliberately absent from Explorer. This is why a screenshot is a starting point for investigation, while the exact record and its supporting references are much more useful for reaching a conclusion.

What to do next

Follow the linked guide or API reference, and contact the team if your intended workflow remains unclear.

V2 API reference ↗Implementation guides ↗Contact the team ↗