If you are not familiar with cron schedule expressions, you can use this website. e.g: 0 22 * * * calls receive daily at 10pm. The AUTO_RECEIVE_SCHEDULE accepts cron schedule expressions and automatically calls the receive endpoint at the given time. So, if you are not already calling the receive endpoint regularily, it is recommended to set the AUTO_RECEIVE_SCHEDULE parameter in the docker-compose.yml file. Signal-cli, which this REST API wrapper is based on, recommends to call receive on a regular basis. ⚠️ This setting is only needed in normal/native mode! for updates, the storage location for the signal-cli configuration is mapped as Docker Volume into a local /home/user/signal-api directory. This launches a instance of the REST service accessible under To preserve the Signal number registration, i.e. e 'MODE=native ' bbernhard/signal-cli-rest-api v /home/user/signal-api:/home/.local/share/signal-cli \ $ sudo docker run -d -name signal-api -restart=always -p 9922:8080 \ This mode is usually the fastest, but requires more memory as the JVM keeps running.Įxample of running signal-cli-rest in native mode json-rpc Mode: A single, JVM-based signal-cli instance is spawned as daemon process.The native mode may also be less stable, due to the experimental state of GraalVM compiler. On the armv7 platform this mode is not available and falls back to normal. This results in a much lower latency & memory usage on each call. native Mode: A precompiled binary signal-cli-native (using GraalVM) is used for every REST API request.
Being a Java application, each REST call requires a new startup of the JVM (Java Virtual Machine), increasing the latency and hence leading to the slowest mode of operation. normal Mode: (Default) The signal-cli executable is invoked for every REST API request.The signal-cli-rest-api supports three different modes of execution, which can be controlled by setting the MODE environment variable. You should now have send a message to +44987654. $ curl -X POST -H "Content-Type: application/json " ' ' \