Every capability, and where each one stands.

Your marketing data belongs in your own analytics property. Accounts supply their own measurement IDs and the tags load on the platform their artists use — with the privacy rules enforced on our side rather than trusted to a pasted snippet.

• Per-account GA4, Meta Pixel and Tag Manager IDs, plus site-verification tags
• Saved in the console and live for artists immediately — no redeploy
• IDs only, never pasted scripts, so a strict content-security policy can stay strict
• Query strings stripped before any address is reported — reset tokens can never leak into analytics
• Nothing identifying is ever sent: no artist ID, no email, not even a hashed one

The two things that decide whether a branded platform reads as yours or as a rebadge. The artist-facing application is deployed per account on your own domain rather than served from a path under ours, and outbound mail is authenticated to send from your address — which is a DNS and deliverability exercise, not a from-header swap, and is the part that quietly fails elsewhere.

• A separate deployment per account on your own domain, so your platform's availability is yours
• TLS and DNS handled as part of onboarding rather than left as your homework
• Mail sent from your address with SPF, DKIM and DMARC aligned so it reaches inboxes
• Every artist-facing template written so it never mentions anyone but you — with a test enforcing it
• Password resets, release notices and payout mail all in your name

The platform your artists sign in to carries your identity, top to bottom. Not a logo swap on someone else's product: your domain, your palette, your sender address, your analytics, and copy that never mentions anyone but you.

• Your own domain, with the artist-facing application deployed per account
• Your logo, palette and typography applied across every artist-facing screen
• Email sent from your address, in your name — the artist-facing templates never mention us
• Your own analytics and verification tags, configured by you
• A separately deployed front end per account, so your platform's availability is yours

Artists sign in on your domain under your branding, with an emailed one-time code as a second step where you require it. Sessions are short-lived and rotate, a reused refresh token ends the whole session family, and every sign-in is audited.

• Password sign-in with an emailed one-time code as a second factor
• Short-lived sessions that rotate; a reused refresh token revokes the whole family
• Sign-ins, logouts and revocations audited per artist
• Sessions scoped to one account and one end user
• Rate limiting keyed on the real client address, behind the proxy
• Sign-in, reset and notification email in your branding
• Owner and member roles inside each account, with the last owner protected

For accounts that deliver through a distributor of their own rather than ours. Once you approve a release, a delivery agent recreates it on your distributor, searches for its own reference before creating anything so nothing is entered twice, and locks the release while it works so nobody edits what is being typed.

• Opt-in per account, with your distributor login held encrypted
• A lease per release — one agent at a time, released if it stalls
• A reference written into every release, searched for before anything is created
• The release locked while delivery is in progress, for every role
• Releases that fail three times handed to a person, never retried forever
• You mark it live once your distributor confirms

Your artists pay you, not us, on the payment accounts you already hold. Plans, add-on labels and one-off fees are charged on your gateway, and a plan change ends the old subscription at the gateway too — so nobody keeps being charged for a plan they left.

• Your own card and UPI merchant accounts, gross amounts with your own tax
• Plans with included labels; extra labels charged once or on the subscription
• Plan changes that take effect now or at the next renewal
• A cancelled plan cancelled at the gateway as well as on the platform
• Payments the browser never confirmed recovered by a sweep

Switch it on and your artists can no longer create labels themselves — they ask, and your team decides. Approval comes before payment, so a rejection never needs a refund, and the label is created only when the request is paid for or approved free.

• Off by default, switched on per account
• Approve, then pay — nothing is charged before a decision
• A default price, editable per request, paid on your own gateway or marked paid by your team
• Artists told of the decision in your name

Run the platform end to end with test artists before your real roster arrives — releases, review, statements — and clear every trace of the rehearsal in one step when you go live.

• Test artists created alongside real ones, kept out of billing
• A trial period for the account itself
• One-step purge of everything the rehearsal created

Your team learns the console in the console: guides for each procedure, kept next to the screens they describe rather than in a document nobody can find.

• Guides for each procedure, in the console
• Written for your team's console, not ours
• Guided tours on the screens where people get stuck

Your artists follow their releases, read their statements, withdraw what they are owed and reach support from their phone. Every request is signed by the device, and the app never takes a payment.

• Releases, statements, withdrawals and support tickets
• Every request signed by the device it came from
• Approved accounts only — applicants follow their application on the web
• No payments in the app — money only ever goes out, as withdrawals

Today the hierarchy is your account, the clients inside it, and the labels beneath each client — which is the right shape for a distributor serving artists and labels directly. It is not the right shape for a distributor whose own clients resell to others, and that third tier, with its own branding, permissions and audit trail per level, is the next structural change to the account model.

• Today: your account → your clients → their labels, with hard isolation at the account boundary
• Planned: a further tier so a client can administer clients of their own
• Per-tier branding, so a sub-distributor's artists see the sub-distributor
• Permissions and audit trails that resolve at the right level rather than flattening
• Approval flows that can require a parent's sign-off before delivery
• Earnings routed all the way down automatically — most platforms pay the parent and leave the parent to pay its clients by hand

The system of record. Releases and tracks carry the complete contributor and composer graph rather than a flat text field, so a credit is an entity you can query, correct once, and deliver consistently to every store.

• Releases, tracks, contributors, composers and recording versions as first-class records
• 193 metadata languages and 429 genre styles, held as stable lookups rather than free text
• ISRC, UPC/EAN, label, P-line and C-line, territory rules and sale dates
• Roles and role groups, primary versus featured, ordered credits per release and per track
• Corrections propagate — fix an artist once, every release carrying that credit follows
• An artist de-duplication tool for the near-identical roster entries every migrated catalogue arrives with
• A per-release status timeline, so "where is it" is a screen rather than a support ticket

The upload surface your artists actually touch. Release, Tracks and Distribution as three tabs over one record, saving as they type, with a live validation panel beside them. Submission unlocks only on a clean report — so a release does not reach your queue, or a store, in a state someone has to send back.

• Three tabs over one release — Release, Tracks, Distribution — with the tab held in the URL, so a reload or a Back lands where you were
• Autosave with a visible save state; nothing is lost to a closed laptop
• A validation panel listing every finding as blocking or advisory, and clicking one jumps to the exact field that raised it
• Submit is gated on a clean report rather than accepting the release and rejecting it later
• Contributor and composer pickers with roles, ordering and publishing shares — not free-text credit fields
• Artwork and per-track audio uploaded straight to storage, with metadata read from the file itself
• Per-track monetisation policy and distribution settings on their own tab

Delivery orchestration with a per-account store catalogue on top. The reach is a function of the relationships you hold, not of the software: through aggregator and partner routes the addressable network runs past 400 platforms and sub-platforms, and the delivery layer is built to target any endpoint you have a deal with. Every client sees only the destinations you enabled for them.

• 400+ platforms and sub-platforms addressable through aggregator and partner routes
• Not bounded by one contract — deliver through your supply agreement, your partner's, or ours
• New destinations added as endpoints rather than as engineering projects
• Spotify, Apple Music, YouTube Music, Amazon, Deezer, TikTok, Tidal, JioSaavn, Boomplay, Anghami and more
• Per-account store catalogue — enable or disable destinations for each client
• Takedowns, redeliveries and per-store status tracked as release events
• Content ID and rights-management destinations handled alongside the audio stores

The delivery relationship and the software that drives it need not come from the same company, as every credible platform in this category now says. Here it is not a higher plan tier or a short endpoint allowlist, and the API you would automate it with is public. Where your upstream partner exposes an API, the whole system is built on it — artist dashboards, admin console, catalogue, analytics, royalties, payouts and support.

• Bring your own distribution agreement — your contract, your rates, your relationship
• Not a premium add-on and not a single-endpoint allowlist: every destination you hold a deal for
• Delivery orchestrated through your upstream partner rather than replacing it
• Where that partner exposes an API, the whole platform is built on it end to end
• Artist-facing dashboards, admin console, analytics and royalty reporting on your supply chain
• Or use ours — the same platform, with wavbee's own delivery relationships behind it
• The choice is commercial, not technical: nothing in the software assumes one answer

Where delivery runs through an upstream partner's API, a release is sent the moment it reaches your review — so the partner's own checks run while you review — and held there until you approve it. Approval releases exactly what was reviewed: if anything changed in between, it is withdrawn and re-sent first. Rejected releases are withdrawn and kept, so a corrected resubmission comes back under the same record.

• Sent at review, held at the partner, released only by your approval
• A content fingerprint proves the approved release is the one being released
• Codes the partner assigns — barcode and ISRCs — are read back into your catalogue
• Per-store status read back on a schedule, so the timeline shows what the stores did
• Separate sandbox and production connections per account, never mixed
• Existing artist accounts at the partner linked by exact email, never duplicated

If you hold an ISRC registrant code or a GS1 barcode range, codes are allocated from it at the right moment in the release's life — and a code the uploader supplied is never replaced. Without a range, the release goes out blank and the codes assigned downstream are copied back.

• ISRCs from your registrant range; barcodes from your GS1 prefix, 12 or 13 digits
• The GS1 check digit computed, the item width derived from the prefix
• One allocation per release, recorded, never reused
• Supplied codes kept as supplied

Quality control that exists now, rather than the automated engine described on the QC page. Releases arrive pre-validated by the builder, land in a review queue, and are approved, returned with a reason, or held. The automated checks being built plug into this queue rather than replacing it — the queue is where anything a machine should not decide alone ends up either way.

• Pre-submit validation in the builder, so most problems never reach the queue
• Findings carry a severity — blocking or advisory — rather than one undifferentiated list
• Approve, return with a reason, or hold, with the whole exchange recorded on the release
• Returned releases come back with the specific field named, drawn from a structured reason catalogue
• A hold with a reason that pauses the queue clock and is invisible to the uploader
• Audio recognition on every track beside the release — approval waits until each one is scanned
• Changes after go-live arrive as edit requests and are reviewed, never written straight through
• The queue the automated checks feed into, so adopting them changes the volume, not the workflow

For distributors whose labels, or whose sub-labels, want a say before anything goes out. A release submitted by an artist goes to their label's own review desk first — approve, reject, or ask for changes — and only an approved release reaches yours. Nothing is delivered on the first approval alone.

• Two review stages, each with approve, reject and request-changes
• The label's decision and reasons travel with the release to the second stage
• Switched on per account, so labels that want no desk of their own are not given one
• The same queue, reasons and audit trail at both stages

A release that is being reviewed or delivered cannot change under the reviewer, and a live release is never edited in place. Each state decides who may change what, and the answer is enforced on the server rather than hidden by a button.

• Drafts edited freely and deletable until first submitted
• Locked in review and in delivery, for every role including the reviewer
• After go-live, changes arrive as edit requests and go back through review
• A release date or as soon as possible — never neither, so a blank date is never a silent choice
• Every transition recorded on the release's own timeline

A takedown is a request with a stage, not a button. An artist asks, their label decides, then the distributor — and a self-distributing label's approval is the last word. Whole catalogues can be taken down in one decision, and distribution can be switched off for an account without closing it.

• Takedown requests decided in order — label first, then distributor
• Whole-catalogue takedowns: live releases taken down, in-flight ones taken down on arrival, drafts untouched
• Distribution off stops new releases and keeps the account, its statements and its payouts
• Taking the catalogue down is a separate choice from switching distribution off
• Artists told of every decision in your name

Who owns what, who wrote what, and on what evidence — held against the release and track rather than in a spreadsheet somebody has to remember to update.

• Per-release and per-track ownership with an account boundary enforced in the database
• Contributor roles and role groups aligned to the standards stores expect
• Writer and publisher shares captured at track level and delivered with the release
• Monetisation policy per track and per destination
• Every change written to an audit trail with the actor and the timestamp

Statements arrive in as many shapes as there are reporting parties — your distributor's, a third party's, your own. Every one is normalised into one table, attributed to the recording it belongs to, and pushed out as per-artist statements, earnings views and API data. Imports are additive: a late or supplementary report adds to a month rather than overwriting it, and nothing is ever counted twice.

• One normalised store for both major reporting patterns — per-transaction and per-summary
• A byte-identical file is refused outright; a second file for a month already imported is asked about, with the overlap shown first
• Overlap counted row by row on one definition of a row, so “identical data” adds only what is new
• Your own and third-party reports imported alongside your distributor's, never mixed with them
• Attribution to ISRC, release, artist and account, then per-artist statements published from the same rows
• An import can be withdrawn while nothing built from it is final; after that a correction is an adjustment
• Replacing an import is restricted, needs a reason and is audited

Statements that have been signed off stay exactly as they were signed off. When a supplementary report lands for a closed month, the difference is carried forward — once for the label's payout and once for each affected artist, at that month's own rates — and the next month cannot close until someone has acknowledged it.

• Closed months never rewritten — differences carried, not edited in
• Calculated with the original month's rules, so an unchanged month carries exactly nothing
• Each artist's correction goes to whoever owned the release in that month
• A month cannot be finalised until its carried adjustments are acknowledged
• A negative balance carried against later earnings, never silently dropped

Earnings become payments without anyone maintaining a parallel spreadsheet. A monthly run picks up every account whose latest statement clears the threshold, and the amount actually paid is recorded in the account's own currency.

• Monthly automatic payout run driven by the latest settled statement, with a ticket trail
• Bank details held encrypted per end user, with a payout minimum you set
• Manual payout requests alongside the automatic run
• Balances stay right after a month closes — late corrections arrive as adjustments, never rewrites
• Multi-currency — the paid amount is recorded in the currency it was paid in
• A permanent payout log, queryable per account and per period

Reporting built on the ingested statements rather than on a separate analytics product, so the number an artist sees and the number you pay out are the same number from the same row.

• Trend charts over revenue and performance by release, track, artist and account
• Ranked lists — top releases, top tracks, top territories, top stores for a period
• An explorer for slicing the same data by dimension rather than only reading fixed reports
• Per-end-user analytics surfaced inside the account holder's own console, not only yours
• A per-account analytics switch, independent of anyone else's reporting
• Drill-down to the individual statement line behind any figure
• Exportable for finance, with the underlying royalty rows still addressable

Every account is a hard boundary. Isolation is enforced in the query layer and asserted by a scoping matrix in the test suite, because 'we scope by account everywhere' is a claim that needs a machine checking it, not a convention.

• Account-scoped everything — catalogue, users, statements, tickets, assets
• Owners, and team members granted any of nine scoped capabilities — a section without one is absent, not read-only
• Fields filtered on the server where a screen mixes domains, so finance data never reaches a catalogue-only seat
• Per-account switches granted centrally — QC, escalation, store management, royalty import, analytics, API access and docs
• Cross-account isolation asserted by an automated scoping matrix, not by convention
• Impersonation for support behind its own grant, with a visible banner and a full audit record

The money layer, including the parts nobody demos. Currency is derived from the account's country rather than trusted from the client, mandates are never charged before the account is approved, and every redirect flow is confirmed server-side.

• Three gateways — cards, UPI and wallet rails — behind one interface
• Subscription and one-off pay-per-use charges on the same billing stack
• Approval-gated mandates: nothing bills before an account is accepted
• GST tax invoices in their own numbered series, with credit and debit notes for corrections
• Returns built from the issued documents rather than from a payments export
• Reconciliation sweeps recover any payment whose browser callback never arrived

A distribution platform is a support business wearing a technology coat. This is a full desk — inbound email parsed and threaded on message identity, shared and personal mailboxes, SLA clocks that stop and start with status.

• Inbound email threaded on Message-ID and reference code, never on subject resemblance alone
• Shared team mailboxes and personal mailboxes with per-member roles
• Kanban queue with statuses, internal notes, and a public reply visible to the requester
• SLA timers that pause and stop with ticket status
• Live chat and calls with wavbee's team from inside the dashboard, with the agent seeing the page you are on
• Spam learning, suppression filters, a knowledge base and dynamic intake forms

Masters, artwork and documents held in object storage behind signed, expiring URLs, with large uploads going straight from the browser to the bucket so a big master never has to squeeze through the application.

• Private bucket for masters, artwork, attachments and documents
• Signed, expiring delivery URLs — no public object is ever the default
• Direct-to-storage presigned uploads for large files
• A separate public bucket for the assets that are genuinely public
• Provider-agnostic — the storage layer is configuration, not code

Moving a live catalogue is the single biggest reason a label stays on a platform it has outgrown. A release is identified by its barcode and a recording by its ISRC, and by nothing else — two labels can both release “Greatest Hits”. The import scans first and writes nothing; a person reads the report, then applies it.

• Barcode and ISRC matching, normalised first, so an export written with dashes is not a new catalogue
• Three verdicts per line — already here, ready to create, or unresolved with the reason named
• Scan and apply are separate steps; the report a person approved is exactly what is written
• One transaction per release, so one bad date never rolls back a nine-hundred-release migration
• Imported releases land as drafts — history, not new work in the review queue
• A catalogue already held by an upstream partner can be read across and linked, not re-uploaded
• Historical statement import so earnings history survives the move

The publishing side of a recording, held as records rather than a credits field: who wrote it, in what shares, which publisher and administrator act for them, and which society they belong to — validated in the builder and delivered with the release to every store that takes it.

• Writer shares per track, with composer and lyricist roles checked before submit
• ISWC, publisher, administrator, mechanical society and registration id per share
• Publisher records with IPI number and society, set up and audited centrally
• Writers with ISNI, mergeable when a migrated catalogue arrives with duplicates
• Self-published writers handled explicitly, never left as a blank

The rest of the publishing picture. Writer and publisher metadata already travels with every track; the work behind it — its own owners, registrations and money — is the next major expansion. It is partner-plural by design: publishing routes through whichever administrators and societies the client already works with, not through one we picked for them.

• Works as records in their own right, linked to the recordings that embody them
• Writer and publisher splits with controlled-composition handling
• Society and CMO registration workflows, through whichever partner the client works with
• Mechanical and performance royalty ingestion alongside the recording pipeline
• One statement view across recording and publishing income

Today a release's earnings go to the account that owns it. Splits divide a track's earnings between the people who made it, each paid into their own balance from the same statement line, without the owner re-distributing by hand.

• Shares per track, per collaborator, adding to one hundred percent
• Collaborators paid from the same statement line, into their own balance
• Invitations for collaborators who do not have an account yet

Moving a large catalogue is a project, not an upload. We run it with you: your export prepared against our templates, every line matched on barcode and ISRC, the report read together before anything is applied, and duplicates in the roster merged rather than carried across. A catalogue already held by your current partner can be read across directly instead.

• Templates for your export, and a person on our side who has done this before
• Barcode and ISRC matching with every unresolved line named, never guessed
• Duplicate artists and writers merged before go-live, not after
• Historical statements imported so earnings history comes with the catalogue
• Releases land as drafts — your live catalogue never re-enters a review queue as new work

Catalogues decay: a credit spelled three ways, a missing ISRC, a writer share that no longer adds up. Our team corrects and maintains release, track, credit and publishing metadata on your behalf, reviews change requests after go-live, and sets up publisher records so writer shares deliver properly.

• Release, track and credit corrections made by our team, recorded on each release
• Writer shares, publishers, IPI numbers and societies set up and maintained
• Post-release edit requests reviewed before they reach a store
• Roster hygiene — artist names, merges and name-change requests handled

The daily operation of a distribution desk: every release reviewed against your standards and the stores', audio recognition results read by a person, deliveries followed until the stores confirm, and takedown requests decided and carried out.

• Release review with reasons your uploaders can act on
• Audio recognition findings read and decided by a person
• Delivery followed through to store confirmation
• Takedown requests and whole-catalogue takedowns carried out

Royalty season stops being a fortnight of spreadsheets. We import every report you receive — your distributor's, third parties', your own — reconcile the months, publish per-artist statements, carry late corrections as adjustments, raise the invoices and run the payouts.

• Reports in any shape imported additively, overlaps checked before anything lands
• Months reconciled and finalised, corrections carried rather than rewritten
• Per-artist statements published from the same rows your totals come from
• Payouts run and recorded, with a ticket trail for every one

A support desk staffed by people who know the platform because they run it. Email arrives in a mailbox in your name and is threaded into tickets; inside the platform, your artists and your team reach a person by chat or by call from the page they are stuck on, and the person answering sees that page.

• Tickets and email in a mailbox in your name, threaded on message identity
• In-platform chat and calls, switched on per account
• The agent sees the page and the unsaved form the person is asking about
• Anything unanswered becomes a ticket rather than a missed message

Some catalogue owners need nothing artist-facing; others want their artists to see their own releases and earnings. When you do, the same branded application our platform clients run is deployed for you, on your domain, with our team behind it.

• Releases, statements, earnings and payout requests for each artist
• Your domain, logo and sender address
• Optional — the managed service works without it

Large catalogues are rarely standard. Where you need an integration with your own systems, a report your finance team already uses, or a workflow the platform does not have, we build it into the platform rather than beside it — so it is tested, deployed and maintained like everything else.

• Integrations with your own systems through the documented API, or built by us
• Reports and exports in the shape your finance team already uses
• Workflows added to the platform, not bolted on beside it
• Built, tested and maintained by the same team that runs the platform

The check that protects you from delivering something you do not have the right to deliver. Each track is scanned by audio recognition, and the findings sit on the review screen and on the uploader's own track rows. Approval waits until every track has been scanned.

• Matches, covers and remixes, each with where it plays, its ISRC, its rights holder and its store links
• A match against the artist's own earlier release marked as theirs, not flagged as a problem
• AI-generated audio detected, with the generator named where the engine reports it
• Reported as evidence for a reviewer, never as an automatic refusal
• Approval refused until every track in the release has its result

Deterministic rules run first and cost nothing. Titles, versions, casing, featuring conventions, explicit flags, language and script consistency, identifier validity — checked against a published catalogue rather than a reviewer's memory.

• A 112-rule catalogue drawn from the store style guides that actually reject releases
• The Apple Music Style Guide as the worldwide baseline, with per-store profiles on top
• Per-account overrides — your standards can be stricter than the baseline, never looser than the store's
• Severity per rule, so a warning does not block what a failure should
• Deterministic checks run before anything expensive is called

Resolution and format are the easy half. The half that gets releases rejected is the content — social handles, store logos, URLs, explicit imagery, a face that belongs to somebody else. Those need to be looked at.

• Dimensions, colour space, format and compression against store specifications
• Text and logo detection — URLs, social handles and store marks that stores reject
• Explicit-content classification with a review path rather than an automatic refusal
• Likeness and impersonation signals routed to a human
• Every verdict carries the evidence that produced it

One analysis pass over the master produces every measurement the checks need. The defects that get a release taken down after delivery are exactly the ones that are cheap to catch before it.

• Leading and trailing silence measured against a published threshold
• Clipping, true-peak and integrated loudness
• Dropouts, digital silence mid-track and channel anomalies
• Fake hi-res detection — spectral analysis against the declared sample rate
• Browser-side pre-checks so the obvious problems never reach the queue

The difference between quality control and rejection. When something is ambiguous rather than wrong, the run asks — in the upload session, in plain language, with a proposed correction the uploader can accept in one click.

• Questions raised during the upload, not in a rejection email three days later
• Each question carries a proposed patch to the metadata
• Accepting a patch re-runs only the checks it affects
• Unanswered questions hold the release rather than failing it
• Every question and answer is part of the release's permanent record

A verdict is a decision with its reasoning attached. Clean releases are approved automatically with the full evidence recorded; everything else routes to the right queue, so human review is spent on the cases that need a human.

• Five outcomes: pass, pass with warnings, needs clarification, manual review, fail
• Per-rule evidence rows — what was checked, what was found, what it cost
• Automatic approval for clean releases, with the audit trail to defend it later
• Manual review routed by reason, not dumped in one queue
• A published turnaround target for the fast lane

Quality control is useful to every distributor, not only to the one that owns the catalogue. The engine is being built as a standalone service from the first commit so it can be consumed over an API by platforms that will never use anything else here.

• REST submission with idempotency keys and retrying signed webhooks
• DDEX input accepted alongside a native payload
• A sandbox that returns realistic verdicts without consuming metering
• Per-tenant rule profiles and thresholds
• Metered per release, with the cost ledger visible to the tenant

The builder as a component another platform can embed — their branding, their session, their users, with the checks and the clarification loop running live as the release is assembled.

• Embeddable component with short-lived session tokens
• Checks run live as fields are filled, not on submit
• The clarification loop rendered inside the host product
• Uploads go directly to storage from the visitor's browser
• Host-controlled styling

The analysis that powers the defect checks also describes the music. Exposed to artists and labels, that becomes a product of its own: what this track is, and how it sits against the catalogue around it.

• BPM, key and scale
• Danceability, energy and mood descriptors
• Hook and chorus timestamps for clip selection
• Comparative percentiles against a reference catalogue
• Available to the artist, not only to the reviewer

A complete cover-art tool, not a filter. Generate from a prompt, or start from an upload or a template, then lay out typography and export at the specification stores actually accept — without leaving the release you are building.

• AI cover-art generation from a prompt, with the artist's own uploads as an alternative start
• A real editor — layers, typography, colour, alignment, backgrounds
• Templates and a per-account library that persists between releases
• Exports at store-ready dimensions and colour space
• Ships as a self-contained package, so it can be embedded rather than rebuilt

Lyrics are metadata the stores display and listeners search, and most catalogues have none. The studio opens beside each track in the release editor: transcribe the master automatically, correct it, and time every line against the audio — without a separate tool or a file passed around by email.

• Automatic transcription from the master, returned already timed line by line
• Tap-along syncing against a zoomable waveform, with fine adjustment per line
• A romanized version alongside the original for lyrics in non-Latin scripts
• A preview that plays the track with the lines lighting up as they are sung
• Every change keeps the version before it, and a person's own timing is never overwritten unasked
• In the release editor your team and your reviewers already use

One link that knows where the listener is and sends them to the right store, before release as a pre-save and after release as a landing page. Built into the release rather than bolted on, so the link exists the moment the release does.

• One smart link per release, routing each visitor to the store they actually use
• Pre-save and pre-add campaigns that convert to a play on release day
• Artist bio pages collecting every release, social profile and link in one place
• Short lnkb.ee links for bios and captions, full lnkbee.com pages for campaigns
• Click, destination and territory analytics reported back into the release's own dashboard
• Created automatically with the release — no separate tool, no separate login

Editorial pitching fails on timing and on thin information. The intake form enforces the lead time and asks for the material a pitch actually needs, and the draft comes back written the way editors expect to read it.

• Structured intake capturing lyrics, story, influences, audience and promotion plan
• Release-date-aware deadline enforcement built into the form
• A drafted editorial pitch and press-release copy returned to the artist
• Tracked as a ticket, so nothing is lost between the form and the answer
• Honest framing throughout — pitching improves odds and never guarantees a placement

Video generation attached to the release rather than bolted on beside it. Promotional videos for social, animated cover artwork, vertical loops for the streaming players that support them, and lyric videos — each produced from assets the release already has. The rendering is handled by production partners we integrate with, so the artist never leaves your platform and you carry no render infrastructure of your own.

• Promotional videos for social and streaming placement
• Motion artwork — the cover animated, with no master required at all
• Vertical loop formats for the players that support them
• Lyric videos generated from the track's own lyrics and artwork
• Rendering is delivered through production partners — you integrate once, not per vendor
• Every format is switchable, so you offer exactly the set you want to support
• Media goes from the browser straight to the render pipeline — nothing is proxied or stored in between

Every release needs the same set of assets and every artist makes them by hand. The system already holds the artwork, the title, the artist, the release date and the smart link — so it generates the set, in the right sizes, ready to post.

• Square posts, vertical stories and reel covers generated from the release's own artwork
• Announcement, pre-save, release-day and out-now variants as one pack
• Correct dimensions and safe areas for Instagram and Facebook
• Caption and hashtag drafts with the smart link already inserted
• Downloadable as a pack, or scheduled directly to a connected page

Editorial placement cannot be bought and should not be faked. An owned network of precisely-named playlists that grow through search relevance is the version of this that is durable — and the roster is placed into it on identifiers, not names.

• An owned playlist network grown through search relevance, not purchased followers
• ISRC-first roster placement, held pending until the track is genuinely live
• Outcome measured against royalty statements, not against follower counts
• Organic-only by policy — the manipulation rules bill the distributor, not the artist
• Scheduled, guardrailed placement rather than ad-hoc additions

Everything the console does, the API does, specified in OpenAPI. The specification is a build gate — an endpoint added without documentation fails the test suite — so the reference cannot drift from the implementation. It is also public, where most platforms in this category issue theirs under an account, so you can evaluate it before any sales process.

• Releases, tracks, contributors, composers, artists, labels, stores, statements and tickets
• An OpenAPI specification that the test suite enforces against the routing table
• Consistent pagination, filtering and error shapes across every resource
• Readable before you talk to anyone — not issued under an account after a sales call
• Nested resources where the domain is nested — a track's contributors live under the track
• An Idempotency-Key on every retryable create: a retried request replays the stored answer for 24 hours instead of duplicating

Your servers and your artists are not the same caller and should not share a credential. Machine keys are issued per account and can be refused centrally; end-user tokens are how an artist's own session reaches the API, and are untouched by that.

• Per-account machine keys, mintable by the account owner
• Separate short-lived tokens for end-user sessions
• A central per-account switch that refuses machine keys without revoking anything
• Scoped access — every request resolves to exactly one account
• Full request auditing per key

For teams that extend their own artist application: the endpoints it calls, with guides, drawn from the same specification as the public reference, so the two cannot disagree.

• Drawn from the one OpenAPI specification — a guide naming a missing endpoint fails the build
• Guides for the flows your application is built around
• Switched on per account

Release state changes, closed statement periods and corrections to a closed period are pushed to your endpoint as they happen, signed so you can prove they came from us, and retried on a published schedule when your endpoint is down. The payload says what changed and links to the resource rather than carrying it, so you read the current record instead of a copy that aged in a retry queue.

• Signed payloads, with the timestamp inside the signature so a captured request cannot be replayed
• Retries on a published backoff schedule, and a dead-letter view when we stop
• Per-account endpoints, subscribed to named events or to everything by default
• Every attempt visible in the console with the response your server gave, and replayable by hand
• A stable event id on every attempt, so a duplicate is a no-op on your side
• Test-mode endpoints that hear only sandbox records, so a rehearsal never reaches production

A test key behaves exactly like a live one — the same endpoints, the same validation, the same response shapes — but everything it creates is held apart from your catalogue. Your live keys cannot see it, it never enters our delivery queue, and it is not metered. You can build the whole integration, get it wrong as many times as you need to, and clear it out in one click.

• A test key on your real account — no second login, no separate environment to keep in step
• Identical behaviour to live, because it is the same code path and not a mock
• Nothing created in it can be delivered to a store, by construction rather than by policy
• Live keys cannot read or change sandbox records, and test keys cannot touch real ones
• Not metered and it does not spend your daily release limit
• Ask the API which mode your key is in, so your own test suite can assert it before it starts
• Clear everything it created in one action, leaving the live catalogue untouched

The specification is machine-readable, so client types are generated from it rather than written by hand — it is how our own artist app and mobile app are built, and what stops a hand-written client quietly disagreeing with the API it calls.

• TypeScript types generated directly from the OpenAPI specification
• The same generation our own front ends use, so the path is exercised every release
• Versioned endpoints — a breaking change is a new version, never a surprise
• Machine-readable discovery so agents and crawlers can find the specification

Established labels and aggregators speak DDEX, and the industry is mid-migration — the current suite is ERN 4.3.x, plenty of the supply chain still runs 3.x, and the platforms that matter accept both. Speaking both, in and out, removes the integration project that would otherwise sit between you and a catalogue that wants to move.

• ERN ingestion and generation across both the 3.x and 4.3.x families
• Batch delivery over SFTP, which is still how most of this supply chain actually moves
• Per-partner conformance testing, because DDEX conformance is agreed between two parties — there is no certificate to hold
• Store-specific packaging where a destination does not speak DDEX at all, which several do not
• Identifier reconciliation against the existing catalogue, keyed on our own identifiers rather than trusting an incoming ISRC
• A validation report rather than a silent partial import