This project creates a small dockerized REST API around signal-cli.
At the moment, the following functionality is exposed via REST:
- Register a number
- Verify the number using the code received via SMS
- Send message (+ attachments) to multiple recipients (or a group)
- Receive messages
- Link devices
- Create/List/Remove groups
- List/Serve/Delete attachments
- Update profile
and many more
Sample docker-compose.yml
file:
version: "3"
services:
signal-cli-rest-api:
image: bbernhard/signal-cli-rest-api:latest
environment:
- USE_NATIVE=0
#- AUTO_RECEIVE_SCHEDULE=0 22 * * * #enable this parameter on demand (see description below)
ports:
- "8080:8080" #map docker port 8080 to host port 8080.
volumes:
- "./signal-cli-config:/home/.local/share/signal-cli" #map "signal-cli-config" folder on host system into docker container. the folder contains the password and cryptographic keys when a new number is registered
signal-cli, which this REST API wrapper is based on, recommends to call receive
on a regular basis. 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. The AUTO_RECEIVE_SCHEDULE
accepts cron schedule expressions and automatically calls the receive
endpoint at the given time. e.g: 0 22 * * *
calls receive
daily at 10pm. If you are not familiar with cron schedule expressions, you can use this website.
WARNING Calling receive
will fetch all the messages for the registered Signal number from the Signal Server! So, if you are using the REST API for receiving messages, it's not a good idea to use the AUTO_RECEIVE_SCHEDULE
parameter, as you might lose some messages that way.
On Systems like the Raspberry Pi, some operations like sending messages can take quite a while. That's because signal-cli is a Java application and a significant amount of time is spent in the JVM (Java Virtual Machine) startup. signal-cli recently added the possibility to compile the Java application to a native binary (done via GraalVM).
By adding USE_NATIVE=1
as environmental variable to the docker-compose.yml
file the native mode will be enabled.
In case there's no native binary available (e.g on a 32 bit Raspian OS), it will fall back to the signal-cli Java application. The native mode only works on a 64bit system, when the native mode is enabled on a 32bit system, it falls back to the Java application.
The Swagger API documentation can be found here. If you prefer a simple text file based API documentation have a look here.
Running Signal Messenger REST API in Azure Web App for Containers - written by @stefanstranger
Name | Client | Library | Language | Maintainer |
---|---|---|---|---|
Shell Client | X | Shell | @florian-h05 | |
pysignalclirestapi | X | Python | @bbernhard |
In case you need more functionality, please file a ticket or create a PR.