Messaging API Documentation
Quicktext's Messaging API provide a seamless way to send/receive messages to/from Quicktext
Application
An Application is an entity in Quicktext who represents the user of this API.
In order to use this API you need to create an application in Quicktext which identifies you and gives you the required security Tokens.
Messaging API Application Documentation
Roles
This API can be used as one of the following two roles:
Member
A Member is an API user who subscribes to Teams so it can see conversations and messages of the subscribed Teams, create conversations and respond to clients.
This Role typically represents a Team user who needs to send/receive messages usig this API instead of using the quicktext's UI ( accessible via app.quicktext.im ).
Member Messaging API Documentation
Client
A Client is an API user who can start conversations with any Team and talk to Team members and Chat bots.
This Role typically represents a Team's customer who wants to ask questions about a specific Team ( Hotel, Bank or any organisation registered in Quicktext ).
Client Messaging API Documentation
Communication paradigms
In this section we try to illustrate the used communication techiques, where and why
REST
We use this technique to send informations to Quicktext, Ex:
- Send message
- Create new application
- List conversations
- Etc...
This technique s the most standard used in Web Development but it does not permit the other direction which is sending informations from Quicktext to the partner. We will discover the next two paradigms which allows Quicktext to send events.
HTTP Webhook
Quicktext's partner creates a web server having a HTTP endpoint that accept calls from Quicktext, so for any events happens in Quicktext, we will call the created endpoint using the corresponding URL, Method and a predefined body in this documentation
This paradigm is useful for partners who needs to use our API using their Web Server.
The problem with this paradigm that it's not possible using browsers and mobile applications because they cannot publish a static IP.
WebSocket
This paradigm allows Browsers and mobile applications to listen to Quicktext's events ( like messages, status updates, etc... )
Push Notifications
This techique is designed for mobile devices, it's useful when the application is closed so websocket is not available.
Actually we use Firebase to send events notifications to clients.