Fraud and bot protection
Onflow Ads runs a set of automated checks so that honest users do not have to police each other. This page describes only the parts you can see: what gets checked, what the checks can and cannot conclude, the exact messages and notifications they produce, and what you should do when one of them fires.
The thresholds, timings and signals that make abuse detection work are not published — publishing them would tell an abuser exactly how to stay under them. What is published is everything that affects an honest user: what triggers a visible action, what that action does, and how to get it undone if it was wrong. Terms §16.4 says the same thing about the duplicate-account test: a test whose numbers are public is a test that gets designed around, and then it protects nobody.
The one principle
Automated systems propose; people decide.
An automated check can pause money, flag an order, throttle a request or apply a fixed, published penalty for a confirmed failure. It can never permanently take your money, decide a dispute, or dock your score on a guess. Anything ambiguous goes to a human reviewer with no penalty applied in the meantime — and every penalty that does land can be appealed.
The ban lookups, the rate limiter, the reliability gate and the shield all return the permissive answer when the database or the cache is unreachable. A backend fault can therefore leave a restriction briefly unenforced. That is the deliberate trade: a protection quietly not firing for a minute is a far smaller harm than a fault locking every legitimate user out of the site.
What does the checking
Almost every check on this page that concerns a Telegram channel is carried out by @OnflowAdsBot, from its administrator position in that channel. That is the third of the bot's three jobs — alongside notifying you and publishing what the website arranged — and it is the reason a channel has to keep the bot as an admin to stay in the marketplace.
What it looks at is narrow and it is public: whether a channel exists and whether you administer it, its subscriber count and the view and reaction counts on recent public posts, and whether a placement it published is still there. It is never given your subscriber list, and it never reads private messages. See the Privacy Policy.
One check is not the bot's. The top-of-feed exclusivity check further down reads a page of a channel's recent public history — what else went up while an ad was supposed to be the newest post — and it does that through the platform's public-channel reader, a separate Telegram identity from the bot that sees only what any reader of a public channel sees. It needs no administrator position at all, and on a deploy where that reader is not configured the check simply does not run.
Both observe and report; neither decides anything. What they see is written to the same ledger everything else is written to, and the website applies the penalty, holds the payout or pays the compensation.
This page's title covers both: our bot, which does the checking described here, and the abusive automation the platform blocks — fake members, scrapers and scripted traffic. They are unrelated things that happen to share a word.
The delivery monitor (paid placements)
When you buy a paid placement, the bot watches the delivered post for the whole purchased window. This is the platform's answer to the oldest problem in ad placement: the post that goes up, gets screenshotted, and quietly comes down an hour later.
What it checks
| Check | What it means |
|---|---|
| The post still exists | The delivered post is still reachable in the channel it was promised in |
| The post is still pinned | Only where a pin was actually bought — the Pinned for the whole campaign extra, or the 7 days in feed · pinned throughout format. Both promise the pin for the whole booked run — and for no longer than that — so the whole run is what gets checked |
The formats that read 1 hour at the top · 24 hours in feed (and its 2/48 and 3/72 siblings), Native and the 30 days in feed month all promise that the ad is the newest post in the channel for the stated hours — the owner publishes nothing else in that window. That is a different promise from pinning, and the delivery monitor does not check it. It is checked separately and afterwards, by the top-of-feed exclusivity check below. Pinning is now a priced extra the owner chooses to sell, not something a format quietly includes.
Bookings taken before the formats were rewritten keep their old meaning. Those slots were sold as "pinned for N hours", so they are still delivered as a pin and still monitored as one. Nothing was changed retroactively — an owner is held to the promise that was on the page when the slot was sold, not to a later one.
What it can conclude
The monitor is deliberately conservative, because flagging an honest owner costs them reliability points and holds their money.
- It flags only when Telegram is explicit that the post is gone or the channel is unreachable — for example the post was deleted, the bot was removed from the channel, the channel's posting rights were revoked, or the channel went private.
- A network problem, a rate limit or any unrecognised error is treated as inconclusive and never flags anything. The check simply runs again on the next pass.
- One conclusive reading is not enough. A reading that looks conclusive is held as an unconfirmed marker and only becomes a flag if the next pass reads the same thing. Because a flag holds money — and on an insured order refunds it automatically — waiting one more cycle costs nothing against getting it wrong once.
- Only a definite unpin of the ad itself counts, and only on a booking that was actually sold with a pin. A newer message pinned on top of yours does not flag anything — though publishing over an ad inside its top-of-feed window is a separate matter, with its own separate check below.
What happens when it flags an order
All of this happens automatically, once per order:
- The order is marked as flagged, with the reason recorded.
- The owner takes the published −1.50 "post removed early" reliability penalty. It can only ever land once per order.
- The owner receives a notification titled "A placement was flagged automatically", naming the channel and the reason, ending with: "The payout is on hold — re-post the ad or contact support."
- The buyer receives a notification titled "A problem with one of your placements", ending with: "Your funds are still held — you can raise a concern from your campaigns."
- The payout on that order stops releasing. The money stays in escrow.
The two reasons you will actually see quoted are:
- "The post was deleted before its promised duration ran out."
- "We can no longer see the channel — the bot was removed, or the channel went private, before the placement finished."
An automated check is allowed to hold a payout. It is not allowed to take money back. Funds stay in escrow until the buyer confirms, the order completes normally, or the Onflow Ads team resolves it. That asymmetry is intentional.
Fairness rules built into the monitor
- After the window, the deal is done. Deleting the post once its paid window has fully elapsed is not under-delivery — the buyer received the entire duration they purchased, and nothing is flagged.
- Platform failures are never your fault. If a post could not go out because Telegram was down or an Onflow Ads system failed, the owner's score is untouched and the buyer is refunded or rescheduled instead.
- Unclear cases go to a person. When the cause of a delivery failure cannot be determined, no penalty is applied and the case is queued for a human reviewer. Ambiguity resolves in your favour, never against you.
- One cause, one penalty. Where a single act broke several placements in the same cross-promotion campaign at the same moment, Terms §15.1 binds the platform to treat it as one incident — see Appeals.
- Private channels are not monitored this way. A placement has to be a public post for the monitor to verify it.
If you are an owner and think a flag is wrong
- Check the channel — if the post is genuinely still up and reachable, say so.
- Re-post the ad if it came down by accident, then contact support with the order reference.
- Once the penalty appears on your ledger, use the Appeal button on it, within 30 days. See Appeals and fraud concerns.
How often it checks, by plan
The monitoring interval is a plan benefit — higher plans are checked more frequently, so a problem is caught sooner. The cadence for each tier is listed in Comparing the tiers.
Automatic refunds under Verified Delivery Insurance
On plans that include Verified Delivery Insurance (Elite and above), a monitor-flagged failure refunds you automatically. You do not have to raise a dispute or argue your case.
What you see: a notification titled "Refunded automatically". It names the channel and the refunded amount, adds the service credit where one applies, and ends with the line "You didn't need to raise a dispute — your plan covers this."
Rules that come with it:
- The refund is the full remaining charge on that order, returned to your wallet.
- The additional service credit is goodwill, not earnings — it is non-withdrawable and can only be spent on the platform.
- The owner keeps the reliability penalty from the flag and forfeits their good-faith stake, but is not charged for your goodwill credit. One failure, one penalty.
- Without this plan benefit, the same flag still pauses the owner's payout and still notifies you — you just raise a concern yourself to get the money back.
Tier details are on Comparing the tiers.
The top-of-feed exclusivity check (paid placements)
Most paid formats sell time at the top: for the stated number of hours the ad is the newest post in the channel, so anyone opening the channel in that window sees it first. That is the thing the advertiser actually paid for, and it is checked — separately from the delivery monitor, by a different reader, with a different penalty.
Nothing can stop a channel's own admins from posting. Slow mode does not apply to them and no Telegram permission covers it, so the platform does not pretend to prevent it. The owner agrees to the quiet window when they sell the slot, and the window is checked afterwards — exactly the way the delivery monitor checks that a post stayed up rather than trying to stop it coming down.
How it works
- One look, after the fact. Once the window has closed — plus a 5-minute settling delay, so a post made at the last second has time to appear — the platform reads a page of the channel's recent public history, up to 60 messages, and reconstructs the whole window from the timestamps on them. A single backwards look sees more than any polling cadence could, including something posted inside the window and deleted again before anyone came to look.
- What counts as a breach: a message published after the ad and dated inside the window.
- What does not: the ad's own album — a creative sent as a set of photos is several Telegram messages, and penalising an owner for the shape of the advertiser's creative would be absurd. Nor do service messages (a pin, a join, a title change), forwards of the ad itself, or an edit — editing a message does not make a new one.
- Two formats are never checked this way: Forward / repost and 7 days in feed · pinned throughout, because neither sells a top-of-feed window. And bookings taken before the formats were rewritten are outside it entirely — they were sold as a pin, so they are still policed as one.
Three answers, not two
The check returns ok, breached or unknown, and the third one is the point of it:
- ok — nothing else went up inside the window.
- breached — something did. How many posts, and how far into the window the first one landed, are both recorded and quoted back to both parties.
- unknown — the channel could not be read: unreachable, no longer public, or the reader came back empty. An
unknownis never recorded as a clean run and never as a breach. It goes back in the queue and is re-read on later passes; if it still cannot be read 25 hours after the ad was published it is closed asunknownfor good — an honest "we could not look", rather than a guess in either direction.
The delivery monitor takes two consecutive conclusive readings before it flags, because a live probe can catch a channel mid-blip and read "gone" from a network hiccup. This check does not, and that is a decision rather than an oversight: it is one retrospective read of an immutable past. Its uncertain answer already has its own value — unknown — and is retried, and a second read of the same history would return the same thing.
What a breach costs
| What moves | What happens |
|---|---|
| Reliability | −0.40 on the channel owner, once per placement, on the same ledger as every other mark and appealable the same way |
| Money | Nothing. The payout is unaffected, no escrow is held, no insurance fires, and the ad keeps running for its full booked duration |
It is deliberately far lighter than the −1.50 for a post removed early. Posting one extra message forty minutes in is a smaller wrong than taking the ad down, and a scale that priced them the same would stop meaning anything.
Both sides are told:
| Who | Notification | What it says |
|---|---|---|
| The channel owner | "Your channel posted during an ad's exclusive window" | Names the channel, how many posts went up and how far into the window the first one landed, then: "No money is affected — your payout still depends only on leaving the ad up for its full run." |
| The advertiser | "Your ad did not get its full time at the top" | The same facts, then: "We have recorded it against the channel. Your ad is still running for its full booked duration." |
If you sold 1 hour at the top, publish nothing else in that channel for that hour. It is the one thing on the rate card that a routine post can breach without anyone intending anything. The windows are deliberately short — one hour on the smallest format, three hours on the longest — so that they are livable alongside a normal posting schedule; if yours is tight, schedule the placement around it rather than through it.
The cross-promotion anti-cheat monitor
Cross-promotion swaps carry no escrow, so the protection is reputational — plus whatever insurance cover each side chose to declare. A monitor checks that both partners' posts stay live for the agreed campaign duration, and that each partner stays a member of the other's channel.
The bot that runs the monitor decides nothing about the score. It records the fact it observed — which post, which campaign, which kind of breach — into a queue the website owns; the website prices it from its published table and writes the ledger entry, usually within a minute. Two kinds of breach are recorded:
| What the monitor saw | Recorded as | What the website applies |
|---|---|---|
| The cross-post was taken down before the campaign ended | CP post removed early | −1.50 |
| The partner left (or left and rejoined) the other's channel while the post was still up | Left the partner channel early | −1.00 — lighter, because the partner's ad was still being read |
What each side sees:
| Who | Notification | Content |
|---|---|---|
| The person at fault | "Anti-Cheat Violation Detected" | Names the CP code (OFCP-…) and the channel, says what happened, and states what was recorded — "−1.50 recorded (your 0-to-10 track record) — it is applied on onflowads.com within a few minutes" — with a See why & appeal button to the reliability page. If the fact could not be recorded at all, the line reads logged for review — no change has been applied to your score yet |
| Their partner | "Partner Removed Their Post Early" or "Partner Left Your Channel Early" | Names the CP code and the campaign, and confirms the breach was logged and is priced on the website. There is nothing for them to do |
| Their partner, where the party at fault had declared insurance cover | "Campaign Insurance Claim Recorded" | Confirms the claim was recorded and that onflowads.com settles it into their wallet — the declared cover moves from the party at fault to the partner, into debt if the wallet cannot pay it. Their own score is unchanged |
The same conservative rule applies here: a probe that cannot reach the post is retried rather than treated as a deletion, so a temporary outage does not become someone's penalty.
Escrow and payment verification
- Money is held, not forwarded. On a paid placement, your payment is held while the deal is arranged and released to the owner only after the placement runs as agreed — or when you confirm it yourself from your orders page.
- Every top-up is verified with the payment provider before any wallet credit is applied, and each payment is credited exactly once. A duplicate charge is refunded in full. See the Refund Policy.
- Proof is public and verifiable. Placement proof pages let a third party — a client, a partner, an agency — verify that a placement really ran, without signing in or having an account.
- Higher plans add stronger escrow variants — retention escrow, which holds a slice of the owner's payout past delivery, and placement underwriting, which pays an upheld dispute back immediately. Both are described in Comparing the tiers.
Anti-abuse rules you should know about
These exist so honest users compete on a level field. All of them are published, because none of them can be gamed by knowing about them — they simply describe conduct that earns nothing or costs something.
| Rule | What it means in practice |
|---|---|
| Self-dealing earns nothing | Buying your own listing awards no reliability credit to either side. This includes two accounts sharing one Telegram identity. Trust cannot be manufactured by trading with yourself |
| Posting over an ad you sold costs you | Where a format promised hours at the top, publishing anything else in that channel inside the window costs the owner −0.40 reliability. No money moves over it, and the ad still runs its full booked duration |
| Trusted is held, not farmed | Above 9.0, each clean completion is worth steadily less as your score approaches 10, so a churn of cheap deals cannot pump a permanent 10 |
| Referral abuse is penalised | Confirmed self-referral or fake-signup schemes cost −2.00 reliability and sever the abuser's referral links |
| Chargeback fraud is penalised | A confirmed fraudulent payment reversal costs −2.00 reliability |
| Fake audiences are banned | Inflating members, engagement or reach with bots or purchased traffic breaches the Terms and Conditions and can end an account |
| Ratings are verified | A review on a paid placement can only be left by the advertiser who actually booked it, only once the booking is completed, and only once per booking. Attempting a second returns "You've already reviewed this booking." |
| False fraud concerns cost the raiser | A concern that does not stand costs you −0.50 reliability, and a repeated pattern of rejected concerns costs more |
| AI misuse closes its own door | Misusing the AI tools is reviewed by a human, and if confirmed docks reliability — which immediately tightens that account's own AI access |
None of the penalties above fire on suspicion. They fire on a confirmed outcome — an upheld concern, a confirmed reversal, a human-reviewed finding — and every one of them lands on your ledger where you can see it and appeal it.
The security check
Some actions carry a security check — the Checking your browser row you see under a form, shown as Onflow Security — which tells a person from a script without asking you to identify pictures of buses. Underneath it is Cloudflare Turnstile; the Privacy Policy names it in §18.3.
Where it runs:
| Where | When it is asked for |
|---|---|
| Create account, the contact form | Every time |
| Sign in, forgot password | Every time by default. An operator can set either to ask only past its per-address limit — 40 attempts on one email in 15 minutes for sign-in, 12 reset codes in 15 minutes for forgot-password |
| Withdrawal requests | Every time — the request opens the check as a small dialog, then goes through by itself |
| Support chat opened by a signed-out visitor | Every time. Members are never asked |
| The admin console's sign-in | Only from the third attempt in 15 minutes, per address and per identity — so a broken key can never lock an administrator out of the panel that fixes it |
How it behaves:
- It usually passes on its own. The row reads Checking your browser for a moment, then Browser verified. Only when the check cannot decide does a tick-box appear inside the same row, with Confirm you are human above it.
- A refused check is never a dead end. The form asks for a fresh check and sends again by itself; if it still cannot pass, the form says "Please complete the security check and try again." and the row offers Try again. Every check is single-use, so nothing is ever re-sent with a stale one.
- When it cannot load — a content blocker, a device clock that is wrong, an unsupported browser — the row says so in plain words and what to do about it, and Try again runs it once more. If your device clock is wrong, set the date and time to automatic.
- It is not a consent question. Privacy Policy §18.3 files it as strictly necessary — no banner, no opt-in — while stating plainly that it does see your IP address and browser, as any anti-abuse check must.
- It fails open, never closed. Where the check is not configured, or its provider cannot be reached, or the provider rejects our configuration, the action goes through rather than refusing everybody; only a check the provider actually refuses is refused. An operator is alerted when the provider reports the configuration as broken.
Rate limits
Every action that costs the platform something — signing in, filing a concern, cancelling a booking, leaving a review, generating with AI — is rate limited, and there is one coarse ceiling across the whole site on top of the per-action ones.
| Limit | What it is |
|---|---|
| Per action | Each endpoint has its own allowance — for example 20 fraud concerns an hour per account. Ordinary use never approaches one |
| Every write, per IP address and per account | Anything that changes something — a form, an order, a setting — is counted twice over: 90 per minute per IP address and 240 per minute per signed-in account by default, with tighter tiers on sign-in (10 per minute per IP), money (30 per minute per account) and uploads (20 per minute) |
| Site-wide, per IP address | A blunt burst protector: 300 requests per 60 seconds by default, static files not counted. Normal browsing never trips it; a scanner or a credential-stuffing burst does |
| Sign-in paths | Longer locks after repeated failed sign-ins, verification codes or password resets — see Limits and lockouts |
The complete table — every action, its budget, and the protections around the bot, the ad links and the administrators — is on Security and rate limits.
A handful of paths are exempt from the site-wide limiter entirely, because throttling them by IP would break something that has nothing to do with abuse: the uptime check, the files search engines and browsers read about the site, the brand images, and payment processors' callbacks — a payment confirmation must never be dropped for arriving too often.
What you see when you hit one:
| Message | What it is | What to do |
|---|---|---|
| "Too many attempts. Please wait a minute and try again." | The general-purpose short limit, on ordinary actions and on the site-wide ceiling | Wait a minute |
| "Too many attempts. Please try again in a few hours." | Sign-in protection after repeated failed attempts | Wait, or use the password reset |
| "Too many attempts. For your security this is locked for a few hours." | The same protection on the verification-code path | Wait it out |
None of these touch your reliability score or your account standing. They are traffic control, not conduct actions.
The cross-origin guard
Any request that changes something — submitting a form, placing an order, saving a setting — is checked against where it came from. If it carries an Origin or Referer header that does not match onflowads.com, it is refused:
"Cross-origin request blocked."
This is what stops a page on another site from acting on your account using your signed-in session. Two details worth knowing:
- A request with no such header at all passes. A command-line client or a server-to-server call carries no origin, and a page on another site cannot suppress that header on a cookie-bearing request — so "no header" is never a forged browser request.
- You will only ever see this by accident, typically from a browser extension or an embedded frame rewriting a page. Opening onflowads.com directly and retrying is the fix.
A refusal that says nothing at all
If the site answers a bare, unstyled page reading only Forbidden., that is not about your account. It is a block on the network address you are browsing from, it runs before sign-in, and it deliberately gives no reason and no expiry. It also covers the contact form and the support desk, so contesting one has to happen from a different connection.
Everything about that state — why it looks like this, why it can catch people it was not aimed at, and exactly how to get it lifted — is in Account standing.
Automated-access blocking
Onflow Ads can block crawler, scraper and script traffic to protect the site and its members' data. It is an operator setting with three positions, and which one is in force decides what you see:
| Setting | What it blocks | What it leaves alone |
|---|---|---|
| Off | Nothing | Everything |
| AI-crawler blocking | AI-training crawlers, answer-engine crawlers and commercial SEO scrapers | Search engines, link-preview fetchers and real browsers — so search ranking and social cards are untouched |
| Strict | The above, plus search engines, link-preview fetchers, generic HTTP client libraries, and anything a catch-all heuristic flags — including a request with no User-Agent at all | Very little |
What each one advertises about itself, so a well-behaved crawler does not have to be blocked to be told:
- AI-crawler blocking adds a per-bot
Disallowstanza torobots.txtfor every agent it refuses, and sendsX-Robots-Tag: noai, noimageaion pages. - Strict advertises the full
noindex, nofollow, noarchive, nosnippet, noimageindexset as well — which hides the site from search engines and breaks link previews. It is a defensive posture, not a normal one.
What you see when you are blocked:
- A page reading "403 — automated access to this site is disabled."
- On an API path, the same refusal as "Automated access is disabled."
Three exemptions matter to real users:
- Normal browsers are never affected. The block matches automated clients, not people.
- The developer API is permanently exempt, in every mode. The Boost developer API is key-authenticated and designed to be called by scripts. So are payment webhooks, ad-click redirects, email unsubscribe links, the public placement-verification endpoints and the public plan price list.
- A signed-in admin always passes, so an operator cannot lock themselves out of their own site.
Scraping the service is separately against the Terms and Conditions.
Moderation
- Channels are reviewed before they go live. A newly submitted or edited channel sits at Pending until it is approved, and shows Under review on its own page in the meantime. If changes are requested the status reads Needs changes and the reviewer's note appears on the channel page. Full walkthrough: Verify your channel.
- Campaigns and content may be reviewed for compliance with the acceptable-use rules.
- Content anyone can report. If something published through the platform is unlawful, infringes your rights or breaches the Terms, Terms §16.6 is the notice-and-takedown route: email [email protected] or use the contact form with a link to the exact post or listing, what is wrong with it, the right you rely on if any, and how to reach you. Knowingly false reports are themselves a breach.
- Moderation decisions are made by people, and a rejected channel can be edited and resubmitted.
If you think a protection got it wrong
| Situation | What to do |
|---|---|
| A placement of yours was flagged and you believe the post was live | Re-post if it came down, then contact support with the order reference; appeal the ledger entry once it appears |
| A reliability penalty landed that you think is wrong | Use the Appeal button on that entry in Your ledger, within 30 days — see Appeals and fraud concerns |
| You were told your ad "did not get its full time at the top" | Nothing to file. The breach is already recorded against the channel and your ad runs its full booked duration; there is no refund attached to it |
| A paid placement genuinely failed you | Raise a fraud concern from your orders page — same page |
| "Please complete the verification challenge and try again." on a form | Reload the page and submit again; the challenge token had gone stale |
| "Cross-origin request blocked." | Open onflowads.com directly rather than through a frame or an extension, and retry |
| A 403 — automated access page in an ordinary browser | Contact [email protected] with the page you were on |
| A bare page reading only Forbidden. | A block on your connection. Email support from a different network with the time and your public IP — see Account standing |
| You found a security vulnerability | Do not use the support queue. Use the disclosure route in Trust and safety |
| An unauthorised charge or a suspected account compromise | Email [email protected] immediately |
Frequently asked questions
Will an automated check ever take money out of my wallet?
No. Automated checks pause payouts and hold escrow. Money moves back to a buyer only through a refund path — an automatic service refund, an insurance refund on a covered plan, or a human-resolved concern.
Can the monitor flag me because Telegram had an outage?
No. Only errors that Telegram is explicit about — the post is gone, the channel is unreachable — can flag an order. Anything ambiguous is retried, and if a genuine platform failure caused a delivery miss, the buyer is refunded or rescheduled and the owner's score is untouched.
My views were lower than I expected. Is that fraud?
No, and it is not a reliability matter either. Reliability penalises non-delivery of the placement, never view variance — no owner fully controls views. Where a plan offers an underdelivery remedy, it is financial.
Does the monitor read my channel's private messages?
No. Everything either check reads is public, and both see only what any reader of your public channel sees.
The delivery monitor verifies that one specific public post still exists — and, on a booking that was actually sold with a pin, that it is still pinned. The top-of-feed exclusivity check reads a page of your channel's recent public history, because working out whether anything went up over an ad means looking at what went up: it reads the times those posts were published, not who read them. Neither is given your subscriber list, neither reads private messages, and Onflow Ads never messages your audience privately.
Why did I lose 0.40 points for posting in my own channel?
Because that channel had a live ad in the window it was sold. A format that reads "1 hour at the top" promises the advertiser that the ad is the newest post for that hour, and publishing anything else inside it breaks that promise. The mark is −0.40, it lands only on the owner, no money is affected, and the ad keeps running. If you think it is wrong — the post was outside the window, or it was the ad's own album — appeal the ledger entry within 30 days.
I got a "403 — automated access" page on my phone. What happened?
Almost always an in-app browser or an unusual client identifying itself in a way the filter matched. Try a normal browser, and if it persists, contact support with the page you were trying to open. Note that a plain Forbidden. page is a different thing entirely — that is a connection block.
Why did a form ask me to "complete the verification challenge" when I never saw one?
The anti-spam check is invisible when it passes, so the only time you meet it is when it fails — usually because the page had been open long enough for its token to expire. Reload and submit again.
Can I be penalised twice for the same incident?
Not for the same act. Each check applies its penalty at most once on any given order, and the resolution of a concern applies one outcome. A single act across a multi-partner cross-promotion is one incident under Terms §15.1.
Two different acts on one placement are two marks, though, and that is intended. The delivery monitor and the exclusivity check are independent, so an owner who publishes over an ad inside its top-of-feed window and then also takes the ad down early has broken two separate promises and carries both marks — −0.40 and −1.50 — on the same order. If you believe the same event was counted twice, appeal the second entry from your ledger.
Where do I see everything that has been applied to me?
The Your ledger section at the bottom of your reliability page — your 50 most recent score changes, each with a plain-language label, the date, and the score afterwards.
Related
- Account standing — every state a refusal can put you in, including the connection block
- Appeals and fraud concerns — the two ways to push back
- Trust and safety — escrow, proof and the responsible-disclosure route
- Limits and lockouts — the sign-in protections in detail
Next: Policies FAQ — the quickest answers across everything in this section, each one linking to the page with the full detail.