Apply to connect your store
Submit your website after signing in with Telegram and follow each review stage at a private URL. Automated checks support the reviewer; a moderator always makes the final decision.
On this page
Submit an application#
Descriptions require 40–3000 characters; project names allow up to 100. The website must be accessible without signing in. URLs containing credentials, private hosts, nonstandard ports or query parameters are not accepted.
The verified account owns the application. The entered Telegram contact is for communication and does not change ownership. Forwarding the tracking URL does not grant another account access.
- 1
Sign in or register with Telegram, then open /account#applications.
- 2
Enter a public HTTPS website address, project name, category and a description of your products or services.
- 3
Add a Telegram contact. Explain what customers receive and how orders are fulfilled.
- 4
Confirm your authority to submit the site and send the form.
- 5
Keep the /account#applications/{id} address that opens immediately after submission.
Four review stages#
The connecting line and stage markers reflect persisted server states. Reopening the page continues the same process. Closing the tab does not cancel your application; background jobs continue work and recover interrupted stages.
| Stage | What happens | Status shown |
|---|---|---|
| Application received | Submission details and the private URL are saved | The first stage is complete |
| Content review | AI compares the description with public website content | Running, complete or awaiting a specialist |
| Technical checks | Availability and a bounded set of links are examined | A separate result and stage timestamp |
| Specialist review | A moderator reviews the submission and findings | Awaiting decision, approved or a decline reason |
A yellow stage needs a specialist#
A yellow marker means that a stage needs attention, for example because information is insufficient, a link is unavailable or an automated result cannot be accepted confidently. It is not a final rejection. The status page explains the next step.
A moderator can clear the current stage so the next check continues. A declined stage displays a cross and a user-facing reason that the moderator can edit before sending. Clearing an intermediate stage never removes the final manual review.
What automated checks cover#
Checks examine the public home page: HTTPS, HTTP response, title, text and suspicious link patterns. They also request headers for at most three links on the same website. Redirect count, response size and request time are bounded.
The checks do not access signed-in areas, execute downloaded files or replace a security audit or malware scanner. Completing a stage does not guarantee that every page is free of malicious content.
Website content is untrusted data. Instructions on a website cannot assign an administrator, change Kevmi terms or approve an application. Unavailable AI and malformed model output require specialist review instead of silently passing the stage.
Telegram updates#
Receiving an application, completing a stage, requesting specialist attention and making a final decision create notifications with a private tracking link. These use the Support category in account notification settings. Disabling that category stops the messages.
The application event and notification outbox entry are committed together. Telegram delivery uses a retry queue and requires a connected bot. The tracking page remains the source of current status if Telegram is unavailable or the bot is blocked.
Moderation receives separate alerts. Only users on the server moderator allowlist can clear a stage from Telegram; an old button cannot apply a repeated decision. Decline reasons are edited in the moderation workspace.
Application and decision contract#
Ownership comes from the session. Applicants cannot submit userId, status, roles or review results. Repeating creation with the same Idempotency-Key and body returns the existing application; changing the body with that key produces a conflict.
A moderator decision applies only to the expected application version. Concurrent decisions save once; the other request receives 409. A decline reason is plain text of 10–1500 characters. Internal review evidence is restricted to moderators.
| Route | Access and behavior |
|---|---|
| POST /api/applications | Session + CSRF + Idempotency-Key; 202 with a private url |
| GET /api/applications | Current account applications |
| GET /api/applications/{id} | Owned submission, stages and public history |
| POST /api/applications/{id}/resume | Session + CSRF; continues processing applications only |
| GET /api/moderation/applications | Verified moderators only |
| POST /api/moderation/applications/{id}/decision | approve_step or reject, expectedVersion and a decline reason |
After the decision#
A new payment and card intent require the merchant’s latest website-review application to be approved. Approval alone does not connect the payment gateway. If the review changes after dispatch, the existing operation remains available for status reads, reconciliation and a requested bank code.
If rejected, the merchant sees the reason and can correct the materials before applying again. A yellow stage means a specialist still needs to decide; it is not automatic approval.