In DDD, are Commands strictly synchronous API calls?

Commands in the context of domain-driven design:

Commands - in the context of domain-driven design - represent the intent for something to happen in the system that leads to some desired outcome after being executed. So it can be seen as some object that contains all the information required by the receiver of the command to execute the command.

So when talking about commands in domain-driven design there is no technical definition or restriction in what way a command can be triggered and transmitted or how the required information is represented.

Commands should be describable from the business perspective first to find out what or who in the system context will trigger it and when it will be triggered. As well as what the expected state shall be after the command has been executed.

Commands can be triggered/transmitted, for instance, the following ways:

• Performing some synchronous REST request when a user clicks on a button on a web site
• Sending an asynchronous message (e.g. from one Microservice) to the message queue of the command receiver (e.g. another Microservice)
• Performing a gRPC call (e.g. from one Microservice to another)
• Clicking on a button in the UI of a desktop application
• Executing a scheduled background task

Commands in the business context can be, for instance:

• Checkout the current shopping basket in an online shop to initiate the order
• Upvote and answer on stackoverflow and increase the answer's vote

In the context of domain-driven design it is just some implementation detail if the command is executed synchronously or asynchronously. The important part is that the intended outcome will have happened after the executed has been performed successfully.

When performing a sychronous API call the component that triggered the command can get feedback via a synchronous answer if the command went through ok.

Whereas in an asynchronous command transmission (like messaging) you will only know that the message has been delivered to some queue but the successful execution of the command will have to be perceived in some other way. Either by querying for the current state of the involved domain entities or by leveraging some event-based mechanism where events get published after a command has been executed and any interested parties can subscribe to those events.

TL;DR

Getting back to your questions:

When I read about Command in the DDD Context, it is usually described as an API call.

The API call itself is just the technical data representation and transmission of the command.

Are Commands strictly synchronous API calls, or can be asynchronous?

The same command can be triggered in different ways (see previous examples) and again transmitted in different ways. But no matter how triggered or how transported it will have to contain the same required information and will lead to the same desired outcome in the overall system after being executed.

So, yes it can of course be asynchronous as well.