API RevRake.

Базовые URL

API — это четыре подписанных эндпоинта для платформы оператора, два для записи и два для чтения, и трекинговая ссылка, которую открывают посетители. Подписанные эндпоинты также опубликованы в виде файла OpenAPI 3.1.

Порталы на app.revrake.com используют собственные эндпоинты за сессией вошедшего пользователя. Это не публичный API, и они могут измениться без предупреждения. Отчёты, реестр и строки выплат можно также скачать там в CSV.

Ключи

Ключи бывают двух видов. У каждого есть ID ключа и секрет, и каждый подписывает запросы одинаково. Ключи никому не передаются: у каждой стороны свой.

• Новый ключ сразу отзывает старый — для обоих видов. Партнёр может также отозвать свой ключ и остаться без ключа.
• Ключ партнёра работает, только пока партнёр одобрен в программе. Иначе чтение отвечает 403 affiliate_inactive.
• С ключом партнёра параметр affiliate игнорируется, а на by=affiliate возвращается группировка по дням.
• Лимит частоты чтения считается на ключ.

Аутентификация

Каждый запрос к /v1 подписывается ключом. Каждый запрос содержит три заголовка:

Чтобы подписать запрос:

1. Сформируйте тело и сохраните точные байты, которые будете отправлять.
2. Возьмите текущее Unix-время в секундах, десятичным текстом.
3. Соедините метку времени, точку (.) и тело.
4. Вычислите от этого HMAC-SHA256 на вашем секрете и запишите в hex в нижнем регистре.
5. Отправьте тело без изменений, с тремя заголовками.

Подпись запроса на чтение

У GET нет тела, поэтому подпись считается от цели запроса: пути и строки запроса в точности как при отправке, например 1790000000./v1/reports?by=link&days=7. Если строки запроса нет — от метки времени, точки и пути. Сформируйте адрес один раз, подпишите этот текст и отправьте этот же текст: клиент, который после подписи меняет порядок параметров или перекодирует строку запроса, ломает подпись.

• Сначала проверяется ключ, затем метка времени, затем подпись.
• Заголовок Content-Type не обязателен. Передавайте application/json для событий и text/csv для файлов.
• Сменённый ключ перестаёт работать сразу.

Примеры подписи

В каждом примере одна функция подписи; он отправляет регистрацию, а затем читает отчёт. Замените ID ключа и секрет своими.

KEY="pb_your_key_id"
SECRET="your_secret"
BASE="https://app.revrake.com"

# sign <payload>: hex HMAC-SHA256 of "<timestamp>.<payload>" under the secret
sign() { printf '%s.%s' "$TS" "$1" | openssl dgst -sha256 -hmac "$SECRET" -hex | sed 's/^.* //'; }

# Write: the payload is the body.
TS=$(date +%s)
BODY='{"type":"registration","player_id":"PLR-1001","click_id":"CID_FROM_LANDING_URL"}'
curl -X POST "$BASE/v1/postback" \
  -H "Content-Type: application/json" \
  -H "X-RevRake-Key: $KEY" \
  -H "X-RevRake-Timestamp: $TS" \
  -H "X-RevRake-Signature: $(sign "$BODY")" \
  -d "$BODY"

# Read: the payload is the path and the query, exactly as sent.
TS=$(date +%s)
TARGET='/v1/reports?by=link&days=7'
curl "$BASE$TARGET" \
  -H "X-RevRake-Key: $KEY" \
  -H "X-RevRake-Timestamp: $TS" \
  -H "X-RevRake-Signature: $(sign "$TARGET")"

import { createHmac } from 'node:crypto';

const KEY = 'pb_your_key_id';
const SECRET = 'your_secret';
const BASE = 'https://app.revrake.com';

// hex HMAC-SHA256 of "<timestamp>.<payload>" under the secret
function sign(secret, timestamp, payload) {
  return createHmac('sha256', secret).update(`${timestamp}.${payload}`).digest('hex');
}

function headers(payload) {
  const ts = Math.floor(Date.now() / 1000).toString();
  return { 'X-RevRake-Key': KEY, 'X-RevRake-Timestamp': ts, 'X-RevRake-Signature': sign(SECRET, ts, payload) };
}

// Write: the payload is the body. Send the same string you signed.
const body = JSON.stringify({ type: 'registration', player_id: 'PLR-1001', click_id: 'CID_FROM_LANDING_URL' });
const write = await fetch(`${BASE}/v1/postback`, {
  method: 'POST',
  headers: { 'Content-Type': 'application/json', ...headers(body) },
  body,
});
console.log(write.status, await write.json());

// Read: the payload is the path and the query, exactly as sent.
const target = '/v1/reports?by=link&days=7';
const read = await fetch(BASE + target, { headers: headers(target) });
console.log(read.status, await read.json());

import hashlib
import hmac
import json
import time
import urllib.error
import urllib.request

KEY = "pb_your_key_id"
SECRET = "your_secret"
BASE = "https://app.revrake.com"


def sign(secret: str, timestamp: str, payload: bytes) -> str:
    """hex HMAC-SHA256 of "<timestamp>.<payload>" under the secret"""
    return hmac.new(secret.encode(), timestamp.encode() + b"." + payload, hashlib.sha256).hexdigest()


def call(method: str, target: str, body: bytes | None = None):
    ts = str(int(time.time()))
    # Write: the payload is the body. Read: the path and the query, as sent.
    payload = body if body is not None else target.encode()
    headers = {"X-RevRake-Key": KEY, "X-RevRake-Timestamp": ts, "X-RevRake-Signature": sign(SECRET, ts, payload)}
    if body is not None:
        headers["Content-Type"] = "application/json"
    req = urllib.request.Request(BASE + target, data=body, method=method, headers=headers)
    try:
        with urllib.request.urlopen(req, timeout=10) as res:
            return res.status, json.load(res)
    except urllib.error.HTTPError as e:
        return e.code, json.load(e)


event = {"type": "registration", "player_id": "PLR-1001", "click_id": "CID_FROM_LANDING_URL"}
print(*call("POST", "/v1/postback", json.dumps(event).encode()))
print(*call("GET", "/v1/reports?by=link&days=7"))

<?php
const KEY = 'pb_your_key_id';
const SECRET = 'your_secret';
const BASE = 'https://app.revrake.com';

// hex HMAC-SHA256 of "<timestamp>.<payload>" under the secret
function sign(string $secret, string $timestamp, string $payload): string
{
    return hash_hmac('sha256', $timestamp . '.' . $payload, $secret);
}

function call(string $method, string $target, ?string $body = null): array
{
    $ts = (string) time();
    // Write: the payload is the body. Read: the path and the query, as sent.
    $payload = $body ?? $target;
    $headers = [
        'X-RevRake-Key: ' . KEY,
        'X-RevRake-Timestamp: ' . $ts,
        'X-RevRake-Signature: ' . sign(SECRET, $ts, $payload),
    ];
    $ch = curl_init(BASE . $target);
    curl_setopt_array($ch, [CURLOPT_CUSTOMREQUEST => $method, CURLOPT_RETURNTRANSFER => true, CURLOPT_TIMEOUT => 10]);
    if ($body !== null) {
        $headers[] = 'Content-Type: application/json';
        curl_setopt($ch, CURLOPT_POSTFIELDS, $body);
    }
    curl_setopt($ch, CURLOPT_HTTPHEADER, $headers);
    $answer = curl_exec($ch);
    return [curl_getinfo($ch, CURLINFO_RESPONSE_CODE), json_decode($answer, true)];
}

$event = ['type' => 'registration', 'player_id' => 'PLR-1001', 'click_id' => 'CID_FROM_LANDING_URL'];
print_r(call('POST', '/v1/postback', json_encode($event)));
print_r(call('GET', '/v1/reports?by=link&days=7'));

package main

import (
	"bytes"
	"crypto/hmac"
	"crypto/sha256"
	"encoding/hex"
	"fmt"
	"io"
	"net/http"
	"strconv"
	"time"
)

const (
	key    = "pb_your_key_id"
	secret = "your_secret"
	base   = "https://app.revrake.com"
)

// sign is the hex HMAC-SHA256 of "<timestamp>.<payload>" under the secret.
func sign(secret, timestamp string, payload []byte) string {
	mac := hmac.New(sha256.New, []byte(secret))
	mac.Write([]byte(timestamp + "."))
	mac.Write(payload)
	return hex.EncodeToString(mac.Sum(nil))
}

func call(method, target string, body []byte) (int, string, error) {
	ts := strconv.FormatInt(time.Now().Unix(), 10)
	// Write: the payload is the body. Read: the path and the query, as sent.
	payload := body
	if body == nil {
		payload = []byte(target)
	}
	req, err := http.NewRequest(method, base+target, bytes.NewReader(body))
	if err != nil {
		return 0, "", err
	}
	req.Header.Set("X-RevRake-Key", key)
	req.Header.Set("X-RevRake-Timestamp", ts)
	req.Header.Set("X-RevRake-Signature", sign(secret, ts, payload))
	if body != nil {
		req.Header.Set("Content-Type", "application/json")
	}
	res, err := (&http.Client{Timeout: 10 * time.Second}).Do(req)
	if err != nil {
		return 0, "", err
	}
	defer res.Body.Close()
	answer, err := io.ReadAll(res.Body)
	return res.StatusCode, string(answer), err
}

func main() {
	event := []byte(`{"type":"registration","player_id":"PLR-1001","click_id":"CID_FROM_LANDING_URL"}`)
	fmt.Println(call("POST", "/v1/postback", event))
	fmt.Println(call("GET", "/v1/reports?by=link&days=7", nil))
}

Тестовый вектор

С этими входными данными ваш код должен выдать ровно такие подписи:

Секрет

test_secret

Метка времени

1791072000

Тело

{"type":"registration","player_id":"PLR-1001","btag":"1001_1"}

Подпись

115d8c73c6069d8953a36ca3a68c114da6232e4ba31889fd519d41ab1350a603

Цель запроса на чтение

/v1/reports?by=link&days=7

Подпись запроса на чтение

ed1ed72dd7ddef22c762f63b8919011e7c36c7214b55b72693c5927fb4b911d0

Лимиты

Это все лимиты, которые продукт сегодня применяет к интеграциям, трекингу и партнёрам, с их значениями. Вход, сброс пароля и заявки тоже ограничены для защиты от злоупотреблений.

Два эндпоинта записи, POST /v1/postback и POST /v1/files, ограничены на ключ (см. таблицу). Каждый ответ содержит X-RateLimit-Limit и X-RateLimit-Remaining; отказ — это 429 с Retry-After. Отправляйте события в их естественном темпе, а для догрузки истории используйте пакеты. У трекинговой ссылки ограничения частоты нет; необычный всплеск кликов по одной ссылке с одного адреса поднимает флаг фрода, но переход всё равно выполняется.

Лимит частоты чтения

• Каждый ключ может делать 120 запросов на чтение в минуту. Запас — это корзина на 120: чтение забирает один, и один возвращается каждые полсекунды. Ключ, который простаивал, может сделать 120 чтений сразу; после этого — два в секунду.
• Каждый ответ на чтение содержит X-RateLimit-Limit (всегда 120) и X-RateLimit-Remaining (сколько чтений осталось прямо сейчас).
• Сверх лимита ответ — 429 rate_limited с заголовком Retry-After: сколько секунд ждать. Подождите, затем отправьте тот же запрос снова, подписав его свежей меткой времени.
• Лимит считается на ключ: у ключа оператора и у ключа каждого партнёра свой запас.

HTTP/1.1 200 OK
X-RateLimit-Limit: 120
X-RateLimit-Remaining: 117

HTTP/1.1 429 Too Many Requests
X-RateLimit-Limit: 120
X-RateLimit-Remaining: 0
Retry-After: 1

{"error":"rate_limited","message":"Too many requests: at most 120 reads a minute per key. One more is allowed every half second; wait the seconds in Retry-After and try again."}

Обработка 429

// read(target) signs one GET with a fresh timestamp and sends it,
// as in the signing samples.
async function readWithRetry(target, tries = 5) {
  for (let i = 0; i < tries; i++) {
    const res = await read(target);
    if (res.status !== 429) return res;
    const seconds = Number(res.headers.get('Retry-After')) || 1;
    await new Promise((resolve) => setTimeout(resolve, seconds * 1000));
  }
  throw new Error('still rate limited after ' + tries + ' tries');
}

POST /v1/postback

Сообщает об одном событии с платформы оператора. Тело — JSON-объект с полем type и полями этого типа или JSON-массив таких объектов (пакетная отправка).

POST https://app.revrake.com/v1/postback

• type — одно из значений: registration, deposit, chargeback, ngr.
• Поле, не перечисленное для типа, отклоняется с 422, так что опечатка никогда не проходит молча.
• ts — время события в формате RFC 3339 (2026-10-04T08:15:00Z). Если его нет, берётся время запроса. В нём должно быть смещение от UTC (Z или +03:00); время без смещения отклоняется. Оно не может быть в будущем больше чем на сутки.
• Сумма — десятичное число, JSON-текстом или JSON-числом: "25.00" или 25.5. Без разделителя тысяч, без экспоненты и не больше десятичных знаков, чем у валюты.
• currency — трёхбуквенный код ISO 4217. Нижний регистр принимается. Если не передан, берётся валюта отчётности рабочего пространства.
• У текстовых значений обрезаются пробелы в начале и в конце, кроме click_id и btag: передавайте их ровно в том виде, в каком они пришли на лендинг.

registration

Новый игрок. Передайте click_id, btag, promo_code или несколько из них; без них игрок записывается как неатрибутированный. Игрок атрибутируется один раз, здесь. Ответ: attribution.

{"type":"registration","player_id":"PLR-1001","click_id":"01K6QF3M8Z5T7W9XB2C4D6E8GH","btag":"1001_1"}

{
  "status": "accepted",
  "event_type": "registration",
  "event_id": "0199b2c4-6f1e-7a53-9d0c-2b8f4e1a7c33",
  "attribution": {
    "attributed": true,
    "reason": "click",
    "affiliate_number": 1001,
    "link_number": 1,
    "click_id": "01K6QF3M8Z5T7W9XB2C4D6E8GH",
    "policy_version": 1,
    "window_days": 30,
    "model": "last_click"
  }
}

deposit

Отправляйте событие deposit для каждого депозита с ID транзакции в txn_id. Сделка определяет, сравнивать ли минимум CPA с первым депозитом или с суммой депозитов за вычетом чарджбэков. При выполнении условия создаётся одна комиссия CPA на игрока, в холде.

{"type":"deposit","player_id":"PLR-1001","txn_id":"TX-88213","amount":"25.00","currency":"KES","first":true}

{
  "status": "accepted",
  "event_type": "deposit",
  "event_id": "0199b2c9-03aa-7e10-b6d2-91c07f5e2a18",
  "commission": {
    "effect": "created",
    "type": "cpa",
    "amount_minor": 4000,
    "status": "hold"
  }
}

chargeback

Отправьте событие chargeback с собственным txn_id и txn_id исходного депозита в ref_txn_id. Оно отменяет весь депозит. При накопительном CPA комиссия отзывается, только если оставшаяся зачётная сумма становится ниже минимума: комиссия в холде отклоняется, для одобренной или выплаченной добавляется строка отмены.

{"type":"chargeback","txn_id":"CB-5001","ref_txn_id":"TX-88213"}

{
  "status": "accepted",
  "event_type": "chargeback",
  "event_id": "0199cc10-7b2d-7c41-a3f0-5d2e8b9c1f47",
  "commission": {
    "effect": "cancelled",
    "type": "cpa",
    "amount_minor": 4000,
    "status": "rejected"
  }
}

ngr

Чистый игровой доход (NGR) игрока за день или месяц. По нему начисляется RevShare той версии сделки, которая действует на конец периода, в холде. Игрок должен быть зарегистрирован. Ответ: commission.

{"type":"ngr","player_id":"PLR-1001","period":"2026-10-03","amount":"118.40","currency":"KES"}

{
  "status": "accepted",
  "event_type": "ngr",
  "event_id": "0199b2d1-5c0e-7b42-8a17-3e9d6f0c4b21",
  "commission": {
    "effect": "created",
    "type": "revshare",
    "amount_minor": 2960,
    "status": "hold"
  }
}

Ответ

На событие, которое сохранено или уже было сохранено, возвращается 200 и JSON-объект. Неприменимые поля опускаются.

{
  "status": "accepted",
  "event_type": "deposit",
  "event_id": "0199b2c9-03aa-7e10-b6d2-91c07f5e2a18",
  "waiting_for_player": true
}

{
  "status": "duplicate",
  "event_type": "deposit",
  "event_id": "0199b31f-8c02-7a66-b4e1-2d7f9a3c6e15",
  "duplicate_of": "0199b2c9-03aa-7e10-b6d2-91c07f5e2a18",
  "detail": "The same deposit (TX-88213) was already reported through the API; this one adds nothing."
}

{
  "status": "duplicate",
  "event_type": "deposit",
  "event_id": "0199b2ca-11d4-7f09-8c55-0a6e2d4b7f90",
  "commission": { "effect": "none", "reason": "not_first" }
}

Комиссия создаётся со статусом hold. Она одобряется автоматически, когда заканчивается холд сделки, если её ничто не удерживает: открытый фрод-флаг, неодобренный партнёр или отсутствующий курс.

Причины атрибуции

Сначала проверяется click ID. Если он не из ваших, проверяется btag. Если правило говорит, что побеждает btag, и btag совпадает со ссылкой, первым проверяется btag. Btag, совпавший со ссылкой, атрибутирует игрока, даже если клик не найден. Промокод проверяется последним, только если ни click ID, ни btag не атрибутировали игрока. Правило, его окно и то, что из двух побеждает, задаются на странице «Интеграция»; каждое изменение становится новой версией. Если политика отдаёт приоритет промокоду, совпавший с ссылкой код проверяется раньше обоих, а несовпавший возвращает к ним. Сделка может задать своё окно, которое заменяет окно политики для кликов по ссылкам её партнёров.

Почему комиссия не создана

Пакетная отправка

Телом может быть JSON-массив от 1 до 1000 событий, отправленный на тот же эндпоинт с теми же заголовками. Подпись считается от всего массива. События обрабатываются по порядку, каждое отдельно, так что одно отклонённое событие не останавливает остальные.

На массив, который удалось прочитать, возвращается 200 — даже если все события в нём отклонены. Смотрите на счётчики.

[
  {"type":"deposit","player_id":"PLR-1001","txn_id":"TX-88213","amount":"25.00","first":true},
  {"type":"ngr","player_id":"PLR-1001","period":"2026-10-03","amount":"118.40"},
  {"type":"ngr","player_id":"PLR-1002","period":"October","amount":"-12.50"}
]

{
  "results": [
    {
      "index": 0,
      "status": "accepted",
      "event_type": "deposit",
      "event_id": "0199b2c9-03aa-7e10-b6d2-91c07f5e2a18",
      "commission": { "effect": "created", "type": "cpa", "amount_minor": 4000, "status": "hold" }
    },
    {
      "index": 1,
      "status": "duplicate",
      "event_type": "ngr",
      "event_id": "0199b2d1-5c0e-7b42-8a17-3e9d6f0c4b21",
      "commission": { "effect": "created", "type": "revshare", "amount_minor": 2960, "status": "hold" }
    },
    {
      "index": 2,
      "status": "rejected",
      "field": "period",
      "message": "period must be a day (2026-10-03) or a month (2026-10), not in the future."
    }
  ],
  "accepted": 1,
  "duplicate": 1,
  "rejected": 1
}

POST /v1/files

Отправляет ежедневный CSV-файл: альтернатива его загрузке на странице «Интеграция» или тому, чтобы RevRake забирал его с адреса, по которому его публикует ваша платформа. Тело запроса: сам файл; заголовки и подпись те же, что у события, а подпись считается от метки времени и файла. Имя файла передаётся в параметре строки запроса filename; оно показывается в портале и больше нигде не используется.

POST https://app.revrake.com/v1/files?filename=sales-2026-10-03.csv

Строка заголовка определяет тип файла: файл со столбцом registration_date — это файл REG, со столбцом activitydate — файл SALES. Имена столбцов сопоставляются без учёта регистра. Столбцы, не перечисленные ниже, могут оставаться в файле; они игнорируются.

Форматы дат: YYYY-MM-DD, YYYY-MM-DD HH:MM:SS, YYYY-MM-DDTHH:MM:SS, RFC 3339 или YYYY/MM/DD. Без смещения UTC применяется часовой пояс файлов из настроек рабочего пространства (по умолчанию UTC). Время со смещением задаёт точный момент; для SALES используется его календарный день в часовом поясе файлов. Порядок дня и месяца не угадывается: 30/09/2026 отклоняется.

Файл REG: одна строка на зарегистрированного игрока

brand_name,registration_date,btag,promo_code,player_id,player_country
Example,2026-10-03,1001_1,,PLR-1001,KE
Example,2026-10-03,,,PLR-1002,KE
Example,2026-10-03,,GARAGE50,PLR-1003,KE

Файл SALES: одна строка на игрока в день

brand_name,activitydate,player_id,btag,currency,deposits,first_deposit_amount,chargeback,casino_net_revenue,sports_net_revenue
Example,2026-10-03,PLR-1001,1001_1,KES,3500.00,2500.00,0,118.40,0
Example,2026-10-03,PLR-1002,,KES,900.00,0,0,-12.50,

• Каждая строка SALES сохраняет дневную денежную сводку и, если заполнены ячейки выручки, отдельное событие NGR. Они обрабатываются независимо: отклонение денежной сводки не отменяет принятую выручку, и наоборот. Проверяйте все проблемы в ответе.
• Одна сводка на бренд, игрока и день активности; первая принятая валюта фиксируется. Одинаковые денежные значения считаются повтором даже после переименования файла или перестановки строк. Изменение сумм, валюты или часовых границ принятого дня вызывает конфликт, в том числе при изменении нулей. Записанные деньги остаются неизменными.
• deposits, first_deposit_amount и chargeback — обязательные столбцы. Пустая ячейка означает ноль. Суммы должны быть неотрицательными десятичными числами с точностью валюты строки. Согласуйте эти определения с платформой до подключения экспорта.
• Отправляйте REG перед SALES. Денежные сводки, полученные раньше, сохраняются и рассчитываются при поступлении регистрации. NGR неизвестного игрока отклоняется: после REG повторите SALES или NGR. Сохранённая денежная сводка будет обработана как повтор.
• Сводка покрывает отдельные постбэки за её день активности и в её валюте в часовом поясе файлов, без двойного суммирования. ID транзакций остаются доступны для ссылок. Известные депозиты или чарджбэки сверх сводки, а также противоречивые данные о первом депозите вызывают конфликт.
• Для накопительного CPA депозиты за вычетом чарджбэков должны достичь минимума сделки. Каждый дневной денежный поток использует курс своей даты активности; отдельные постбэки — своего дня UTC. Без курса расчёт остаётся в холде с fx_rate_missing. Отсутствие курса чарджбэка блокирует выплату с chargeback_fx_missing до сверки, в том числе для комиссий, уже включённых в выплату.
• При CPA по первому депозиту агрегированный чарджбэк может не указывать отменённый депозит. Неоднозначная денежная сводка зарегистрированного игрока отклоняется. Если она пришла до REG, сводка сохраняется и регистрация принимается, но созданный CPA остаётся в холде с chargeback_reference_missing. Для проверки ссылки на транзакцию отправьте чарджбэк, указав ID транзакции исходного депозита в ref_txn_id.
• Выручка независима от неизменяемых денежных итогов: изменение дневного NGR считается корректировкой, а разница комиссии записывается отдельным корректирующим начислением.

Ответ

Читаемый файл возвращает 200. Счётчики относятся к событиям, а не только строкам: строка SALES может отдельно сохранить денежную сводку и NGR, в том числе с частичным успехом. Всегда проверяйте rejected и problems.

{
  "id": "0199b31e-2a40-7d18-9b6c-4f1e7a2c5d03",
  "filename": "sales-2026-10-03.csv",
  "kind": "sales",
  "uploaded_at": "2026-10-04T02:00:07Z",
  "rows_total": 2,
  "accepted": 3,
  "duplicates": 0,
  "rejected": 1,
  "skipped": 0,
  "problems": ["line 3: Player PLR-1002 is not registered. Send the registration first."]
}

GET /v1/reports

Возвращает отчёт страницы «Отчёты»: клики, помеченные клики, регистрации, первые депозиты и заработок, сгруппированные по одному признаку, за дни по сегодняшний в часовом поясе рабочего пространства. Цифры за сегодня обновляются при запросе отчёта, на загруженной программе — не чаще раза в 30 секунд.

GET https://app.revrake.com/v1/reports?by=link&days=7

{
  "by": "link",
  "from": "2026-09-28",
  "to": "2026-10-04",
  "currency": "KES",
  "rows": [
    {
      "key": "0199a7f0-41c2-7e55-b1d9-6c3a8e2f7b10",
      "label": "telegram-october",
      "clicks": 1840,
      "flagged_clicks": 212,
      "registrations": 96,
      "ftds": 31,
      "earnings_minor": 12400000
    }
  ],
  "total": {
    "key": "",
    "label": "",
    "clicks": 1840,
    "flagged_clicks": 212,
    "registrations": 96,
    "ftds": 31,
    "earnings_minor": 12400000
  }
}

В формате CSV

С format=csv ответ — файл. Его первый столбец назван по группировке и содержит подпись группы; далее идут clicks, flagged_clicks, registrations, first_deposits и earnings_<currency> десятичным числом. Последняя строка — итог.

link,clicks,flagged_clicks,registrations,first_deposits,earnings_KES
telegram-october,1840,212,96,31,124000.00
total,1840,212,96,31,124000.00

GET /v1/commissions

Возвращает одну страницу реестра комиссий, сначала новые, если вы не задали другую сортировку. Суммы в строках никогда не редактируются, и строки никогда не удаляются, но status строки меняется после её записи: hold, затем approved, затем paid — или rejected. Синхронизация должна перечитывать период и обновлять строки по id, а не только загружать новые.

GET https://app.revrake.com/v1/commissions?from=2026-09-01&to=2026-10-01&per_page=500

{
  "currency": "KES",
  "totals": { "hold": 1240000, "approved": 3720000, "paid": 9800000 },
  "owed": { "KES": { "hold": 1240000, "approved": 3720000, "paid": 9800000 } },
  "period": true,
  "commissions": [
    {
      "id": "0199b2c9-0a11-7c3e-9f20-7d4b1e6a2c58",
      "occurred_at": "2026-09-14T08:20:00Z",
      "type": "cpa",
      "currency": "KES",
      "gross_currency": "KES",
      "reporting_minor": 400000,
      "affiliate_name": "Odds Garage",
      "affiliate_number": 1001,
      "player_ref": "PLR-1001",
      "deal_name": "CPA 4000",
      "deal_version": 2,
      "gross_minor": 250000,
      "rate_snapshot": 400000,
      "amount_minor": 400000,
      "status": "approved",
      "status_reason": "",
      "hold_until": "2026-10-14T08:20:00Z",
      "status_note": ""
    }
  ],
  "total": 1,
  "page": 1,
  "per_page": 500
}

Строка комиссии

Списки программы: партнёры, ссылки, сделки

Ваш бэкенд может получить программу в том виде, в каком её показывает кабинет: с подписью, как и другие чтения, и в том же лимите. GET /v1/affiliates и GET /v1/deals требуют ключ оператора; с ключом партнёра они отвечают 403 operator_key_required. GET /v1/links отдаёт ссылки бренда или одного партнёра с affiliate=<номер>; с ключом партнёра — только его ссылки.

Списки разбиты на страницы параметрами page (с 1) и per_page (от 1 до 500, по умолчанию 100) и содержат total. GET /v1/affiliates принимает также status: pending, approved, rejected или suspended. Создавать партнёров и ссылки через API пока нельзя: расскажите, для чего вам это нужно.

GET https://app.revrake.com/v1/links?affiliate=1001&per_page=100

Каждый партнёр

Каждая ссылка

Каждая сделка

Выгрузка в хранилище данных

Настраивается на странице «Интеграция»: каждую ночь RevRake записывает предыдущий день каждого бренда в ваш собственный бакет любого S3-совместимого сервиса по пути <папка>/<бренд>/<ГГГГ-ММ-ДД>/; день считается в часовом поясе рабочего пространства. Четыре CSV-файла, сжатых gzip (UTF-8, строка заголовков, кавычки по RFC 4180), затем manifest.json. Манифест пишется последним: загружайте день, когда он появился, и сверяйте rows, bytes и sha256 каждого файла.

Строка относится к дню, когда она поступила (клик — когда был сделан), поэтому опоздавший ежедневный файл попадает в день поступления и не теряется. Время — RFC 3339 в UTC с миллисекундами; суммы — десятичные числа в своей валюте. Статусы — на момент выгрузки: статус комиссии потом меняется, поэтому за текущим снова читайте GET /v1/commissions. Неудачный день повторяется каждый час и догоняется до семи дней назад; повторная выгрузка дня перезаписывает его файлы. В конец файла могут добавляться новые столбцы; schema_version в манифесте меняется, когда загрузчик должен измениться.

manifest.json: schema_version, workspace, brand, day, timezone, from и to (границы дня в UTC), generated_at и files: для каждого name, rows, bytes, sha256 (сжатого файла).

clicks.csv.gz: все клики по ссылкам бренда за день, включая помеченные.

players.csv.gz: игроки, чья регистрация поступила в этот день.

events.csv.gz: все принятые события бренда, поступившие за день, включая дневные сводки SALES, с их содержимым.

commissions.csv.gz: строки комиссий, записанные в этот день.

Идемпотентность

У каждого события есть естественный ключ. Идентичный повтор возвращает сохранённый ответ с "status":"duplicate". Ответ депозита, ожидавшего регистрации, обновляется при её поступлении. Изменённые денежные данные могут вызвать конфликт; корректировки NGR используют ревизии. После тайм-аута повторите запрос с новой временной меткой подписи.

Статусы и ошибки

Все ответы, которые может дать API, и все статусы, которые может иметь запись, в одном месте. На ошибку возвращается JSON-объект: error (код), message (предложение на английском) и, для invalid, field.

{"error":"invalid","field":"amount","message":"amount must be a positive decimal in KES, for example 25.00."}

HTTP-статусы и коды ошибок

• Массив без событий или больше чем с 1000 событий отклоняется с 422 invalid без field.
• Ответ 401 из-за неверной метки времени или подписи с ключом оператора отображается в журнале входящих как bad_signature. Запрос с неизвестным ключом или с ключом партнёра в журнал не попадает.
• Чтение отвечает 422 только на период отчёта, который нельзя использовать (from и to). Любой другой параметр с недопустимым значением игнорируется, и берётся значение по умолчанию. Проверяйте by, page и per_page в ответе.
• Повторяйте запрос при таймауте, при 429 и при 500. Не повторяйте другие 4xx без изменений.

На что указывает field в ответе 422

Статус события

В ответе на одно событие и для каждого события в results при пакетной отправке.

Что событие изменило в реестре

Типы комиссий

Статусы комиссий

Строка записывается один раз, и её суммы никогда не меняются. Меняется её статус:

Значения status_reason

Пусто, если строка ожидает только окончания холда, и обычно для одобренных или выплаченных комиссий. Отсутствующий курс чарджбэка может блокировать и одобренную строку. Холд по подозрению в мошенничестве ожидает оператора или настроенного срока истечения флага.

Статусы выплат

Месяц закрывается в пакет выплат с одной позицией на партнёра и валюту. С пакетами и позициями работают в портале; API показывает их результат как статус paid строк комиссий.

Почему строка файла отклоняется

Отклонённая строка учитывается в rejected, перечисляется в problems в виде line N: reason и сохраняется в журнале входящих вместе с самой строкой. Помимо причин, по которым может быть отклонено событие:

• Строка не является корректным CSV.
• REG: registration_date или player_id отсутствует либо не читается.
• SALES: activitydate или player_id отсутствует либо не читается.
• SALES, выручка: игрок не зарегистрирован.
• SALES, деньги: сумма отрицательна, не читается или содержит слишком много знаков после запятой для валюты.
• SALES: первый депозит превышает общую сумму депозитов.
• SALES: принятый день повторно выгружен с изменёнными денежными итогами, валютой или часовыми границами.
• SALES: известные отдельные депозиты или чарджбэки превышают дневную сводку.
• SALES: данные о первом депозите противоречат другому дню или известной транзакции.
• SALES: агрегированный чарджбэк неоднозначен для CPA по первому депозиту уже зарегистрированного игрока.

Результаты в журнале входящих

Состояния доставки постбэка

Статусы партнёра

Трекинговая ссылка

Трекинговую ссылку открывает посетитель, ваша платформа её не вызывает. Она сохраняет клик и отвечает редиректом 302 на лендинг бренда. Пока бренд не подтвердил свой сайт, посетитель сначала видит короткую страницу о том, куда ведёт ссылка. Хост назначения берётся из настроек бренда; ссылка может выбрать только путь на нём.

GET https://track.revrake.com/c/a8Kq2Zx?sub1=TRACKER_CLICK_ID&utm_source=telegram

HTTP/1.1 302 Found
Location: https://your-site.example/landing?btag=1001_1&cid=01K6QF3M8Z5T7W9XB2C4D6E8GH&utm_source=telegram
Cache-Control: no-store

Параметры ссылки

Параметры, добавляемые к URL лендинга

• Если URL лендинга бренда содержит {click_id} в строке запроса, click ID подставляется туда, а cid не добавляется.
• Клик по ссылке неодобренного партнёра сохраняется и помечается, а посетитель попадает на лендинг без cid и btag: такой клик нельзя атрибутировать.
• Боты, превью ссылок, запросы HEAD, запросы без user agent и повторные клики в течение часа сохраняются и помечаются, а не отбрасываются. В отчёты они не входят.
• Другие параметры ссылки не сохраняются и не передаются.
• Ссылка, которой партнёр дал короткое имя, отвечает и по адресу /go/<name>, точно так же, как по /c/<code>. Бренд с собственным подтверждённым трекинговым доменом обслуживает оба пути и на этом домене.
• На неизвестный код возвращается 404 и HTML-страница ошибки; так же отвечает ссылка, у бренда которой ещё не задан адрес назначения.

Постбэки в трекеры партнёров

Эта часть не требует работы со стороны оператора. Каждый партнёр добавляет в своём портале до 10 адресов назначения: шаблон адреса с макросами и события, о которых нужно сообщать. Когда по игроку партнёра записано событие, RevRake заполняет шаблон и вызывает его запросом GET.

События

Слова-статусы по пресетам

Адрес назначения, созданный из пресета, отправляет в {status} слова, которые знает его трекер. Пресеты Voluum, PeerClick и FunnelFlux Pro, а также «Другой / свой», отправляют слова из таблицы выше. Слова определяются пресетом, который записан у адреса назначения; его сохранённый адрес никогда не меняется.

Макросы

Макрос — это имя в фигурных скобках. Он заменяется своим значением в URL-кодировке. Имена сопоставляются без учёта регистра. Неизвестное RevRake имя отправляется как есть, так что опечатка видна в журнале доставок. Неизвестное значение остаётся пустым.

Другие имена тех же макросов

Трекеры называют одно и то же по-разному. Эти имена тоже принимаются:

Пресеты

В портале партнёра есть эти шаблоны. Партнёр заменяет хост на хост своего трекера. Каждый шаблон следует документации своего трекера: {conversion_id} стоит в параметре транзакции там, где трекер обновляет конверсию, пришедшую повторно под тем же ID, а {event_id} — там, где трекер отбросил бы более поздние события.

Пример

https://YOUR-TRACKER-DOMAIN/postback?click_id={sub1}&event={event}&status={status}&payout={commission}&currency={currency}&tid={conversion_id}&eid={event_id}

GET https://tracker.example/postback?click_id=TRACKER_CLICK_ID&event=ftd&status=sale&payout=40.00&currency=KES&tid=0199b2c9-0a11-7c3e-9f20-7d4b1e6a2c58&eid=0199b2c9-03aa-7e10-b6d2-91c07f5e2a18%3Aftd

Доставка

• Постбэк ставится в очередь в той же транзакции, что и событие, о котором он сообщает, и отправляется примерно в течение десяти секунд, сначала самые старые.
• Запрос — это GET с user agent RevRake-Postback/1. Он следует не более чем по трём редиректам и прекращает ожидание через 5 секунд. Сертификаты проверяются.
• Ответ 2xx — успех. Всё остальное — неудача; доставка повторяется через 1 минуту, 5 минут, 25 минут, 2 часа, 10 часов и 24 часа.
• После последнего повтора доставка помечается как остановленная. Партнёр может отправить её вручную.
• Каждая попытка записывается с длительностью, статусом и первыми 500 символами ответа.
• После 5 и после 15 неудач подряд владелец адреса назначения получает e-mail. После 20 адрес назначения выключается. Его доставки, включая доставки событий, которые происходят, пока он выключен, продолжают вставать в очередь и отправляются, когда партнёр включает его снова. Адрес назначения, который партнёр выключил сам, ничего нового не получает.
• RevRake вызывает только публичные адреса. Loopback-адреса, частные, link-local и адреса carrier-grade NAT отклоняются в момент установления соединения, так что редирект не позволяет это обойти.
• Шаблон должен быть полным адресом http:// или https:// длиной не более 2000 символов.

Почему попытка не удалась

Вебхуки оператора

Вебхуки сообщают собственным системам оператора (CRM, хранилищу данных, чат-каналу), что происходит в программе. Администратор рабочего пространства добавляет эндпоинт на странице «Интеграция» портала оператора: адрес на вашем сервере, события для отправки и необязательное описание. На каждое из этих событий RevRake отправляет на адрес подписанный JSON-запрос POST. Другие участники команды не могут видеть или менять эндпоинты.

Адрес указывается полностью, с https://, на публичном хосте (http:// принимается, но используйте https://). У каждого эндпоинта свой секрет, он начинается с whsec_. Секрет показывается один раз, при создании эндпоинта или смене секрета: скопируйте его сразу. Смена секрета сразу создаёт новый, а старый перестаёт подписывать.

Endpoint может быть и каналом Slack или Microsoft Teams: выберите «Сообщение в Slack» или «Сообщение в Microsoft Teams» и вставьте адрес входящего вебхука канала (для Teams — процесс «Когда получен запрос вебхука Teams»). Тогда каждое событие приходит в канал фразой вместо подписанного JSON, а сумма позволяет оставить только первые депозиты от этого размера.

События

Отметьте одно или несколько для каждого эндпоинта. Поля data описаны ниже; поле, которое не относится к событию, не передаётся.

Тело запроса

Каждый запрос несёт один JSON-объект:

{
  "id": "0199b2c9-0a11-7c3e-9f20-7d4b1e6a2c58",
  "type": "commission.created",
  "created_at": "2026-10-05T09:12:44.318204Z",
  "data": {
    "player_id": "PLR-1001",
    "occurred_at": "2026-10-05T09:12:40Z",
    "attributed": true,
    "affiliate_number": 1001,
    "affiliate_name": "Odds Garage",
    "commission_id": "0199b2c9-0a0f-7a51-8c3d-5e2f4a6b7c90",
    "commission_type": "cpa",
    "amount": "25.00",
    "amount_currency": "USD",
    "commission": "40.00",
    "commission_currency": "USD"
  }
}

Ключи могут идти в любом порядке, а пробелы в JSON не фиксированы. Проверяйте байты в том виде, в каком они пришли, и только потом разбирайте их.

Заголовки

Запрос также несёт Content-Type: application/json и user agent RevRake-Webhook/1.

POST /revrake-webhook HTTP/1.1
Host: example.com
Content-Type: application/json
User-Agent: RevRake-Webhook/1
RevRake-Event: commission.created
RevRake-Delivery: 0199b2c9-0b7e-7d02-8a41-3c5e6f708192
RevRake-Timestamp: 1791191571
RevRake-Signature: <hex HMAC-SHA256 of "1791191571.<raw body>">

Поля data

Проверка запроса

1. Прочитайте сырое тело как байты, до любого разбора JSON.
2. Убедитесь, что RevRake-Timestamp отличается от ваших часов не более чем на 5 минут, иначе отклоните запрос: так записанный запрос нельзя будет воспроизвести позже.
3. Вычислите hex HMAC-SHA256 от метки времени, точки и сырого тела под секретом эндпоинта и сравните с RevRake-Signature за постоянное время.
4. Только после этого разберите тело. Если вы уже обработали его id, ответьте 2xx и ничего не делайте.
5. Отвечайте любым 2xx в течение 5 секунд, а медленную работу выполняйте после.

Та же проверка на Node.js и Python, как её показывает страница «Интеграция»:

const crypto = require("node:crypto");

// raw: the body exactly as received (a Buffer), before parsing it as JSON.
function verify(raw, headers, secret) {
  const ts = headers["revrake-timestamp"] ?? "";
  if (!/^\d+$/.test(ts) || Math.abs(Date.now() / 1000 - Number(ts)) > 300) return false;
  const expected = crypto.createHmac("sha256", secret).update(ts + ".").update(raw).digest();
  const got = Buffer.from(headers["revrake-signature"] ?? "", "hex");
  return got.length === expected.length && crypto.timingSafeEqual(got, expected);
}

import hashlib, hmac, time

# raw: the body exactly as received (bytes), before parsing it as JSON.
def verify(raw: bytes, headers, secret: str) -> bool:
    ts = headers.get("RevRake-Timestamp", "")
    if not ts.isdigit() or abs(time.time() - int(ts)) > 300:
        return False
    expected = hmac.new(secret.encode(), ts.encode() + b"." + raw, hashlib.sha256).hexdigest()
    return hmac.compare_digest(expected, headers.get("RevRake-Signature", ""))

Доставка, повторы и отключение

• Доставка ставится в очередь в той же транзакции, что и изменение, о котором она сообщает, поэтому событие отправляется тогда и только тогда, когда изменение сохранено. Оно отправляется примерно в течение десяти секунд, начиная с самых старых.
• Доставка выполняется как минимум один раз: одно событие может прийти больше одного раза, например, если ваш ответ потерялся по дороге. Отбрасывайте повторы по id из тела.
• Порядок не гарантирован: повтор может прийти после более позднего события. Упорядочивайте события по created_at или occurred_at, а не по времени прихода.
• Ответ 2xx в течение 5 секунд считается успехом. Всё остальное считается неудачей и повторяется через 1 минуту, 5 минут, 25 минут, 2 часа, 10 часов и 24 часа, с тем же телом и новыми меткой времени и подписью.
• После последнего повтора доставка помечается как остановленная. Администратор может отправить её снова кнопкой «Отправить снова» в журнале доставок; тогда она снова проходит всё расписание повторов.
• После 20 неудачных попыток подряд эндпоинт отключается. Его события продолжают вставать в очередь, и всё накопленное отправляется, когда администратор включит его снова. Email при этом не отправляется: состояние каждого эндпоинта видно на странице «Интеграция».
• Эндпоинт, который вы отключили сами, ничего нового не получает: пока он выключен, события для него в очередь не ставятся.
• RevRake обращается только к публичным адресам: ждёт ответа не дольше 5 секунд и проверяет сертификаты. Loopback, частные, link-local адреса и адреса carrier-grade NAT отклоняются. Редиректу RevRake не следует: ответ 3xx считается неудачей с ошибкой redirect, а журнал доставок показывает адрес, на который он указывал.

Проверьте и читайте журнал доставок

• Нажмите «Отправить тест» у эндпоинта: событие webhook.test отправляется сразу, подписанное как настоящее, и вы видите статус, которым ответил эндпоинт, и время ответа. Тест не повторяется, не попадает в журнал доставок и не считается неудачей.
• Журнал доставок эндпоинта показывает последние 100 доставок: событие, состояние (ожидание, повтор, остановлено или доставлено), число попыток, последний статус или ошибку, первые 500 символов вашего ответа, следующую попытку и тело в том виде, в каком оно было отправлено.
• Неудачная попытка описывается теми же словами, что и для постбэка (см. почему попытка не удалась), плюс redirect: ваш эндпоинт ответил кодом 3xx. Состояния те же, что у доставки постбэка.

{
  "id": "0199b2d4-5c60-7b1a-9e3f-1a2b3c4d5e6f",
  "type": "webhook.test",
  "created_at": "2026-10-05T09:30:02.104377Z",
  "data": {
    "message": "A test from RevRake. If you can read this, your endpoint works."
  }
}

Рекомендации

• Храните секрет на своём сервере, никогда на странице или в приложении. Если он утёк, смените его и сразу переведите эндпоинт на новый: старый секрет перестаёт работать немедленно.
• На запрос, подпись которого не совпала, отвечайте 4xx. Он будет повторён с подписью текущим секретом, поэтому доставка, пришедшая во время смены секрета, не потеряется.
• Сохраняйте id каждого обработанного события и игнорируйте событие, которое уже видели.
• Сначала ответьте, потом работайте: поставьте событие в собственную очередь и ответьте 2xx, чтобы медленная база данных никогда не заставляла RevRake повторять запрос.
• Указывайте конечный адрес эндпоинта. Редиректу RevRake не следует: попытка завершается ошибкой redirect, а журнал доставок называет адрес, который нужно указать вместо него.
• Используйте commission_id, чтобы связывать события об одной комиссии, и сверяйтесь с GET /v1/commissions: ночное чтение за последние 60 дней поймает всё пропущенное.
• Отмечайте только те события, которые используете. Каждое из них это запрос к вашему серверу.

Файл OpenAPI

Четыре подписанных эндпоинта, со всеми статусами и причинами в виде перечислений, описаны в openapi.yaml (OpenAPI 3.1) — для генераторов кода и API-клиентов. Его адрес не меняется.