No description
  • Rust 96.6%
  • Dockerfile 3.4%
Find a file
2026-05-15 22:27:28 +05:00
.cargo just throwin there 2026-05-15 22:27:28 +05:00
adsbot.conf.example/leadbot just throwin there 2026-05-15 22:27:28 +05:00
migrations just throwin there 2026-05-15 22:27:28 +05:00
src just throwin there 2026-05-15 22:27:28 +05:00
.containerignore just throwin there 2026-05-15 22:27:28 +05:00
.gitignore just throwin there 2026-05-15 22:27:28 +05:00
Cargo.lock just throwin there 2026-05-15 22:27:28 +05:00
Cargo.toml just throwin there 2026-05-15 22:27:28 +05:00
Containerfile just throwin there 2026-05-15 22:27:28 +05:00
diesel.toml just throwin there 2026-05-15 22:27:28 +05:00
Makefile.toml just throwin there 2026-05-15 22:27:28 +05:00
README.md just throwin there 2026-05-15 22:27:28 +05:00
rust-toolchain.toml just throwin there 2026-05-15 22:27:28 +05:00
rustfmt.toml just throwin there 2026-05-15 22:27:28 +05:00

Very simple bot which will monitor VK ADS form leads and pass them to telegram upstream. Just throwin it here coz friend asked.

VK ADS API lead forms

See the configuration example

Arbitrary POST forms (TBD)

The arbitrary POST form is created with adsbot.conf/leadbot/features/formlead.d TOML configuration. The format is explained in the example.

POST request head shall contain Authorization header with one of the configured secret values.

POST request raw body size in bytes is limited by 4KiB.

Request raw body may be:

  • Either valid UTF-8 JSON string with Content-Type: application/json
  • Or a messagepack encoded message with Content-type: application/msgpack
  • Or a raw text, which is reported as-is without parsing with Content-type: text/plain

Response

Depending on the request criteria and server state

form

Parsed request body shall contain the field form, which is an array limited by 128 entries.

Excessive entries shall not be reported, form entries are reported in the order of presense.

Each of entries must follow the schema:

{
    type: "object",
    "properties": {
        "t": {
            "type": "string",
            "enum": ["text","tel","personal","yn"]
        },
        "d": {
            "type": "object"
        }
    }
}

Any form entry, which does not conform to the specified schema, will not be processed.

t/d fields

"text" type:

With the "t": "text" field set on the POST data, the d field is expected to follow the schema:

{
    "type": "object",
    "properties": {
        "q": {
            "type": "string",
            "description": "The form question/field name to display in report"
        },
        "a": {
            "type": "string",
            "description": "The user answer/value to display in report"
        }
    }
}

The "text" entry shall be included into report as-is.

"tel" type:

With the "t": "tel" field set on the POST data, the d field is expected to follow the schema:

{
    "type": "object",
    "properties": {
        "q": {
            "type": "string",
            "description": "The form question/field name to display in report"
        },
        "a": {
            "type": "string",
            "description": "The value, which will be treated as personal phone number",
        }
    }
}

When possible the "tel" entry shall be included into report as tel: anchor/link, and (when possible) shall be hidden under protective block, which does not grant visual access to the phone number without manual interaction or authorization.

"personal" type:

With the "t": "personal" field set on the POST data, the d field is expected to follow the schema:

{
    "type": "object",
    "properties": {
        "q": {
            "type": "string",
            "description": "The form question/field name to display in report"
        },
        "a": {
            "type": "string",
            "description": "The value, which will be treated as personal information"
        }
    }
}

When possible shall be hidden under protective block, which does not grant visual access to the phone number without manual interaction or authorization.

"yesno" type:

With the "t": "yn" field set on the POST data, the d field is expected to follow the schema:

{
    "type": "object",
    "properties": {
        "q": {
            "type": "string",
            "description": "The form question/field name to display in report"
        },
        "a": {
            "type": "boolean",
            "description": "The value, which will be treated as yes/no answer"
        }
    }
}

example

The following shall not be parsed and will be reported as-is

-- HEADERS --
Authorization: pqo8jdp9:p183ycnpdo1
Content-Type: text/plain
-- BODY --
I am a text. I wanna MANY alpacas. I demand:

- At least 1 black alpaca
- At most 4 white alpacas
- All alpacas to be either black or white
- Exactly 666 alpacas

The following shall be parsed as JSON

-- HEADERS --
Authorization: 0192mu:odump298yfcniudo8c3mo
Content-type: application/json
-- BODY --
{
    "form": [
        {
            "t": "personal",
            "d": {
                "q": "First name",
                "a": "Danis"
            }
        },
        {
            "t": "text",
            "d": {
                "q": "How much aplacas do you have?",
                "a": "120"
            }
        },
        {
            "t": "tel",
            "d": {
                "q": "Phone",
                "a": "88005553535"
            }
        },
        {
            "t": "yn",
            "d": {
                "q": "Do you want another aplaca?",
                "a": true
            }
        }
    ]
}

Development

Software requirements:

  • cargo-make
  • diesel-cli
  • podman

Prerequistes:

  • Create the dev-volumes/{adsbot.log,adsbot.db,adsbot.conf} directories, and configure the dev-volumes/adsbot.conf by example provided in adsbot.conf.example

Altering database schema:

Dont forget to create appropriate migrations by

diesel migration generate --diff-schema=<SCHEMA.RS> <MIGRATION_NAME>

Building from source

cargo make build for static binary build

cargo make image for container image

Please, note, that by default on each program startup the license and authors information from Cargo.toml are printed into the log. If you want to disable it - set the LOG_CREDENTIALS="none" env variable during the build