How do I manage tour dates across Bandcamp, Spotify, and my site

Keep Bandcamp, Spotify, and the artist site aligned by writing dates in one calendar — usually Bandsintown for Artists, Songkick Tourbox, or an owned CMS — then letting the other surfaces read. Bandcamp does not take a pasted date list; as of its May 2026 help article it retrieves upcoming shows from Songkick. Spotify does not take Songkick either: it imports concerts from ticketing partners and states “We don’t display events from Songkick.” This spoke sits under Websites That Feel Like Films. I do not invent ticket-sale lifts for Foxtide, Arkayla, or anyone else. The receipt is the fan-out: one write, three readers, two different ingest pipes.

The short answer

• Pick one write calendar. Managers type there. Everything else is a reader.
• Site: embed or API from that calendar. Do not hard-code dates in Webflow Designer.
• Bandcamp: enable upcoming shows and pin the Songkick Artist ID. Name-match is not identity.
• Spotify: list the show with a current ticketing partner (Bandsintown is one path). Songkick will not get you there.
• If you need Bandcamp and Spotify, you are covering two pipes with one human — not maintaining two tours.

What does one calendar fanning out actually look like?

The architecture is a star, not a chain of copy-paste. One record. Many readers. The site is not a fourth calendar wearing nicer type.

Surface	Role	What it is allowed to store
Bandsintown / Songkick / owned CMS	Write	Date, city, venue, status, ticket URL, notes
Artist site (/ + /tour)	Reader	Widget, API, or CMS mirror of that record
Bandcamp sidebar	Reader	Songkick listings for this Songkick Artist ID
Spotify Live Events	Reader	Partner ticketing feed that qualifies
Link-in-bio / Stories	Pointer	URL to /tour or the live ticket link — never a handwritten list

Fan-out rule (say it out loud before you ship):

1. A date exists in exactly one write system.
2. The site displays that record.
3. Bandcamp ingests Songkick, not your site.
4. Spotify ingests a partner listing, not your site and not Songkick.
5. Social points at a URL. It does not own dates.

If Bandcamp, Spotify, and the homepage each have a date string a human typed, you do not have a system. You have three chances to be wrong on Friday.

The site can be film-grade and still be a reader. Cinema on the fold is a different job from the calendar. Dates are ops.

What does Bandcamp actually ingest?

Hedge this, because vendor partnerships move. As of Bandcamp’s May 2026 upcoming-shows article, Bandcamp uses your artist name to pull shows from Songkick unless you pin identity. You add and edit shows in Songkick Tourbox, not inside Bandcamp’s profile editor as a second calendar.

Bandcamp control	What it does	What it does not do
“Display upcoming shows”	Turns the sidebar on	Create shows
Songkick Artist ID or URL	Binds the sidebar to your Tourbox	Feed Spotify
Name-only match	Convenient until it is not	Survive a same-named act
Bandcamp merch / music	Commerce	Substitute for a ticket feed

Bandcamp’s own help is the Tonga joke: a name collision can inject someone else’s routing. Fix:

• Songkick artist page URL resolves to this act
• Numeric Songkick Artist ID (or full Songkick URL) is pasted into Bandcamp Profile → Upcoming Shows
• “Display upcoming shows” is ticked
• Changes are saved
• You do not retype dates into Bandcamp after a Tourbox edit

Songkick’s own Add your Songkick listings to Bandcamp article matches that paste-the-ID path. Treat name-match as a fallback, not the architecture.

What Bandcamp will not ingest, as of that help cluster:

• A Webflow CMS collection
• A Bandsintown-only calendar with no Songkick record
• A Google Sheet
• A Linktree block
• Spotify Live Events

If the only write tool on the team is Bandsintown, Bandcamp stays empty or wrong until Songkick has the same nights. That is ingest, not a Bandcamp bug.

Re-check the Bandcamp article at the start of every major tour cycle. I am not promising Songkick remains the only Bandcamp concert source forever. I am telling you what the current help page says to build against.

What does Spotify actually ingest?

Spotify is a reader with a partner filter. You do not type the routing into Spotify for Artists as the primary workflow.

Adding concerts to Spotify (re-read the live page; the partner table changes) says:

• List the concert with a ticketing partner site.
• Spotify imports from that list automatically.
• “We don’t display events from Songkick.”
• Required on the listing: at least one artist name, start time, venue name, event name.
• Virtual events are excluded on that article.

Spotify’s Live Events page is marketing around the same import: partner ticketing companies supply the feed. I do not repeat Spotify’s campaign ticket-count anecdotes as if they were your numbers. Import ≠ conversion.

Spotify question	Honest answer (as of September 2026 help)
Can I paste dates into Spotify for Artists?	Not as the source of truth. List upstream.
Does Songkick get me on Spotify?	No. The adding-concerts article says they do not display Songkick.
Is Bandsintown enough?	It is on the published partner list. Qualification still depends on listing fields.
Is Ticketmaster / AXS / DICE enough?	If that ticketer is on the current partner list, Spotify may ingest that listing — you do not also need a fake BIT tour.
How fast?	Missing-concerts help: should show within 24 hours; can take a few days. After that, contact Spotify with the event link and the artist profile.
Wrong time or room?	Fix at the ticketing partner. Spotify will not be your editor.

Partner-list hedge: the adding-concerts page is a long, living checklist (Bandsintown, Ticketmaster, AXS, DICE, Eventbrite, See Tickets, and many regional ticketers). Do not memorize a blog copy of it. Open the Spotify article the week you announce. If your actual ticketer is already a partner, do not invent a second Bandsintown calendar just to “be on Spotify.” Let the ticketer feed Spotify. Cover Bandcamp with Songkick.

TBA hedge: Spotify’s required venue name is why a city-only TBA listing can look fine on your site and still be invisible on Spotify until the room is real. That is partner policy, not a broken embed.

Virtual / livestream hedge: the adding-concerts article excludes virtual events. Do not promise a stream night on Spotify Live Events because it exists on /tour.

Why can’t Bandcamp and Spotify share one feed?

They do not ingest the same vendor. That is the whole post, in one sentence.

You need on the internet	Ingest pipe that actually feeds it	Write tool that feeds that pipe
Bandcamp sidebar	Songkick	Tourbox (or a system that writes Songkick)
Spotify Live Events	A current Spotify ticketing partner	That partner’s listing (often the real ticketer; BIT if they tell you to)
Site tour module	Whatever you embed or query	The same write calendar the manager will open at 11:40 p.m.

Decision table — pick a write dashboard, then cover the other pipe with the minimum extra work:

Write dashboard	Site reader	Bandcamp coverage	Spotify coverage
Songkick Tourbox	Tourbox website widget	Pin Songkick ID on Bandcamp	Separate partner listing (ticketer or BIT) if Spotify matters
Bandsintown	BIT widget or events API	Songkick still needs the nights	BIT is on Spotify’s partner list when the listing qualifies
Owned CMS (Webflow, etc.)	CMS → homepage next-3 + /tour	Still write Songkick if Bandcamp matters	Still need a partner listing if Spotify matters
Real ticketer already a Spotify partner	Embed BIT or Songkick or CMS — pick one	Songkick for Bandcamp	Let the ticketer feed Spotify — do not clone the tour into BIT “just in case”

Two full calendars typed by two humans is the failure. One human, one dashboard, plus a one-time ID pin and whatever partner listing already exists, is the product.

Worked pipes (same 12-date run, no invented sales):

Your real stack this cycle	Write once in	Cover Bandcamp with	Cover Spotify with	Do not
Tickets on Ticketmaster; Bandcamp sidebar matters; site needs a widget	Songkick Tourbox (manager lives there) or BIT if that is the phone tool	Pin Songkick ID	Ticketmaster listing, if it is still on Spotify’s partner list	A second BIT tour “for Spotify”
No major ticketer; BIT widget on the site; Spotify wanted	Bandsintown	Copy or sync nights into Tourbox; pin ID	BIT partner path, required fields complete	Hoping Songkick fills Spotify
CMS waitlist + custom rows; both platforms in scope	CMS as the team write, plus scheduled coverage into Songkick + partner	Tourbox must receive the nights	Partner listing must receive the nights	Treating the CMS as if Bandcamp could read Webflow

If the manager will only open Bandsintown, BIT is the write surface. Then Songkick is a coverage job for Bandcamp, not a second creative project. Assign who copies or syncs into Tourbox. Pretending BIT will magically appear on Bandcamp is how the Bandcamp sidebar shows last year’s rooms — or someone else’s.

How should the site read the calendar without becoming a second write?

The site’s job is proof + click: next dates, honest status, ticket or waitlist. It should not be a place someone types a date string.

Site pattern	Use when	Risk
Bandsintown widget	BIT is write	Default chrome fights the type system; still beats hard-coded dates
Bandsintown API	You need branded rows inside the design system	Cache too long in announce week
Songkick Tourbox widget	Songkick is write	Festival “pick day” is widget-only — do not assume Spotify got the Tuesday set
CMS collection as mirror	Waitlist, VIP notes, film-grade rows	Becomes a second write if managers edit CMS and BIT
Hard-coded rich text	Never, if Bandcamp or Spotify matter	Stale Buy buttons, canceled rooms still live

Homepage vs Tour page (page count is a real IA choice; see how many pages a small site actually needs):

Surface	Shows	Must not do
Homepage	Next 3 + empty state	Full routing, past dates labeled Upcoming
/tour	Full upcoming + status	A second typed calendar
EPK	Next few + link to /tour	A booker-only date list that drifts
Merch	Merch	A Shopify theme calendar that nobody updates

Merch is a different write surface. Do not hide the tour inside a product theme because the store exists. If you are choosing store vs site for commerce, that decision lives in Shopify vs a custom merch store. Tour dates still need their own reader on the artist site.

Site-as-reader checklist:

• Embed or API uses the numeric artist ID, not a display name
• Homepage display limit is 3; “all dates” goes to /tour
• Past dates are off on the Upcoming module
• Empty state is designed (email / notify), not a blank widget hole
• Managers cannot reach Designer to edit a date string
• Link-in-bio points at /tour, not a third list

If the manager must open Webflow Designer to change a Saturday, the architecture failed before Bandcamp ever loaded.

Which write surface should you pick this week?

Pick the tool the named owner will actually open. Taste does not pick. Tuesday-night holds pick.

Question	If yes	Write surface that usually wins
Who adds a date at 11:40 p.m.?	Name a human	Their dashboard
Is Bandcamp a real fan surface this cycle?	Sidebar must be true	Songkick must be accurate + ID pinned
Do you need Spotify Live Events?	Listeners should see shows in-app	A current Spotify partner listing
Is the ticketer already a Spotify partner?	Ticketmaster / AXS / DICE / etc.	Do not clone into BIT unless BIT is also the site widget
Does the site need custom rows / waitlist?	Film-grade /tour	API or CMS reader; still one write
Is this a quiet local calendar, no platforms?	Say that out loud	CMS-only is allowed — it will not fan out

Order to answer. Stop when the next question does not apply:

1. Name the owner. Their login is the write surface.
2. Bandcamp this cycle? → Songkick ID pinned; Tourbox true.
3. Spotify this cycle? → partner listing with required fields. Songkick will not do it.
4. Site custom? → reader (widget/API/CMS), never hard-code.
5. Bio still a handwritten date stack? → delete it. Point at /tour.

Owned CMS as write is honest when platforms are out of scope. The moment you promise Bandcamp and Spotify, CMS-only is a choice to not sync. Make it out loud. Do not discover it in a fan DM.

I have shipped hundreds of production sites. The tour module that survives is the one a tired manager updates from a phone without paging the designer.

How do you pin identity so the right artist fans out?

Most “wrong dates on Bandcamp” bugs are identity bugs. The feed matched a different act with the same spelling. Spotify missing nights is often a different bug: partner fields, lag, or the Songkick-shaped assumption.

Surface	Pin	Failure if you skip it
Bandcamp	Songkick Artist ID or Songkick URL in Upcoming Shows	Phantom routing (Bandcamp’s Tonga example)
Bandsintown widget	data-artist-name="id_{id}" from the /a/{id} URL	Widget shows the other “Foxtide”
Bandsintown API	artists/id_{{artist_id}}/events	Name lookup returns the wrong catalog
Songkick widget	Snippet from your Tourbox Integrations page	Leftover artist’s code
Spotify	Artist attribution on the partner event	Import attaches to the wrong profile or nowhere

Ship checklist:

• Public BIT URL and Songkick URL both resolve to this act
• No unclaimed duplicate BIT or Songkick profile with the same spelling
• Bandcamp Upcoming Shows has the ID saved, not just typed
• Spotify for Artists profile URL is the one partners should attach
• Brand doc stores both numeric IDs next to the domain DNS

Unclaimed duplicates are how an intern “fixes” a missing date by creating a second artist. Fans then see two calendars. Claim, merge, or report. Do not start a new one.

Name-match is a coin flip. IDs are the system.

What is the fan-out SOP when a date changes?

One record, updated in place. Do not create a duplicate TBA and a confirmed night and hope the readers pick the right one.

Announce-week procedure:

1. Write — create or edit the show in the source calendar only.
2. Ticket — paste the live ticket URL on that listing when it is real. Empty offer → Notify / waitlist, not last tour’s Ticketmaster URL.
3. Status — presale → on sale → sold out → canceled on that same record.
4. Site — hard-refresh homepage next-3 and /tour within 15 minutes (CDN cache is a reader bug, not a Bandcamp bug).
5. Bandcamp — if Songkick-sourced, confirm the ID once; use Bandcamp’s refresh if the sidebar lags. Do not re-enter dates.
6. Spotify — wait the documented window (24 hours, sometimes a few days). Then treat it as partner data. Wrong time/venue is fixed at the ticketer, not in Spotify for Artists.
7. Social — link to /tour or the ticket URL.

Who owns the source? Put a name in the doc. Two editors without an owner is how you get two tours.

Worked fan-out (one night, three readers) — no invented sellouts:

Minute	Write calendar	Site should show	Bandcamp should show	Spotify should show
0	Create city + date, venue TBA, no ticket URL	City — TBA; no Buy	After Songkick sync + ID pin: same night if Songkick has it	Often blank until venue + start + event name exist
45	Venue locks; ticket URL pasted; start time set	Ticket CTA live	Same event updated, not a second row	Eligible to import once partner fields exist
Next day	—	Still live	Sidebar matches Tourbox	May still be catching up — do not “fix” by typing into Spotify
Sell-out (when it happens)	Mark sold out on the same listing	Buy becomes waitlist / sold out	Sidebar should stop looking on-sale if Songkick has the state	Partner feed must carry the status; do not paste a dead Buy on /tour
Cancel	Cancel or remove upstream immediately	Event gone or canceled	Songkick/Bandcamp follow Tourbox	Partner listing updated; Spotify is not your cancel button

TBA rule: edit the same event when the room locks. Duplicate TBA + confirmed is how fans double-buy or miss the real link.

Doors vs show time stays on that listing too. A fake 8 p.m. “for the poster” is how a fan misses the set. Same rule as a fake venue.

How does this affect conversion?

It affects conversion by not lying. I will not cite a ticket-sales percentage I did not measure. Wrong dates do not convert. They support-ticket. They chargeback. They teach fans to trust Instagram over the site.

Drift	What a fan does	What you wanted
Site Buy, Instagram sold out	Click, fail, DM	Waitlist
Bandcamp shows another act’s routing	Buy a night you are not playing	Your /tour
Spotify blank for three days after announce	Listeners never see the room	Partner import, then wait
Canceled show still on /tour	Drive to a dark club	An honest empty state
Link-in-bio still last tour	Click a 404 or an old Ticketmaster	/tour

Conversion design that does not require fake math:

• One ticket URL, from the listing, on every reader that shows Buy.
• Sold-out and canceled are states, not Slack lore.
• Homepage proves there is a tour; /tour closes the click.
• Off-season empty state captures email instead of showing 2024 as Upcoming.
• Presale codes live on the listing + your list, not in a designer’s rich text.

What I will not claim: that a widget “adds X% ticket clicks,” that Spotify Live Events “sold Y tickets for this roster,” or that Bandcamp sidebar sync “pays for itself in Z merch.” Those sentences are how blog posts get untrustworthy. The measurable win is agreement: three surfaces, one night, one status, one URL.

If you need a number, count disagreements per announce week (site vs Bandcamp vs Spotify vs the write calendar). Target is zero. That is an ops metric. It is not a revenue slide.

What should you ask a designer about this?

If the designer cannot answer these, you are buying a poster, not a tour system. Ask them in the kickoff, not after launch.

Ask	Acceptable answer	Walk-away answer
Where does a manager add a date?	Named BIT / Tourbox / CMS editor	“We’ll update it for you in Designer”
What do Bandcamp and Spotify actually ingest?	Songkick vs partner ticketing, hedged	“We’ll put dates on all three”
How is artist identity pinned?	Numeric IDs in the embed and Bandcamp	Artist display name only
How does /tour update after an upstream edit?	Widget/API/CMS; cache TTL named	“Hard refresh and hope”
What happens when a room sells out?	Status field flips the CTA	Designer swaps a button
TBA venue?	Same event, updated in place; Spotify may stay blank	Two listings for one night
Empty state?	Designed module + email	Blank hole or past dates
Who owns the BIT/Tourbox login?	Shared inbox + password manager	Intern’s Gmail

Questions to put in the brief (copy them):

• Which platform is the write calendar, and who is the named owner?
• Is Bandcamp in scope this cycle? If yes, who pins the Songkick ID?
• Is Spotify Live Events in scope? If yes, which current partner listing feeds it?
• Homepage next-3 limit, /tour full list, EPK link — three readers, one record
• Sold-out, waitlist, canceled, TBA — show me the component states
• Cache TTL during announce week
• What the designer is forbidden to type (date strings)

If they propose hard-coding the routing in Figma “so it matches the film,” they have optimized the screenshot and abandoned Tuesday. Film-grade type can wrap an API row. It cannot replace the calendar.

When is a custom site worth it for this?

A custom site is worth it when the reader has to do jobs the default widget cannot: waitlist, VIP packages, film-grade rows, EPK-grade routing notes, region-specific landing pages. It is not worth it as a place to type dates that Bandcamp and Spotify will ignore.

Need	Custom site earns its keep	Template / widget is enough
Bandcamp + Spotify agreement	Site as a branded reader of the write calendar	You still need Songkick + a Spotify partner regardless of the theme
Waitlist / VIP / support-slot notes	CMS or API fields the widget cannot hold	Club dates with a clean BIT/Tourbox widget
Identity pinning + empty states	You will actually build them	You will not log in after launch
Merch + tour on one domain	Tour reader on the artist site; store stays commerce	Do not stuff dates into the cart theme
No platforms, local calendar only	Maybe — CMS-only is honest	Then do not promise Bandcamp/Spotify

Custom is a display and capture decision. Sync is a feed decision. Paying for cinema does not make Songkick appear on Spotify.

Skip custom-for-dates when:

• Nobody on the team will own BIT or Tourbox
• You will not pin IDs
• You want the designer to be the CMS
• The “tour page” is one screenshot for a pitch deck

If the site is custom, cap the tour collection: start (timezone explicit), city, venue (TBA allowed), ticket URL (optional), status, one-line note. Editor seat, not Designer. The person who updates dates on Tuesday should not be able to break the fold.

What usually fails first across the three surfaces?

The first failure is almost never “the API is down.” It is a second write surface wearing a helpful attitude.

Failure	How it shows up	Cost	Do this instead
Three typed calendars	Site, Bandcamp, Stories disagree by one city	Angry DMs; bookers screenshot the wrong night	One write; readers only
Name-match Bandcamp	Wrong act in the sidebar	You are advertising someone else’s routing	Pin Songkick ID
Songkick assumed for Spotify	Spotify blank after announce	Team “fixes” it by inventing a fourth list	Partner listing + wait the documented window
TBA duplicated	Two rows for one night	Double-buy or missed URL	Update in place
Hard-coded /tour	Canceled show still Buy	Embarrassment in public	Widget/API/CMS status
Cache days-long	Site stale, BIT correct	Manager thinks BIT “didn’t save”	Minutes in announce week
Intern’s BIT login	Owner leaves mid-tour	Nobody can edit	Shared inbox, 2FA in the password manager
Link-in-bio calendar	Fourth list	Guaranteed drift	/tour only

Hard-code audit (run it on any artist site you inherit):

• Are dates in a collection / widget, or in a rich-text block?
• Change one listing upstream. Does /tour move without a designer?
• Sold-out a room in BIT/Tourbox. Did the CTA change?
• Is Bandcamp pinned to the Songkick ID, or hoping on the name?
• Is Spotify waiting on a partner listing, or on a wish?

If any box fails, you do not have three-surface sync. You have a brochure plus two platforms doing their own thing.

Login handoff fails second. Manager leaves. BIT lives on a personal Gmail. Announce week becomes a recovery ticket. Shared studio or management inbox. Recovery codes next to DNS. Offboard before the next routing drop.

How do you measure whether the sync is working?

Measure agreement, lag, and identity — not a story about ticket lift. Open all three surfaces on the same night and score them.

Check	Pass	Fail
Write calendar vs /tour	Same city, venue, status, URL	Any field disagrees
Bandcamp vs Songkick	Same nights after ID pin + refresh	Other act, missing night, leftover cancel
Spotify vs partner listing	Present after the documented window or still inside it	Blank after several days and Songkick was the only write
Homepage next-3	Matches the soonest three in the write calendar	Past date, TBA duplicate, wrong order
Identity	IDs in the brand doc match live embeds	Display-name widgets
Bio	Points at /tour	Handwritten dates

Ops scoreboard (count these; they are real):

1. Disagreements per announce week (target: 0).
2. Time from write → site visible (should be minutes, cache permitting).
3. Time from qualifying partner listing → Spotify visible (vendor says ~24 hours, sometimes a few days — log it, do not promise “instant”).
4. Bandcamp ID pin: done once per artist, re-verified per tour cycle.
5. Designer tickets to “change a date” (target: 0).

What “working” is not: a screenshot of Spotify Live Events on a good day. Partnerships move. Re-verify the Spotify partner list and the Bandcamp↔Songkick pin at the start of every major cycle. Do not trust a setup from two albums ago.

Night-of audit (print it, walk the three URLs):

• Write calendar: city, venue or TBA, start with timezone, status, ticket URL or empty
• / next-3 includes this night if it is among the soonest three
• /tour matches the write record (not a richer-text leftover)
• Bandcamp sidebar: this night, this act, after ID pin
• Spotify: present, still inside the lag window, or missing with a partner-field reason written down
• Bio: /tour or ticket URL — zero handwritten dates

If Spotify is still blank after the documented window, send Spotify the partner event URL and the artist profile. Do not type the routing into a fourth tool. If Bandcamp is wrong, the ID field is the first check, not the Tour page redesign.

What should you skip if you only have a week — and when is this not worth doing yet?

A week is enough to stop the bleeding. It is not enough to build a custom API tour module and a waitlist product.

Week-one, in order:

1. Name the owner and the write calendar.
2. Pin Bandcamp → Songkick ID. Save.
3. Confirm Spotify’s path: existing ticketer on the partner list, or BIT (or another current partner) if they are not.
4. Replace hard-coded site dates with the matching widget (ID form, display limit on the homepage).
5. Delete the link-in-bio date list. Point at /tour.
6. Write the sold-out / canceled / TBA rule in one paragraph the team can screenshot.

Skip in a week:

Skip	Why
Custom API rebuild	Widget with an ID beats a half-finished fetch
Event JSON-LD chase	Google wants leaf URLs; a correct /tour widget is the week-one win
Dual BIT and Songkick as two creative calendars	You will type twice and drift
Festival Wikipedia → CMS	Saturday becomes Friday
“We’ll also update Instagram first” as policy	Social is a reader

Not worth doing yet:

• You have no named owner. Tools without an owner become two calendars.
• You have zero upcoming dates and no announce on the horizon. Pin IDs anyway if the profiles exist; do not build a tour design system for an empty year.
• Bandcamp is unused and Spotify Live Events are out of scope. Then this is a site calendar problem only — still one write, but do not pretend the other two will follow.
• The only “site” is a Linktree. Buy a /tour or accept that platforms are the site.
• You refuse to use Songkick and you need Bandcamp. Those two sentences cannot both be true as of Bandcamp’s current help.

If two people still insist on updating Instagram first, the site will lose. Post the graphic after the event exists in the write calendar, not before.

Re-read Bandcamp’s upcoming-shows article and Spotify’s adding-concerts article when you start the next cycle. I hedged the ingest on purpose. The pipes are the product. The theme is not.

FAQ

How do I manage tour dates across Bandcamp, Spotify, and my site?

Write dates in one calendar — Bandsintown, Songkick Tourbox, or an owned CMS — then let the site, Bandcamp, and Spotify read. Bandcamp ingests Songkick (pin the Artist ID). Spotify imports ticketing partners and does not display Songkick. The site should embed or query the write calendar, not store a second typed tour.

How do I measure whether tour-date sync across Bandcamp, Spotify, and my site is working?

Score agreement: write calendar vs /tour vs Bandcamp vs Spotify for the same night — city, venue, status, ticket URL. Count disagreements per announce week (target zero) and log Spotify’s import lag against the documented 24-hour-to-few-days window. Do not use invented ticket-sale percentages as the metric.

What usually fails first when teams try this?

A second write surface: hard-coded site dates, a Bandcamp name-match with no Songkick ID, or the assumption that Songkick will appear on Spotify. Identity collisions on Bandcamp and partner-field gaps on Spotify show up next. Duplicate TBA + confirmed listings for one night are how fans get the wrong URL.

How long does this take to show results?

The site should move in minutes if the embed or API is the reader and cache is short. Bandcamp follows Tourbox after the ID is pinned (refresh if the sidebar lags). Spotify’s own missing-concerts help says listings should appear within 24 hours of a partner listing and can take a few days. After that, treat it as partner data, not a redesign problem.

What should I skip if I only have a week?

Skip the custom API rebuild, schema theater, and a second handwritten calendar. Name an owner, pin the Songkick ID on Bandcamp, confirm a current Spotify partner path, replace hard-coded site dates with the matching widget, and point the bio at /tour. Widget-plus-IDs beats a half-finished tour app.

When is this not worth doing yet?

When nobody owns the login, there is no announce on the horizon, or you want Bandcamp without Songkick. CMS-only is fine if you are willing to skip Bandcamp and Spotify out loud. A Linktree date list is not a fan-out. Instagram-first as policy means the site will always lose.

CTA

One calendar. Two ingest pipes. Three surfaces that agree.

Explore /websites or book a Website sprint at /contact?intent=websites-sprint.