Privacy notice

Workflow Corporation, which trades as Radio Workflow HQ, operates Jingle Buddy and is the controller of the information described here. We are at 210 Emerson Pl, Suite 300, Davenport, IA 52801, USA, on +1 (563) 275-6409.

Write to support@workflowcorp.com about anything on this page and mark it for the attention of the privacy team. That is a real inbox that a person reads, which is why it is the only address here: a dedicated privacy alias that nobody watches is worse than a shared one that somebody does. Support is staffed at any hour, every day; the office keeps Monday to Friday, 8:00 AM to 6:00 PM Central, closed at weekends.

We have not appointed a data protection officer, and we have no representative in the EU or the UK. That is said plainly rather than glossed over with a title nobody holds. If you need one of those roles to exist before you can use a service, it does not exist here yet, and the address above is where to say so.

This notice covers the Jingle Buddy website, the console and the public API, and it applies whether you signed up yourself or were invited into somebody else’s workspace.

When you are a member of a workspace that somebody else owns, they decide what goes into it and who else can see it. We hold that content for them. If you want a brief or a track removed from a workspace you do not own, ask the owner first; we will act on their instruction rather than get between you.

All of it, grouped by why it exists. Nothing here is inferred, bought or enriched from anywhere else: it is what you typed, what you were sent, or what the software recorded while doing what you asked.

• Your account. Your email address, your name if you gave one, and a bcrypt hash of your password if you signed up with one. If you signed in with Google or GitHub instead, we hold the account identifier and the tokens that provider issued us, plus the profile picture URL they returned. We also record when you last signed in, and whether the account has been disabled.
• Your workspace. Its name and its address slug, who is in it and what role each member holds, and any invitation you sent: the email address it went to, the role offered, the one-time token and its expiry.
• What you type. Prompts, style words, lyrics you wrote or asked for, playlist and persona names, and the two briefs this product exists for. A client brief holds the business name, the industry, the tagline, the phone number, the offer, the call to action, the lines that have to be said word for word, the city, the website and your notes. A station profile holds the station name, the dial position, the format, the positioning slogan, the city and your imaging notes. Anything you upload as a reference track or as artwork is held too.
• What the engine produced. The finished audio, every take behind it, any stems you exported and any cover art. Alongside it: the caption that was actually sent to the engine, the seed, the checkpoint that rendered it, the length asked for and the length that came back, how long it took, and the error if it failed.
• Metering. One row per piece of work that spent your allowance: what kind it was, how many seconds it cost, which track and which API key it belonged to, which member did it, and when. Plus the running total for the billing period, which is the number the allowance is checked against.
• Security and API logs. For calls to the public API: the method, the path, the status, how long it took, how many seconds it rendered, the error code, the IP address and the user agent. For consequential actions in the console: what was done, to what, by whom, and from which IP address.
• Billing. The card brand, the last four digits and the expiry month and year, the two identifiers the payment gateway uses for your stored card, and the record of each charge: amount, currency, the period it covered, our reference, the gateway’s transaction id, and the reason for any decline. Card numbers and security codes never reach our servers at all: your browser sends them to the gateway, which hands back a one-time token that we exchange for a stored-card reference in the same request.

This product is unusual in that the most sensitive record in it is often not about you. A client brief is an advertiser’s business name, their phone number, their offer and the legal line their lawyer insisted on. A station profile is a broadcaster’s call sign and positioning.

We treat all of it as your content, held on your instruction. You are the one who needs the authority to put it in, and you are the one who decides who in your workspace can see it. If an advertiser asks us directly for a copy of what you typed about them, we will point them at you rather than answer for you, unless the law says otherwise.

Every supplier that touches your information is in the table below, and there is nothing else on that list. Each one is a company we chose and instructed, not a partner we share with. Everything we run ourselves runs in the United States, in us-east4, which is one Google Cloud region for the application, the database, the audio and the engine alike. Two other routes exist and they are yours rather than ours; they are named under the table.

The third row is the one worth pausing on. The music is rendered by an engine we run ourselves on our own GPU, so the words you want sung, including an advertiser’s phone number and a station’s call letters, are not being handed to somebody else’s music service on the way to becoming audio.

The fourth row is the one people are usually surprised by, so it is stated twice: asking for a sung track without writing the words yourself reaches a language model, because the words have to come from somewhere. An instrumental reaches nothing, and neither does a sung track you wrote the words for.

Two routes out of the product are yours rather than ours, and the table cannot list them because we do not choose where they go. If you register a webhook, we post the event to the address you gave us, and for a finished track that payload carries the words that were sung, so the endpoint you point it at receives them; we deliver only to an https address for that reason. And anything holding one of your API keys, an integration of your own or an assistant you connect to our MCP server, can read whatever that key is scoped to reach. Both are doors you open, and closing one is deleting the webhook or revoking the key.

• To run the product. Rendering what you asked for, storing it, letting your workspace play it back and download it.
• To meter and to bill. Counting seconds against your allowance, charging the card on file, and showing you where the seconds went.
• To keep it working and keep it honest. Diagnosing failures, finding abuse, enforcing the acceptable use policy, and answering support.
• To write to you, which this product barely does. There are exactly two messages it can send: an invitation to a workspace, and a password reset you asked for. There is no marketing mail, no newsletter and no announcement mail, so there is no list to be on, no opt-in to give and no preference centre to manage. A failed payment is not an exception: the retry schedule and its outcome are shown on the billing page rather than mailed to you. If that ever changes, anything new will be opt-in and this paragraph changes with it.

Four, all of them ours, none of them for advertising, and every one of them there to make the product work. There is no consent banner because there is nothing here to consent to.

One exception to “all of them ours”, and it is deliberate: opening the card form on the billing page loads Authorize.Net’s own script from Authorize.Net. That script is the mechanism described above, the thing that carries your card details to them instead of to us, and it loads nowhere else in the product. Nothing else on any page fetches anything from anybody.

One track. In the console, an admin of the workspace deletes it from the track page; through the public API, a key with library access does the same. Either way it removes the row and everything stored under it: the master, every take, any stems and the cover art. Its takes are not kept for you to change your mind about.

A whole workspace. Its owner deletes it from workspace settings, and everything filed under it goes with it: songs, takes, stems, lyrics, briefs, station profiles, personas, playlists, API keys, request logs, usage history and the audit trail. The audio is a separate step, because the rows and the bytes live in different places: removing the workspace queues a job that empties the workspace’s entire folder out of the storage bucket, and the job is created in the same transaction as the deletion so that a crash between the two cannot leave the files behind with nothing left to name them. That job is deliberately stubborn. Once the rows are gone nothing else in the system knows those files should have gone too, so it retries rather than giving up quietly.

Your account. You close it yourself, from your account settings: the account itself, your sign-in credentials, your sessions, your linked sign-in providers and your membership of every workspace you belong to. You type your own email address to confirm it, and it takes effect immediately.

Two rules sit around that, and both are there to protect other people rather than us. A workspace where you are the only member is deleted along with your account, and it is named on the screen with its contents counted before you confirm, because nobody else could ever delete it. A workspace where you are the last owner but other people remain BLOCKS the deletion until you make somebody else an owner: a workspace with no owner cannot be billed, renamed or deleted by anyone, and we are not willing to destroy other people’s work on one person’s say-so.

Work you made inside a workspace that survives you stays with that workspace and simply loses its author. That is deliberate: the workspace paid for it, and other members are still working with it.

All three are things you do yourself, in the console, without asking us. If something has gone wrong and you cannot reach the button, write to support@workflowcorp.com from the address on the account, marked for the attention of the privacy team, and we will do it.

Six things, and we would rather say so here than have you find out later. One of them is uncomfortable and it is second on the list.

• Promotional credit records. If your workspace ever redeemed a promo code, the record that it did (which account, which workspace, how much, when) outlives both the workspace and the account, on purpose. The limits are one redemption per code per person, and one promotional code per workspace ever, across every code we have ever published. If those records went with the workspace, both limits could be reset by deleting a workspace and making a new one. It is a fraud control, it holds no content, and it is the only part of the system built to survive you.
• The engine’s own copy of every render. When the engine finishes a render it writes the file into its own staging bucket and hands us a link, and we immediately copy the bytes into your workspace’s storage so that what you play and download is ours. That staging copy is not removed when you delete the track, is not removed when you delete the workspace, and is not removed on any schedule: nothing in this product deletes it and nothing expires it. Two things are worth knowing about it. Its name is a random identifier that says nothing about you, your workspace or what you asked for, and the staging bucket cannot be listed by the public, so it is not findable by browsing. But it can be read without signing in by anyone holding the exact link, which is how our own service fetches it in the first place. If you need a staging copy purged, ask us and we will do it by hand.
• Links you already handed out. A download or playback link is signed and expires within an hour. One that was created before you deleted the track keeps working until it expires.
• Database backups, for about a week. The database keeps seven automated backups and seven days of transaction logs, so a deleted row can sit in a backup until the last one holding it ages out.
• Deleted files, for seven days. Our own storage keeps a deleted object recoverable for seven days before it is unrecoverable for good. So a track you deleted, or a workspace whose teardown has run, is out of the product at once and gone for good about a week later. We would rather say that than let the word “deleted” imply something the storage does not do.
• Request and audit logs, until the workspace goes. Nothing prunes these on a timer, and we are not going to publish a retention period that no code enforces. API request logs and audit rows belong to the workspace and go by database cascade when the workspace goes. The one exception is an audit row written after that point, the record of the deletion itself included: it belongs to no workspace, so nothing cascades it and it stays.

We may also keep what we have to keep: invoices and payment records for the period the tax authorities require, and anything we have been formally told to preserve.

Depending on where you live you may have the right to a copy of what we hold, to have it corrected, to have it deleted, to restrict or object to how it is used, and to complain to your data protection regulator. In the United States that is generally your state attorney general, and elsewhere the authority where you live. We do not charge for any of it, we do not treat you differently for asking, and we do not ask which statute covers you: sorting people by the law that protects them costs more than simply doing the work.

Write to support@workflowcorp.com, marked for the attention of the privacy team. We will answer within 30 days of a request we can verify. Verification is deliberately low-friction and does not involve sending us identity documents: send the request from the email address on the account, and for anything that covers a whole workspace be an owner or an admin of it. If we cannot match a request to an account we will say so rather than guess.

If your request is about a workspace you are a member of rather than the owner of, we will tell you and bring the owner in, because the content in it is theirs to decide about.

• Passwords are stored as bcrypt hashes. We cannot read yours, and neither can support.
• API keys are stored as a SHA-256 hash with a short display prefix, which is why a key is shown once when it is minted and can never be shown again. If you lose it, you mint a new one and revoke the old one.
• The bucket your workspace’s audio lives in is private. Nothing in it is publicly readable: playback and download go through links that are signed for the person asking and expire within an hour. The engine’s staging bucket, which is a different bucket, is not private, and the section above says so rather than letting this bullet imply otherwise.
• Every workspace’s files live under their own path, and every database query is scoped to a workspace. That is how one customer’s imaging stays out of another customer’s library.
• Traffic is encrypted in transit. Card details are handled by the payment gateway in your browser and never traverse our servers.

No system is perfectly secure. If personal data of yours is breached we will tell the customers affected without undue delay, with what we know at the time rather than waiting until we have a complete picture, and we will notify a regulator wherever the law requires it.

This is a professional tool sold to broadcasters and agencies. It is not directed at children, and an account may not be opened by anyone under 18. The threshold is 18 rather than 13 because holding an account means giving a card to a payment gateway and accepting a commercial licence, and neither is something to do on a child’s say-so. If we learn that an account belongs to someone younger, we will close it and delete what is in it.

The service runs in the United States, and everything we hold ourselves is stored and processed there, in one region. If you are somewhere else, signing up moves your information into the United States, and that is a decision you are making rather than one we make later on your behalf.

We have not put a formal transfer mechanism in place, and we would rather write that than name one nobody has signed. No standard contractual clauses are executed with our suppliers on your behalf and we do not rely on an adequacy decision. If your own rules require one before you can use a service like this, write to support@workflowcorp.com and tell us what you need; it is a real question and it will get a real answer rather than a paragraph.

When this notice changes we publish the new version here with its new effective date, and the date on the page is the one that governs. For a material change, a new purpose, a new processor or a longer retention period, the new version goes up at least 30 days before it takes effect, so there is time to read it and to leave if you do not like it.

We deliberately do not promise to email you about it. As set out above, this product sends two kinds of message and neither is an announcement; there is no list to add you to, and a commitment we have built no way to keep is not worth writing down. Checking this page is the mechanism.

Everything on this page goes to support@workflowcorp.com, marked for the attention of the privacy team. Rights in the music go to the same address marked for the rights team, and the content and rights policy sets out what a notice has to carry. Contract questions go to the same address again, marked for the legal team, and the terms say so too. One mailbox, on purpose, for the reason given at the top.

By post: Workflow Corporation, 210 Emerson Pl, Suite 300, Davenport, IA 52801, USA. By telephone: +1 (563) 275-6409.