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

Products & integrations

Where should a developer start?

3 min read

Choose a domain, confirm your credential type and scopes, then read the current V2 contract. Check inputs, errors, ownership, and operation availability before implementing writes. Keep credentials in your trusted environment, not in public client code.

Start with an outcome you can explain

Choose one product and one operation before writing a broad integration. For example, your first goal might be to read a permitted wallet status and display its network clearly. Use the developer portal to locate the product’s guide and API module. Read the access requirements before obtaining or using credentials. A successful first request should demonstrate that you understand the returned information, not merely that a connection can return a response.

Read the success and failure paths

Check the required inputs, resource ownership, scopes, and response fields. A scope limits which requests a credential may make. Look at errors and delayed outcomes as carefully as the successful example. Ask whether success means the work is complete or only accepted for processing. Do not invent parameters, retry headers, or permissions because another product uses them. The contract for the exact operation is the basis for the integration.

Make the first step safe and useful

Use an agreed environment and keep service credentials out of public browser code and logs. Begin with a permitted read or another bounded operation where appropriate. Save non-secret request references so you can investigate the result later. Test an unauthorized case to confirm that the application explains it correctly. Before adding writes, decide who authorizes them and how an uncertain outcome will be reconciled. This small amount of planning prevents the first prototype from teaching users the wrong meaning of success.

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

What “enabled for your operation” means

A product can support several kinds of activity without making all of them available to every user. For example, reading an existing wallet record is different from creating a wallet, signing a transfer, or withdrawing to another chain. Access can depend on the account, environment, network, product configuration, and required approval. An operation is the exact action you want to take, such as reading a status or requesting a withdrawal. A scope is a limit on what a credential is allowed to request. Seeing a feature in documentation tells you what to investigate; it is not itself an access grant. During an evaluation, ask for a simple list of which actions are enabled, which are read-only, and which are outside the agreed test. Keep that list with your test results. This gives business users and developers the same understanding of what a successful demonstration actually establishes.

What to do next

Use the developer portal’s first-request example and the linked operation reference.

Developer portal ↗V2 API reference ↗