I went through the docs for HTTP JSON API and i am aware of the limitation mentioned here:

Apart from this is there any advantages and limitation for using HTTP JSON API service?

Also in future, is there any development to include all LEDGER API features in JSON API service?


1 Like

Howdy @dhaileytaha :wave:

That’s an old HTTP JSON API page (v.013.38). You can find the latest one here with an explanation on why not all functionalities of the Ledger API have been included.


The JSON API provides a significantly simpler way to interact with a ledger than the Ledger API by providing basic active contract set functionality :

  • creating contracts,
  • exercising choices on contracts,
  • querying the current active contract set, and
  • retrieving all known parties.

The goal of this API is to get your distributed ledger application up and running quickly, so we have deliberately excluded complicating concerns including, but not limited to:

  • inspecting transactions,
  • asynchronous submit/completion workflows,
  • temporal queries (e.g. active contracts as of a certain time )

Out of curiosity are you using v 0.13.38 of the Daml Connect SDK specifically?

1 Like

There are no such plans at the moment. What features exactly would you like to be there?

1 Like

Thanks for the response, I am not looking for a specific feature for now. Probably once the project starts, there might be some features nice to be in json-api as well.

But there is one feature i ask to ask about is JSON-API synchronous, it waits for command to success or fail?
As per the doc for “asynchronous submit/completion workflows” we need ledger API.

For now, i was trying to understand the limitation and if there is any progress upcoming for json-apis


In the Ledger API you have two ways of submitting a command, you either:

  • use the CommandSubmissionService#Submit method and listen for the completion using the CommandCompletionService#CompletionStream method
  • use the CommandService#SubmitAndWait method, which makes the Ledger API server take care of tracking

The former is not used by the JSON API, but in practice there is little difference between the two. The latter is more convenient for the client, the former allows the client to independently track issued commands and completions, offloading this duty from the server and allowing more fine grained approach to dealing with back-pressure. Apart from this, all the asynchronous submit/completion workflow does is keeping the in-flight commands state on the server. The client-observed behavior is synchronous but internally the flow is still asynchronous.

1 Like

The JSON API has mostly synchronous endpoints for “write” commands, but does have websocket-based asynchronous “read” commands.

1 Like

Using this version.
What is curiosity about?

1 Like

Thnx for the info :slight_smile:

You referenced an older version of the JSON API (0.13.38) so was wondering if there’s anything special about it that might fulfil the needs for your project. I see you’re using a newer version of the SDK actually (1.11.0)