Skip to content

The API supports three authentication methods. For production integrations, use an API key — optionally with HMAC request signing.

Method Best for Header(s)
API key Production integrations X-API-Key
API key + HMAC High-security environments X-API-Key, X-Timestamp, X-Signature
JWT token Testing, portal-only endpoints HttpOnly auth_token cookie or Authorization: Bearer with that cookie value

Create keys in the portal under Settings → API Keys (see API keys & permissions). Pass the key in the X-API-Key header with every request:

X-API-Key: <YOUR_API_KEY>
Terminal window
curl "https://restlink23telecom.com/api/v1/sms/stats?period=7d" \
-H "X-API-Key: $API_KEY"

For enhanced security, enable signature verification when creating the key. Every request must then carry three headers:

Header Description
X-API-Key Your API key
X-Timestamp Current Unix timestamp in seconds
X-Signature HMAC-SHA256 signature (hex)

Signature computation:

message = "{METHOD}|{path_and_query}|{timestamp}|{body}"
signature = HMAC-SHA256(api_secret, message)

Five rules to get it right:

  • path_and_query is the escaped URL path plus the query string when present. Query parameters are sorted by key before signing, for example /api/v1/sms/stats?period=7d.

  • body is the raw request body string; use an empty string "" for GET.

  • X-Timestamp may be at most 300 seconds in the past and 30 seconds in the future (server time); otherwise 401 INVALID_SIGNATURE. Each timestamp + signature pair is accepted once; a repeat returns 401 INVALID_SIGNATURE.

  • If the replay store is unavailable, POST, PUT, PATCH and DELETE return 503 REPLAY_PROTECTION_UNAVAILABLE. GET, HEAD, OPTIONS are still served without replay protection.

  • Send both headers or neither. A key that requires signatures and is missing either header gets 401 SIGNATURE_REQUIRED. A key with optional signing that sends only one of the two headers gets 401 INVALID_SIGNATURE; with neither header the request is served unsigned.

import crypto from 'node:crypto';
const apiKey = process.env.API_KEY;
const apiSecret = process.env.API_SECRET;
const timestamp = Math.floor(Date.now() / 1000).toString();
const method = 'POST';
const path = '/api/v1/sms/send';
const body = JSON.stringify({
to: ['+14155551234'],
message: 'Hello!',
sender_id: 'MyApp',
});
const signature = crypto
.createHmac('sha256', apiSecret)
.update(`${method}|${path}|${timestamp}|${body}`)
.digest('hex');
const res = await fetch('https://restlink23telecom.com' + path, {
method,
headers: {
'Content-Type': 'application/json',
'X-API-Key': apiKey,
'X-Timestamp': timestamp,
'X-Signature': signature,
},
body,
});
console.log(await res.json());

Signature failures return 401 SIGNATURE_REQUIRED (the key requires signing and a header is missing) or 401 INVALID_SIGNATURE (only one header on an optional-signing key, or verification failed) — see errors.

You can log in with portal credentials for testing and session-only endpoints such as workspaces. Use API keys for production integrations.

Log in
curl -c cookies.txt -X POST https://restlink23telecom.com/api/v1/user/auth \
-H "Content-Type: application/json" \
-d '{"login": "your_username", "password": "your_password"}'
200 OK
{"status": true, "user": {"id": 123}}

The response sets an HttpOnly auth_token cookie and a readable csrf_token cookie. The token is not returned in the response body. If two-factor authentication is required, the response is:

{"status": true, "requires_twofa": true, "twofa_method": "totp"}

The method is totp, email, or both. Repeat the login request with twofa_code, or with totp_code and email_code for both methods. You can also supply trust_device and device_name.

Use -b cookies.txt with curl. Every cookie-authenticated method other than GET, HEAD, or OPTIONS requires X-CSRF-Token with the value of the csrf_token cookie; otherwise it returns 403 CSRF_FAILED. Alternatively, use the auth_token cookie value as an Authorization: Bearer token. Do not send an API key and session cookie together: this returns 400 AMBIGUOUS_AUTHENTICATION.

Login failures include 401 INVALID_CREDENTIALS; 403 CROSS_SITE_LOGIN for a request from another site, including the docs playground; 429 TOO_MANY_ATTEMPTS or ACCOUNT_TEMPORARILY_LOCKED with Retry-After (the lock applies from every IP until it expires, and a password reset is an alternative); and 503 AUTH_PROTECTION_UNAVAILABLE or PASSWORD_HASH_BUSY with Retry-After: 1. Retry a 503 after that delay. A wrong two-factor code returns 401 ERROR_CODE with Invalid 2FA code, Invalid TOTP code or Invalid email code.