FlashСall API

Interaction format

API requests are made over the HTTP protocol. Input and output data structures are transmitted in the request and response body in JSON format.

Authorization

Most HTTP API calls require authentication and authorization procedures that link API calls to the required applications in your account.

To do this, each request must contain a header or an X-Authorization argument with a connection token in the AccessKey token format,

For example, the title
POST /apps/activate HTTP/1.1
Host: https://cpaas.mittoapi.net/api
X-Authorization: AccessKey d8ac9959r12b43545da9034,

either by parameter
POST https://cpaas.mittoapi.net/api/apps/activate?X-Authorization=AccessKey d8ac9959r12b43545da9034

Response format

The JSON scheme of any response contains a string type status parameter with the following values:

Status Value	Description
ok	No errors
invalidAccessKeyError	Invalid AccessKey
requiredJsonError	The request body requires JSON
invalidSchemeError	Invalid JSON scheme
invalidDataError	Input data error
prohibitedForAppError	Prohibited for this application
prohibitedForServiceError	Prohibited for this service
rpcError	Communication error

For example:

    {
        …
        “status”: “ok”
        ....
    }

FlashCall requests

POST https://cpaas.mittoapi.net/api/apps/flash/calls/flash
HTTP Basic
Authorization: token

Parameters in the body, json

    {
        "number": "791791367878",
        "code": 1234,
        "timeout": 60000, 
    } 

Parameter	Description
number	Phone number in e.164 format
code	Code, 4e characters
timeout	Maximum call time in ms

Answer:

In case of successful sending, RequestId is returned — the ID of the message on the partner’s side, which is then returned to the callback.

Example of a successful response:

    {
        "requestId": XXXXXX
        "from": "79179136787"
    }

Example of an unsuccessful response:

    {
        "errorCode" : 1,
        "errorReason" : "Authentication required"
    }

Description of error codes

errorCode	errorReason	Description
1 НТТP 401	Authentication required	Invalid authentication token
2 HTTP 400	Inactive account	Inactive account. Contact support
4 HTTP 429	Too many requests	Too many requests in a short period of time
5 HTTP 401	Inactive token	Inactive token
6 HTTP 403	Insufficient funds	Low balance, unable to complete the request
10 HTTP 400	Invalid request	Incorrectly formed request
11 HTTP 400	Invalid number	Invalid number format. The number must be in the format (E.164).
16 HTTP 400	Sender not allowed	Sender id is invalid for this type of request

Getting statuses

Getting statuses should be configured via Callback

Parameters in the callback

Parameter	Description
requestId	The unique identifier of the request on the partner’s side
number	Subscriber’s number
status	Status (shown in the table below)
timestamp	The time of the status change in unixtime format
appKey	The API key of the application

Statuses comparison

Statuses that a Partner can return	Description of the Partner status	The corresponding status is Message_state
ANSWERED	The call came, the caller picked up the phone	DELIVERED
TERMINATED	The call came, the subscriber did not pick up the phone (the call was interrupted after the ttl or by command)
BUSY_HERE	The call came, the caller dropped the call
REJECTED	The call cannot be made, for example, if the number is still occupied by another call or another SIP error	UNDELIVERED
UNAVAILABLE	The subscriber is unavailable, the phone is turned off
FORBIDDEN	It is returned when the anti-fraud is triggered