Fraud in live entertainment does not arrive at random. It arrives on the calendar you published: the announcement, the presale window, the transfer email, the cancellation notice. Attackers know the dates as well as you do, and they register the domains beforehand. Screening those domains is a lookup you can put directly in the click path.
Most fraud economics reward patience. Ticketing rewards precision timing, because the platform itself publishes when its users will be at their most desperate.
Think about what an onsale actually is from an attacker's point of view. A named artist, a named date, a named venue and a named minute are announced publicly, usually four to eight weeks ahead. At that minute, somewhere between tens of thousands and several million people will open a browser, search the artist's name, and click the first thing that looks like it might have tickets. They will be in a queue. They will be watching a countdown. They will be doing it on a phone, on mobile data, in a hurry, with their card details already in their hand. And they will be doing it on a site most of them have not visited since the last tour, which means they have no memory of what the real one looks like.
Every other industry asks its customers to be suspicious of unfamiliar domains. Live entertainment has spent two decades teaching fans that unfamiliar domains are exactly where the tickets are.
The structural problem in one sentence
That combination — enormous simultaneous intent, no baseline familiarity, and a public schedule — is close to unique. E-commerce has flash sales, but the buyer usually knows the retailer. Banking has fraud spikes, but the customer visits their bank monthly. In ticketing, the single most valuable behaviour you can teach a fan, which is "check the domain before you type your card in", is the exact behaviour the industry has spent twenty years untraining. Presales run on partner domains. Fan clubs run on artist-managed microsites. Bundles run on the record label's shop. Local promoters run on their own brand. A fan who insists on only trusting the primary ticketing domain will miss half the legitimate routes to a ticket.
Attackers exploit exactly that. In the days after an announcement, lookalike domains appear that combine the artist name, the tour name and a generic ticket word. Some are parked and monetised through advertising. Some are full clones of a real checkout. Some are simple credential pages that harvest an account login for the primary platform, which is far more valuable than one card number, because an account with tickets in it can have those tickets transferred out. Search advertising is bought against the artist's name so that the fake ranks above the real listing for a fan who searches rather than types. None of this requires a zero-day; it requires a diary.
The result is that a ticketing business carries a fraud surface that belongs partly to it and partly to nobody. The checkout you run is yours. The listing a scalper posts on a resale marketplace is yours to moderate. The direct message a fan receives on a social platform from a stranger offering two tickets at face value is not yours at all, but the fan will blame you, and the refund conversation will be with you. Any workable strategy has to cover the parts you own with enforcement and the parts you do not with verification tooling that fans can actually use.
This chain runs on almost every major onsale. Knowing its shape tells you where a domain lookup is worth having and where it is not.
The chain has a useful property: the middle is slow and the ends are fast. Registration and ad buying happen days or weeks before the onsale, and the fake domain usually has to resolve and serve content for a while to be worth the ad spend. That is the window in which a domain becomes visible to the security ecosystem, gets reported, gets verified and lands in a known-bad database. By the time the onsale minute arrives and the click volume spikes, a meaningful share of the infrastructure being clicked is no longer novel.
This is why a known-bad lookup performs better in ticketing than the theory suggests it should. The pattern is not one domain used once; it is a small set of domains built ahead of a publicised event and then used very heavily in a compressed window. The database behind this API holds over two hundred thousand DNS-verified, actively resolving phishing domains and is rebuilt on a twenty-four-hour cycle that finishes at 04:30 UTC each morning. For a Friday onsale, the list your systems query was assembled a few hours earlier that day.
Be equally clear about the failure case. A domain registered on the day, used for four hours during the onsale and then abandoned will not be in any known-bad list, because nothing had time to observe it. That is not a gap you can close with a lookup service; it is a gap you close with your own signals — domain age, whether the host appears anywhere in your brand's approved list, whether the link came from an unverified sender, whether the destination is a login form on a domain that has never sent you traffic before. The lookup is the input you cannot generate in-house, because it reflects what is phishing everybody else right now. Combine it, do not rely on it.
The week before an event is the second peak, and it is the one promoters underestimate. By then every ticket has an owner, every owner is waiting for a delivery email, and a large number of them do not remember which of six brands they bought from.
The message that works best is the simplest: your tickets are ready to transfer, sign in to accept them. It arrives from a domain that contains the venue name or the tour name, it carries the artist artwork lifted from the real campaign, and it asks for the one credential that matters — the account holding the tickets. Once inside, the attacker transfers the barcodes out and resells them. The fan discovers the problem at the turnstile, in front of a queue, with no recourse that feels acceptable to them.
Presale codes make it worse, because the legitimate flow already looks like phishing. A code arrives from a card issuer, a mobile network, a fan club or a radio station. It points at a domain that is not the ticketing platform. It asks the fan to enter a code and then sign in. There is no honest way to tell a fan that this is fine but the identical-looking message from a domain they have never seen is not — which is precisely why the verification has to be mechanical rather than educational.
Resale over social direct messages is the third strand and the hardest to reach. A stranger offers two tickets at face value, the conversation feels human, and the transaction ends on a payment page hosted on a domain the buyer sees for the first time thirty seconds before they pay. You cannot moderate a conversation you cannot see, but you can give the fan a place to paste the link, which is covered further down alongside the approach used in messaging platforms.
The fourth one is the design goal. If your genuine delivery mail never requires a sign-in from a link, the request to sign in becomes a reliable signal on its own.
The refund never needs a fan to enter card details anywhere. Saying that plainly in the announcement removes the pretext the fake pages depend on.
If there is one moment on this page worth building a runbook around, it is the announcement that an event is not happening. Nothing else in live entertainment produces the same combination of a large, identifiable, emotionally invested audience and a legitimate reason to expect money to move toward them.
Refund phishing works because the pretext is true. There really is a refund. The fan really is owed money. The only lie is the destination. And unlike an onsale, where at least some fans are habitual buyers who know the flow, a cancellation catches everybody at once, including the person who bought one ticket as a gift eight months ago and has never used the platform since.
Season-ticket renewal at sports clubs has the same structure on a slower clock. An account-manager impersonation aimed at a season-ticket holder is targeting a relationship worth four figures a year, with a payment date the club advertises. Clubs are also unusually easy to impersonate convincingly, because their fan communications are already a mixture of club domains, ticketing partner domains, and a payment provider — the same domain sprawl that makes an unfamiliar host feel normal.
Multi-day festivals produce the messiest version, because a washed-out day is neither a full cancellation nor a normal event. The refund is partial, the eligibility rules are complicated, and the official statement takes hours to draft while a hundred thousand ticket holders sit in a campsite refreshing a feed. Every hour of that drafting delay is an hour in which the only confident answer a fan can find is a fake one, so publish the eligibility rule and the refund domain first and the arithmetic afterwards.
These are the properties of the service that actually constrain a design. Everything else is detail you can read in the documentation.
Two of those numbers drive most design decisions. The batch limit of one hundred domains per request, combined with a rate limit of ten requests per second per key, gives a theoretical ceiling of a thousand domain verdicts per second per key through the batch endpoint — a number worth knowing before an onsale rather than during one. In practice you will not approach it, because a well-built integration deduplicates aggressively and holds a local cache for the day. The database itself only changes once every twenty-four hours, so a cache entry older than the last build is the only kind worth invalidating.
The other is the daily rebuild. Every entry is resolved through rotating proxy infrastructure and kept only while an A record is still answering, which is why the active count sits near two hundred thousand instead of climbing forever — nearly half a million domains have been recorded all time, and the ones that stopped resolving are not in the active set. For a ticketing platform this is the difference between a blocklist you can enforce against and one that generates support tickets, because a domain that no longer resolves cannot be what a fan is complaining about.
The payload itself is deliberately small. You get back the domain you asked about, an is_phishing flag, a category string, a DNS status, the date of the last verification pass, a confidence figure — 0.98 when there is a match, 0.0 when there is not — and the size of the database at the moment of the call. There is no page-level judgement, no screenshot, no logo comparison and no model score for a domain nobody has seen before. It is a fast, deterministic answer to one narrow question, and the narrowness is what makes it safe to put in a blocking path in front of a hundred thousand simultaneous users.
| Field | Meaning for a ticketing integration |
|---|---|
domain | The host you asked about, normalised. Echo it back into your own log line so a moderator can see exactly what was screened rather than the raw URL a seller pasted. |
is_phishing | The only field most call sites need. Boolean. Drive the block, the hold-for-review and the fan-facing warning from this and nothing else. |
category | What kind of phishing it is. Useful for reporting to a registrar or an ad network, and for telling a trust and safety lead which campaigns are hitting a given tour. |
dns_status | Whether the host still resolves. An active record is what makes a blocklist entry enforceable rather than historical noise. |
last_verified | The date of the last resolution pass. Put it in the moderator view; a dated verdict is evidence, an undated one is an opinion. |
confidence | 0.98 on a confirmed match, 0.0 otherwise. It is not a sliding risk score, so do not build tiers on top of it. |
database_size | How many domains were active at call time. Show it on a fan-facing checker so a clean result is honest about what it was compared against. |
Every one of these is a place where a domain string already exists in your systems. The work is plumbing, not invention.
Marketplaces that let a buyer and seller talk before a transfer carry links in that thread. Screen the host at send time and again at click time, and treat a hit as an account signal rather than a single blocked message.
Sellers put contact routes and off-platform payment links in free-text listing fields. Extract hosts from the description before the listing goes live and hold anything that matches for review.
When a promoter or venue submits a destination URL to your campaign builder, resolve and check it before the send goes out. A compromised promoter account has otherwise just bought your deliverability.
A simple page where a fan pastes a link and gets an answer. Host it on the promoter or platform brand, keep the key server-side, rate limit by session, and log every submission — the inputs are a standing feed of what fans are being sent.
Attach the verdict to every reported listing or account so a moderator sees it before opening the case. A confirmed phishing domain in a listing turns a judgement call into an immediate action with an audit trail.
Join the daily feed against the tour's brand terms — artist name, tour name, venue, common ticket words — and review what appears in the days after an announcement. It is a scheduled report, not an alert stream.
On event day a stadium's guest network carries tens of thousands of phones. Load the feed into the resolver behind it and the network stops being a convenient delivery path for last-minute upgrade scams.
The box office is a small, high-trust network where staff process refunds and reissue tickets under pressure. The same daily list applied there costs nothing extra and covers the terminal a duty manager borrows.
Check the destinations in your own transactional templates on every release. A partner microsite whose domain lapsed and was re-registered is the kind of thing you find in a scheduled sweep, never in an incident.
Sequencing matters as much as coverage. The trust and safety queue is the fastest to deliver and the easiest to justify, because it makes an existing team measurably faster without changing anything a fan sees. The listing and messaging checks come next; both are write-path work with a clear owner. The fan-facing checker is small but has a disproportionate effect on how a promoter's support team spends the week before a show, because it converts a stream of "is this real?" questions into a self-service answer.
Pre-onsale monitoring is the one that looks like the most work and is actually the least. You already know the brand terms for a tour — they are in the campaign brief. Joining them against a daily CSV is a scheduled job with no live dependency, and it gives the marketing and legal teams a list they can act on through the channels they already use. It is not a takedown service and this API does not perform takedowns, but it produces the evidence that a takedown request needs. The same logic underpins the approach on our brand protection page.
The last phase is the one nobody schedules and everybody needs: a standing sweep of the destinations in your own transactional and marketing templates, run whenever those templates change and at least once a quarter regardless. Tour microsites lapse, territory partners are swapped mid-run, and a shortener account that nobody has logged into since the last album is exactly the sort of asset that gets re-registered by somebody else. Finding that in a scheduled report costs an afternoon; finding it because fans are already clicking costs a great deal more.
Every technical control on this page is downstream of one editorial decision: whether a fan can tell your message from a copy of it without expertise.
Start by counting your sending domains. Most promoters, when they actually do this, find between six and fifteen: the primary ticketing platform, one or two resale brands, the venue, the festival, the artist's fan club, the label shop, a merchandise partner, an email service provider's tracking domain, a link shortener, and whatever the local promoter uses in each territory. Every one of those is a domain a fan is expected to trust on sight, and collectively they mean the fan has no rule they can apply. Reducing that list is the highest-leverage anti-phishing work available to a live entertainment business, and it is entirely within your control.
Second, decide what your genuine mail never does, and then never do it. The strongest version of this rule in ticketing is: our emails never ask you to sign in from a link, and never ask for card details. If that holds without exception, a fan has a single test that is easy to remember, does not require them to inspect a domain, and correctly classifies almost every fake. It also costs you something real — deep links into an account are convenient and they convert — so it is a genuine trade, and it should be made deliberately at the level of the business rather than by a template author.
Third, publish the domain list. Put a page on your primary brand that names every domain your organisation legitimately sends from and every domain a fan might be redirected to during a purchase. Link it from the footer of every transactional email. When a fan asks whether something is real, support can send one link instead of making a judgement. When a partner is added for a territory, the list gets updated, which forces someone to notice that a partner was added — a small governance benefit that pays for itself the first time.
Fourth, own the cancellation script before you need it. Write the postponement announcement now, with the refund domain named in it, the statement that no card details will ever be requested, and the instruction to ignore anyone who replies to the post offering help. Have it approved by legal and by the client. When a show is pulled at four in the afternoon, the announcement goes out in ten minutes rather than ninety, and the gap between the news breaking and your authoritative statement is the entire window the fake refund pages have to work in.
Fifth, treat the fan-facing verification page as part of the campaign, not part of the security programme. Put it in the announcement post. Put it in the presale email. Put it on the venue's screens. Fans will not go looking for a security tool, but they will use one that is placed where they already are — the same principle that makes an in-context warning work better than a training module, discussed further in our note on security awareness.
Finally, close the loop with your support desk. Every "is this real?" message a fan sends contains a domain, and those domains are the earliest signal you will get that a campaign is running against a specific show. Route them into the same check automatically, keep the ones that come back clean but suspicious, and hand the list to whoever runs your takedown relationships. A support inbox is an underused detection sensor, and in this vertical it is often faster than anything else you own.
Three very different shapes of the same integration, costed against the published monthly plans. The variable that matters most in all three is deduplication.
Take a resale marketplace first, because it has the highest raw volume. Suppose it handles three and a half million listings and fan-to-fan messages a month, of which roughly eight percent contain a URL. That is two hundred and eighty thousand URLs. Extract the host, normalise it, and deduplicate within a rolling twenty-four-hour window and the distinct-domain count typically collapses to somewhere near fifty to sixty thousand a month, because the overwhelming majority of links in a marketplace point at a small number of legitimate hosts. Call it fifty-five thousand a month, or six hundred and sixty thousand a year.
Set that against the Enterprise tier, where $999 buys 750,000 credits per lookup: one package, one year of write-path screening, no renewal conversation in between. If you also check at click time, which you should, budget separately for it: click-time checks hit a much smaller set of domains because most clicks go to hosts you have already resolved, so a same-day cache typically keeps the incremental cost to a small fraction of the write-path figure. A platform several times that size moves up to Enterprise plan at $999/month provides 750,000 lookups — or to the Enterprise plan at $999/month for 750,000 lookups.
A promoter is a completely different shape. There is no user-generated content to screen, so the volume is driven by campaign URL vetting, a fan-facing link checker and the support desk. A busy promoter running forty tours a year might submit a few thousand campaign destinations, field a few thousand fan submissions in the week around each major onsale, and process a few hundred support queries a week. The whole programme rarely exceeds a few tens of thousands of lookups a year. The Starter package at fifty-nine dollars for ten thousand credits is a realistic first purchase, and Growth at ninety-nine dollars for twenty-five thousand covers a full touring year for most independent promoters. lookups reset monthly, which suits a business with a seasonal shape.
A venue or stadium is different again, because the value is in the feed rather than in per-lookup calls. On event day the guest Wi-Fi behind a forty-thousand-seat stadium is not a place you want a synchronous external dependency; you want the list resident on the resolver. That is what the Daily Threat Feed is for. A subscription runs at $499 monthly; the subscription includes priority support and daily-updated data. What ships is the complete CSV — domain, category, DNS status — plus a changelog naming everything added and everything dropped since yesterday, which is what lets a resolver apply a delta instead of reloading the whole file. Pi-hole, BIND and Unbound sinkholes, firewall blocklists and SIEM ingestion into Splunk or QRadar are the intended targets. An enterprise arrangement is quoted individually and can add SFTP or S3 delivery, STIX/TAXII, a different update cadence, an SLA and on-premise deployment.
Whichever shape you are, measure before you buy. Instrument your own pipeline for a week — count URLs, count distinct hosts after normalisation, count distinct hosts after a twenty-four-hour cache — and size from that. Teams almost always overestimate, because raw URL counts look alarming and distinct-domain counts do not. Registration gives you a free key to run that measurement, and the monthly plans are published so the arithmetic is yours to do. Purchases are refundable for fourteen days provided under a tenth of the credits have been spent, and anything above $4,000 — as well as any feed subscription — can be settled by bank transfer rather than PayPal.
One more line item worth planning for: the onsale spike. If your architecture calls the API synchronously in the click path, model the worst case at the rate limit of ten requests per second per key and make sure your fallback on a 429 is to allow the click with your own signals rather than to fail the fan. A queue of two hundred thousand people is not the moment to discover that a security control is a single point of failure. The correct posture is a warm cache primed the night before, an asynchronous refresh, and a degradation path that never blocks a legitimate purchase because a lookup was slow.
Everything above happens on the internet. On the day itself, the fraud moves inside the perimeter of a building you control.
Guest Wi-Fi at a large venue is an unusual network. It exists for a few hours, it carries a very large number of devices that will never connect again, and it is used almost entirely for social media, ticket wallets and payment. It is also, from a fraud perspective, a captive audience standing in a queue with nothing to do. Last-minute upgrade offers, "your seat has moved" messages and fake merchandise pre-order links all perform unusually well in that context, because the recipient is physically at the event and the message is contextually plausible in a way it never would be at home.
Loading the daily list onto the resolver behind that network is one of the cheapest controls in this whole document. It requires no agent on any device, no cooperation from the fan, and no change to the captive portal. A domain that is confirmed phishing simply does not resolve, and the phone shows an error rather than a checkout. Because the list only changes once a day, the operational burden is a scheduled download and a reload — the same pattern venues already use for content filtering, and the same one described in our DNS filtering notes.
The box office deserves separate attention because the threat there is aimed at staff rather than fans. On event day a box office team is processing exchanges, reprints and refunds under time pressure, often with a supervisor logged into a system that can reissue barcodes. A message that appears to come from the promoter, asking for a guest list to be uploaded to a link, or from the ticketing platform, asking a supervisor to re-authenticate, lands in exactly the right conditions. Applying the same resolver policy to the box office network, and the same gateway screening to the shared operations mailbox, closes a gap that is easy to forget precisely because it is small.
Merchandise and fan-club operations are the last piece. A touring artist's merchandise store, fan-club membership renewals and VIP package sales are frequently run by separate companies on separate domains, with separate payment processors, on a schedule that follows the tour. They inherit all the trust the artist has built and none of the security engineering the primary ticketing platform has. If you run one of these, the relevant controls are the ones described for any small storefront handling card payments — the write-path and checkout screening covered on our e-commerce page, and the payment-side considerations on the payment processors page.
Finally, keep a record. Every blocked domain, every fan submission and every trust and safety case with a verdict attached is evidence — for the takedown request, for the platform report, for the police report a defrauded fan may file, and for next year's argument about budget. A tour is a repeatable event with a repeatable fraud pattern, and the single biggest advantage available to a promoter or venue is that they will do this again in six months with the same artist and the same fan base. Very few security problems come with that much foreknowledge. Use it.
Practical answers, including the places where this approach does not help.
Not on its own. This is a lookup against domains that have been confirmed as phishing and verified as still resolving. A host registered hours before it is used has not been observed by anyone yet, so it will not be in the database. What the service does cover well is the infrastructure that was stood up in the days or weeks after an announcement, which in ticketing is a large share of it, because the ad spend that drives traffic to a fake needs the site to exist for a while first.
Pair the verdict with your own signals — domain age, whether the host is in your approved list, whether the destination is a credential form, whether the link arrived from an unverified account — and use the lookup as the one input you cannot produce internally.
Both, for different reasons. Checking at write time lets you refuse to publish a listing or send a message, which is cheaper for everyone and keeps bad content off the platform entirely. Checking at click time catches the case where the destination was clean when it was posted and has since been confirmed bad — common in this vertical, because campaigns are built ahead of an event and only become widely reported once they are being used at scale.
Click-time checking is much cheaper than it sounds if you cache. Most clicks resolve to hosts you have already seen that day, and the database only rebuilds every twenty-four hours, so a same-day cache is correct rather than a compromise.
Ten requests per second per API key, with up to a hundred domains per batch request, which gives you a theoretical thousand verdicts per second through batching. Design so you never need it: prime a cache before the onsale from your known destination set, deduplicate hard, and refresh asynchronously rather than in the request path.
Decide your behaviour on a 429 in advance. The right answer for a consumer purchase flow is almost always to fall back to your own signals and allow the click, not to block a paying fan because a lookup queued. A 429 also means credits are exhausted or the limit was hit, so alert on it separately from ordinary errors.
No. The API key is the username chosen at registration, and putting it in front-end code exposes it to anyone who opens developer tools. Build the checker as a thin server-side endpoint on your own domain: the browser posts the pasted link to your server, your server strips it to a host, calls the API with the key held in your environment, and returns a simple verdict. Rate limit by session so the page cannot be used to burn your credits.
The same rule applies to a mobile app. Never ship the key in a bundle; proxy through your backend.
It does not. There is no takedown function, no registrar notification and no automated enforcement outside your own systems. What it gives you is a verified, dated, machine-readable record that a specific domain is live phishing infrastructure, which is the evidence a registrar, hosting provider, search platform or advertising network will ask for when you file a report.
Pair the daily feed with your tour brand terms and you have a repeatable process: a scheduled join produces candidates, your legal or brand team files the reports, and the record of what was found and when goes in the file.
The volumes are small enough that the Starter package at fifty-nine dollars for ten thousand credits covers a year comfortably for most independents, and the free key is enough to run a link checker and vet campaign destinations while you decide. The bigger investment is not money; it is the communications discipline — reducing your sending domains, deciding your mail never asks for a sign-in from a link, and writing the cancellation script before you need it.
Those cost nothing and they help more than any tool. The API is what catches the traffic that ignores them.
A pure social engineering scam — a stranger who takes a bank transfer and disappears, with no website involved — is outside what any domain lookup can see. That is a payments and identity problem, addressed by keeping transactions on platform, by escrow-style holds until transfer completes, and by the account-level signals your trust and safety team already builds.
The useful boundary is simple: if a domain appears anywhere in the interaction, this check applies. If it does not, you need a different control, and it is worth being explicit internally about which of your fraud categories fall on each side of that line so nobody assumes coverage that does not exist.
Register for a free key, screen the domains around your next tour, and put a link checker in front of the fans who are about to be targeted. The database rebuilds every morning, whether or not your onsale is today.
