| September 10, 2026 | Canadian telephone calls are now carried in Montreal in both directions when we issue the number through Telnyx, a new Canadian workspace now starts on a voice engine that runs speech recognition, the language model and speech synthesis in Montreal, and the dashboard's own AI features moved to Montreal for every Canadian workspace; calls on numbers issued through Twilio, Canadian or United States, are unchanged and still reach us in the United StatesLire la suite de cette entrée- The voice engine changed on the same day, and it is a separate change from the telephone one. Two things happened. First, the language model that powers the receptionist now runs in Montreal (Google Cloud, northamerica-northeast1) for a Canadian workspace on every voice engine but the realtime one (the third paragraph of this entry), where before it ran in the United States for all but one of them; the same move applies to the model that writes a call's summary afterwards and to the one that reads a shared screen. Second, a Canadian workspace created from today starts on the voice engine that also keeps speech recognition and speech synthesis in Montreal, on Amazon Transcribe and Amazon Polly (Amazon Web Services, ca-central-1). That engine has existed since August 28 2026 and was off by default until today.
- ⚠️ Nothing was changed on a workspace that already exists. A Canadian workspace that had already chosen a voice engine keeps it, and we did not rewrite anyone's setting. What every existing Canadian workspace does get is the language-model move, because that is not a per-workspace choice: it is where we send the request. So a Canadian workspace on one of the other engines now has its reasoning in Montreal and its speech recognition and speech synthesis in the United States, and the engine picker in the dashboard labels each engine with the region every step of it runs in, so you can see which is which before choosing.
- What did NOT move, said plainly. The realtime voice engine, which does listening and speaking with a single model, still runs in the United States (us-east4) for a Canadian workspace, because Google does not serve that particular model from its Montreal region at all. That is a limit of what the vendor publishes rather than a choice of ours, and it is why we describe the two engines separately instead of saying 'AI processing is in Canada'.
- One risk we would rather record than discover. The Montreal language model is a version Google has said will enter extended-support status in October 2026, and Google has not announced a successor served from Montreal. If none appears we will have to choose between a United States fallback, which we would disclose here and label in the product, and another approach; we are not going to let the label say Canada while the request goes elsewhere.
- What changed, in one day and in both directions. When our assistant places a call on behalf of a Canadian workspace, the call room, the assistant and the equipment that connects the call to the telephone network now run on our Montreal machine (Amazon Web Services, ca-central-1), the same machine that already holds that workspace's records and its in-browser call media, and the call is handed to Telnyx over a connection anchored at Telnyx's Montreal site. Later the same day the other direction followed: a call arriving on a Canadian number we issue through Telnyx is delivered to that machine from Telnyx's own Canadian gateway and is answered, hosted and transcribed in Montreal. Until today both directions ran in the United States. No sub-processor was added or removed, and no new category of data changed hands.
- ⚠️ NOT every Canadian number, and the distinction is the carrier rather than the country. A telephone number is issued by a carrier, and only Telnyx has Canadian infrastructure we can hand a call to. A call arriving on a number issued through Twilio reaches us in the United States and is hosted on our United States media node, whether that number is Canadian or a United States one, because Twilio publishes no Canadian point of presence. Numbers we issue from today are Telnyx-issued and attached to the Canadian bridge at the moment they are bought, and numbers already issued through Twilio keep the answer they have. We would rather say that plainly than let "a Canadian number" read as Canadian residency.
- Where our claim stops, stated plainly rather than left to be inferred. Our own half of each call is what we describe: the room, the assistant and the equipment that connects the call are in Montreal, our outbound connection and our inbound one are both anchored at Telnyx's Montreal site, and on the inbound proof the call was delivered to us from Telnyx's Canadian gateway. Telnyx describes where it processes a call as a preference it endeavours to honour rather than something it guarantees contractually, so we make no claim about what it does before it hands us a call or after we hand it one, and our internal capability register records Telnyx's Canadian processing as unconfirmed rather than in-region. This is the same rule, and the same limit, as the European changes of August 18 and August 28 2026.
- One measurement we are deliberately not leaning on. On the outbound proof call the carrier's media address was inside Telnyx's published North American range and about 20 milliseconds from our machine, over a path that passes through a content-delivery network. A round trip that short cannot establish where a packet physically is, so we do not offer it as evidence of anything, and we record it here rather than quietly dropping it.
- The dashboard's own AI moved with the voice engine, and it is worth stating separately because it is not part of a phone call at all. When you ask the console assistant a question, when we suggest a reply to a message, when we write up a meeting or analyse a call after it ends, when we compile a lead dossier, and when we index a document you add to your knowledge base so it can be searched, those requests ran in the United States for every workspace until today. For a Canadian workspace they now run in Montreal (Google Cloud, northamerica-northeast1), and for a European workspace in the EU (europe-west4). No sub-processor was added and no new category of data changed hands: the same vendor is doing the same work, closer to where the records already live.
- What did NOT move with it, on the same honesty rule as the voice engine. The external enrichment providers a lead dossier may query about a company are separate services and are still United States ones, disclosed on their own rows. The documents already in a knowledge base were not re-indexed and did not need to be: the embedding model returns the same values wherever it is served, so what changed is where the request goes, not what is stored.
- Amended later the same day, when buying a Canadian number started doing this by itself. Until this afternoon the Canadian bridge answered exactly one number, our own test line, and everything above described a path a person had to wire by hand. A Canadian number bought today on a workspace whose telephony we operate is issued through Telnyx, bound to our Montreal connection at the moment of purchase and answered in Montreal from its first call. A workspace that connected its own carrier account keeps buying on that account, so a Canadian number bought with your own Twilio credentials is a Twilio number and is answered in the United States, exactly as the paragraph above says. We have amended this entry rather than adding a second one for the same day, on the same reasoning as our entry of August 28 2026.
- One limit that comes with it, stated here because a Canadian number invites the assumption. Emergency calling is not enabled on any number we issue, Canadian or otherwise: the platform does not support or route emergency calls, our terms say so, and a number bought through us cannot be used to reach 911. Nothing about today changes that, and buying a number answered in Montreal does not make it a line an emergency service can be reached on.
- Also published today, and it is a disclosure rather than a change: what still LEAVES Canada, named in one place. Nothing moved for this paragraph. These are arrangements we have decided to keep, and we would rather list them than let the day's Canadian changes read as "everything is in Canada now". Sign-in, the directory that routes a telephone number to a workspace and your billing records are held in the United States. The shared operational state that every request touches is a United States database, and a scheduled job that sweeps all four regions runs on whichever of our origins holds the lock for it, which is often the United States one. Our websites are reached through Cloudflare's global edge, whose nearest-location routing we do not pay to confine to Canada. Error diagnostics rest in Germany and infrastructure telemetry and logs in the European Union, because neither provider operates a Canadian region. Account, verification and newsletter email is delivered from the United States. The key that encrypts the third-party credentials you connect, and the store holding our own secrets, are managed in a global Google location rather than a Canadian one. Payments, the optional video avatar and mobile push delivery are outside Canada. And a text message on a Canadian number we issue is carried through Telnyx's United States messaging interface even though a call on that same number is answered in Montreal. The Telnyx, Google Cloud, Cloudflare, Sentry and New Relic entries each carry the sentence that says so, and the data residency map now states the whole list in one paragraph, in both locales.
- Which entries moved with this. The Telnyx entry now describes the Canadian handoff in both directions beside the European one, and its region chip reads US / EU / CA handoff. The Twilio entry says that a call arriving on a Twilio-issued number reaches us in the United States whether the number is Canadian or not. The Amazon Web Services entry said telephone calls for a Canadian workspace are NOT handled in Montreal; it now says they are, in both directions, with the Twilio exception named, and it additionally discloses speech-to-text and text-to-speech in Montreal for the engine new Canadian workspaces start on. The Deepgram entry no longer calls itself the default engine without qualification, because it is the starting engine everywhere except Canada. The Google Cloud entry no longer says it handles the media of every telephone call on a Canadian number. Off this page: the data residency map, the sovereignty page's carrier section, the privacy policy's transfers section and the Canadian region page all state the same answers in the same change.
|
| September 10, 2026 (later the same day) | The live-call events that drive a Canadian workspace's dashboard are now carried and stored in Montreal instead of the United StatesLire la suite de cette entrée- What changed. While a call is in progress and when it ends, we send a short event describing it to an internal message bus, so your dashboard can show the call as it happens. For a Canadian workspace that bus was in the United States; from today it is in Montreal (Google Cloud Pub/Sub, northamerica-northeast1), and the service that reads it and pushes the update to your browser now runs on our Montreal machine rather than our United States one. The same applies to the routing events that make your inbox update without a refresh. No sub-processor was added or removed: Google Cloud already ran this bus, and it already ran a European one on the same arrangement since August 17 2026.
- What is in one of these events, since it is the reason this is worth a disclosure at all. When a call starts, the caller's name and the phone numbers on the call; when it ends, the transcript, the AI summary and the link to the recording. The call audio itself is never sent to the bus. Only calls carried over the telephone network produce these events; a meeting or video call held in the browser produces none.
- Where the event is CREATED is a separate question from where it is carried, and today's change moves only the second. The line falls on the carrier, exactly as it does for the calls themselves, and exactly as the entry above describes: a call your workspace places, and a call arriving on a Canadian number we issue through Telnyx, both run on our Montreal machine, so their events are written in Montreal as well as carried and stored there. A call arriving on a number issued through Twilio, Canadian or United States, is still answered in the United States, so its event is still written there before it is carried to Montreal and stored. We would rather state that split than let today's change read as more than it is.
- Why it was in the United States until now, plainly. The Canadian bus needed a service in Canada to read it, and until today there was not one — publishing to a bus nobody reads is a dashboard that silently stops updating, which is worse than the transfer it would have avoided. The reading service was built and deployed first, and the events were pointed at it afterwards.
- Which entries moved with this. The Google Cloud entry now names three message buses rather than two and says which workspaces use each. The Redis entry describes six databases rather than five, because a separate Canadian database in Montreal now holds the rate-limit counters for our Canadian origin. Off this page: the data residency map, the data-residency section of our terms, the privacy policy's transfers section and the Canadian region page all state the same thing in the same change. Our entry of August 17 2026, which made this move for European workspaces, is left exactly as published.
|
| September 10, 2026 (corrections, that evening) | Correction: to the two September 10 entries above, the realtime voice engine is the one engine whose reasoning is not in Montreal, the Canadian signalling bus now carries telephone trunk configuration, the Canadian rate-limit database is on the residency map's table as well as in its prose, and the Canada roll-up names workspace membership, backups and lead enrichmentLire la suite de cette entrée- The correction, and it is one sentence that appeared in eleven places. This morning's entry said the language model runs in Montreal for a Canadian workspace on EVERY voice engine. It does not, and the exception was already published two paragraphs later in that same entry: the realtime voice engine listens and speaks with a single model that Google does not serve from its Montreal region at all, so a Canadian workspace that chooses that engine has its reasoning in the United States (us-east4) and its label in the engine picker says so. Both halves were true and the claim was written as though the second did not exist. Every surface that carried the unqualified sentence now names the exception inside it rather than after it: the Canada page, the sovereign portal, the PIPEDA page, the data residency map, the data processing addendum, the privacy policy and the Google Cloud entry above.
- A second correction on this morning's entry, and this one runs in the opposite direction. We published that the Canadian signalling bus carried no telephone trunk configuration, because no telephone equipment ran on that node. Telephone equipment started running on that node the same day, which is what made a Canadian call possible at all, so the Canadian bus has carried trunk configuration since September 10 2026 exactly as the United States and European ones do. The Redis entry above now says all three carry it.
- The Canadian rate-limit database was in the prose and not in the table. September 10 added a second regional counter database, in Montreal (Amazon Web Services, ca-central-1), holding the rate-limit counters for requests that reach our Canadian origin. This register described it and the data residency map's own paragraph mentioned it, but the map's TABLE still said two shared databases and named only the United States and Frankfurt ones. The table is the surface a reader checks a claim against, so it now says three, names Montreal beside Frankfurt, and the privacy policy's transfers section says three as well.
- The Canada roll-up, which exists so that a Canadian reader does not have to assemble the list out of the table, was missing four things. It now names the record of who belongs to your workspace, held in the United States alongside sign-in and the phone-number directory; the encrypted backup copy of your workspace's database, written to a Cloudflare bucket whose location Cloudflare chooses rather than one pinned to Canada, encrypted in Montreal before it leaves and with the key kept back; the optional lead enrichment lookups, which run against United States data providers with only the result returning to Montreal; and the realtime voice engine's reasoning, for the reason in the first point above. Its closing sentence also counted fifteen rows where the table has eighteen, and it now counts eighteen.
- Which entries moved with this. The Google Cloud entry now says the language model runs in Montreal on every voice engine but the realtime one, keeping the sentence that already named that exception. The Redis entry says all three signalling buses carry telephone trunk configuration and dates the Canadian one. The Telnyx entry separates the two Canadian directions instead of saying both at once, because the outbound half is every Canadian workspace's calls and the inbound half is only the numbers we issue through Telnyx, and the Amazon Web Services entry carries the same scope. Nothing about where any data is processed changed this evening. Every line here is a correction to how it was described.
|
| September 10, 2026 (fourth entry, that night) | Cartesia added as an optional voice engine, processed in the United States for every workspace that chooses itLire la suite de cette entrée- What changed. A workspace can now choose Cartesia's Sonic model as the voice of its assistant, in the same place it chooses any other voice engine. Cartesia receives the assistant's text and returns the synthesized audio; it does not receive the caller's audio, which stays with the speech-recognition engine already listed. Nothing changes for a workspace that does not choose it.
- Where it runs, stated plainly. Speech synthesis on this engine runs in the United States for every workspace, including European and Canadian ones. Cartesia offers European, British, Indian and Australian endpoints only on its Enterprise tier, which we do not hold, and publishes no Canadian one. The engine picker labels the leg that leaves the region before the choice is made, and a European workspace that needs every leg in region keeps the engine it starts on.
- Why now. Cartesia admitted Distronode to its Startups programme in September 2026, which moved the account onto a plan carrying a commercial licence. Until then the engine existed only for our own evaluation and was deliberately kept out of this register, because a row here is a claim that customer speech reaches the vendor, and it did not.
- Which entries moved with this. A Cartesia row in the speech group above, and the privacy policy's list of optional voice engines in both locales. No other sub-processor was added or removed, and no existing workspace's engine was changed.
|
| September 3, 2026 | Correction: European and Canadian telephone numbers are offered to customer workspaces, so this register no longer says every customer number is a United States numberLire la suite de cette entrée- What is different, and it is what you can buy rather than where anything moved. A workspace can hold a telephone number in Canada as well as the United States, and a European one: a number in Estonia needs no paperwork from you, because we hold that country's regulatory registration ourselves, and other European countries open once your workspace's own local registration is approved. No sub-processor was added or removed, no data changed hands, and nothing about an existing number changed today.
- What it means for where your calls are handled, which is why it belongs on this page at all. A call that arrives on a European number is delivered to us by Twilio at its Dublin edge in Ireland to our own equipment in Frankfurt, and is answered, hosted and transcribed in Europe. A call that arrives on a Canadian number is not the same answer: Canada is where the number is issued, not where the call is handled, so such a call reaches us in the United States and runs on our United States media node in both directions, exactly as a United States number does. We would rather say that plainly than let a Canadian number read as Canadian residency.
- The correction itself. Our Twilio entry said calls arriving over the phone network were United States for 'every customer number today' and that European numbers were 'not yet generally available' to customer workspaces. Both sentences were true when they were written and stopped being true today, and this is the second time a number claim on this register has expired that way — the first was on August 28 2026, hours after it was published. The entry now describes what a workspace can actually buy and where each kind of call is handled.
- Where else the same sentence lived, all corrected the same day: the data residency map, the data-residency section of our terms, the privacy policy's transfers section and our about page each carried some form of 'every customer number today', and so did two more entries on this register itself. The Google Cloud entry said telephone-call media ran in the United States for calls 'on United States numbers, which every customer number is today'; it now says United States and Canadian numbers, and names the European exception the Twilio entry above describes. The Amazon Web Services entry said every number a Canadian workspace can hold is a United States number; it now says a Canadian number is issued in Canada and answered in the United States, which is the same conclusion resting on a fact that has not expired. Our change-log entries of August 19 and August 28 2026 are left exactly as published, because they are dated statements of what was true on those days; read them alongside this one.
- What has NOT changed, on the rule this page has followed since August 18 2026. We still make no claim about where Twilio processes a call past the point it hands it to us or takes it from us: our own measurements are of our own side of that handoff, Twilio has not confirmed its processing location in writing, and our internal capability register still records its European processing as unconfirmed. Registration documents you submit for a number in a regulated country are still held by Twilio's regulatory-compliance service in the United States, and nothing is sent to it until you submit a registration.
|
| August 31, 2026 | Sinch entry corrected against the account itself: SMS and voice only, and a 180-day retention of message content at Sinch is now disclosedLire la suite de cette entrée- The Sinch entry said Sinch carried WhatsApp messages for us. Our Sinch account has no WhatsApp channel configured, so no WhatsApp message has ever passed through Sinch; the entry now lists SMS and voice, which is what the account actually does. This is a correction to a description, not a change in what happens to any data.
- Added, because it was true and unstated: Sinch's messaging service keeps its own copy of message content for 180 days after delivery, its default retention, and deletes it afterwards. That copy exists in Sinch's United States region alongside the message routing the entry already disclosed. Our own retention of message content is governed by the privacy policy and is unchanged.
- Both facts were read from the account configuration directly rather than from our own description of it, which is the standard every entry on this page is held to.
|
| August 29, 2026 | Registering a telephone number in a regulated country now involves the documents that country's regulator demands, which means we may hold government identity documents for the first time; nothing changes for anyone who does not start such a registrationLire la suite de cette entrée- What changed, and for whom. Some countries' telephone regulators require documents before a number there can be held: a business registry extract, a proof of address, and — when a number is registered in an individual's name rather than a company's — a government identity document such as a passport or national identity card. The dashboard now walks a workspace through providing those documents and submitting the registration. If you never start a registration for a number in such a country, nothing about your data changes today, and no United States or Canadian number involves any of this.
- We would rather say the sensitive part plainly than bury it in the word 'documents'. A passport scan is the most sensitive category of personal data this platform can now hold — above call audio. It enters the estate only when a person chooses individual registration and uploads one, it is never required for company registrations where the regulator accepts business documents, and we do not ask for identity documents anywhere else, for any other purpose.
- Where the documents live. The copy we hold is stored in a dedicated bucket in the workspace's own region — the same regional arrangement as recorded call audio, disclosed on the Google Cloud entry — separate from the recordings bucket and never in a shared one. It is readable only through short-lived links our own dashboard mints; there is no public path to it. Submitting the registration sends the documents to the carrier for the number, Twilio, whose regulatory-compliance service runs in the United States, because handing them to the regulator's process is the entire purpose of collecting them; nothing is sent to the carrier until the moment you submit.
- How long we keep them. Thirty days after the number is released or the registration is withdrawn, the documents are deleted; deleting the workspace or the account deletes them immediately. The privacy policy's retention section carries the same window, and the Data Processing Agreement's description of the personal data we process now names registration documents explicitly.
- One honesty rule the feature enforces rather than states. A registration declares who the number's end user is, and that declaration goes to a regulator. Registering a company as an individual, or the reverse, to dodge a document requirement would be a false declaration to that regulator, so the registration flow asks for the documents the declared type actually requires and does not offer a way around them.
- The Twilio entry on this register has been updated to name registration documents in its data category and to say where its regulatory-compliance service runs, and its data chips now include identity documents so the fact is visible at a glance rather than only in the long text. The Google Cloud entry discloses the regional storage. The data residency map, the privacy policy and the Data Processing Agreement moved in the same change.
|
| August 28, 2026 | Calls we place for European workspaces over Twilio now connect through Twilio's Dublin edge in Ireland, and later the same day our first European telephone number went live, arriving in Europe; calls on United States numbers are unchangedLire la suite de cette entrée- What changed, and only this. When our assistant places a call on behalf of a European workspace and the carrier for that call is Twilio, the call now connects from our equipment in Frankfurt to Twilio through Twilio's Dublin edge in Ireland, over an encrypted connection. Until today those calls connected to Twilio through its United States edge. Calls placed over Telnyx are unchanged and are still handed to Telnyx at its Frankfurt site, as our entry of August 18 describes.
- Where our claim stops, stated plainly rather than left to be inferred. Our own measurements, taken on live calls, show the call's media being handled in Ireland at the point where Twilio takes it: the network addresses Twilio assigns for the call's audio when a call enters at Dublin are distinct from the ones it assigns at its United States edge, and its signalling gateways for those calls are the ones Twilio publishes for Ireland. Twilio has not yet confirmed its processing location for these calls in writing. A measurement of ours is not a commitment of theirs, so the Twilio entry's region text says exactly that, and our internal capability register continues to record Twilio's European processing as unconfirmed until something citable exists.
- Calls that come IN to you are now split by the number's country, where this entry originally said they were unchanged. A call that arrives on a United States number — every customer number today — still reaches us in the United States, is still hosted on our United States media node, and is still transcribed there. Late on August 28 our first European telephone number went live, in Estonia: a call that arrives on it is delivered by Twilio at its Dublin edge in Ireland to our own equipment in Frankfurt, and is answered, hosted and transcribed in Europe. European numbers for customer workspaces are not yet generally available, so nothing changes for any number you hold today. This entry was amended the same day it was first published: its original wording said every telephone number we hold is United States, and by that evening it no longer was.
- Where the inbound claim stops, on the same rule as the outbound one. Twilio delivers the Estonian number's calls to us at its Dublin edge, and that delivery is ours to measure: on a live call it arrived from Twilio's published Ireland gateways into our Frankfurt equipment. What Twilio does with a call before that handoff is not ours to claim, and Twilio has not yet confirmed its processing location in writing, so our internal capability register still records Twilio's European processing as unconfirmed, for inbound exactly as for outbound.
- One thing we tried and rejected, for the record. Twilio documents a per-call region setting intended to anchor processing in Ireland. In our testing, enabling it made the connection stop working entirely rather than move, so the shipped design does not use it, and we have reported the behaviour to Twilio. We mention this because the honest basis for today's change is where the call demonstrably enters and is handled, not a vendor configuration flag.
- The Twilio entry on this register has been updated to describe the split rather than saying United States flat, and its region chip now reads US / EU handoff, matching Telnyx. The data residency map and the platform page state the same thing per data type. Nothing changed for Sinch.
|
| August 19, 2026 | Canadian in-browser call media now processed in Montreal; telephone calls are NOT covered and still reach us in the United StatesLire la suite de cette entrée- What changed. A Canadian workspace's in-browser calls now have their live audio processed in Montreal, on Amazon Web Services (ca-central-1), on the same machine that already runs the Canadian website and database. Until today all live call media for Canadian workspaces was processed by Google Cloud in the United States (us-east4). This covers calls made and received in the browser, including the relay used when a participant's network blocks a direct connection. The audio is processed in Montreal and is not stored there.
- The Canadian media node has its own signalling bus in Montreal (Redis Cloud, ca-central-1) rather than sharing the United States one, and its own assistant running in region. Sharing a signalling bus would have let a Canadian call be served from a United States machine while every other setting said Montreal, which is the failure this arrangement exists to prevent. Our Redis entry now describes five databases rather than four, and its region chip reads US / EU / CA.
- ⚠️ Telephone calls are NOT covered, and this is the half most likely to be read too generously. Every telephone number we hold is United States, so a call to or from the telephone network reaches us in the United States and its media is still hosted on our United States media node, in both directions, for Canadian workspaces. There is no telephone equipment on the Montreal machine at all. This is narrower than the European change of August 18, which moved outbound telephone calls as well; nothing of the sort has moved for Canada.
- Speech-to-text, the language model and speech synthesis for Canadian workspaces are unchanged and still run in the United States. None of the speech or language-model providers we use offers a Canadian region, so there is nothing to move: this is a market limitation rather than a choice, and we would rather say so than let the media change imply a Canadian call is processed end to end in Canada. It is not.
- Recorded call audio for Canadian workspaces was ALREADY stored in Canada and is unchanged by any of this. Those recordings sit in a Google Cloud Storage bucket in Montreal (northamerica-northeast1) and are disclosed on the Google Cloud entry. That is a different company from the one that now processes the live audio, and the two claims are separate: Amazon Web Services processes a Canadian in-browser call as it happens, Google Cloud stores the recording of it afterwards.
- The Amazon Web Services entry on this register has been updated to disclose Canadian in-browser call audio, and the Google Cloud entry no longer says it handles real-time call media everywhere outside Europe, because that stopped being true today. The data residency map states the same thing per data type.
|
| August 18, 2026 | Calls we place for European workspaces now start in Frankfurt; calls that come in to you are unchanged and still reach us in the United StatesLire la suite de cette entrée- What changed, and only this. When our assistant places a call on behalf of a European workspace, everything on our side of that call now runs in Frankfurt: the call room, the AI assistant itself, the speech recognition, the speech synthesis, the language model, and the equipment that connects the call to the telephone network. Until today all of that ran in the United States for every workspace, and a European workspace's outbound call was assembled there and dialled from there.
- Where our claim stops, stated plainly rather than left to be inferred. Our equipment in Frankfurt hands the call to our carrier, Telnyx, at that carrier's Frankfurt site. Past that handoff we do not control the path and we do not claim one: Telnyx describes where it processes a call as a preference it endeavours to honour, not a contractual guarantee. So the honest description is that our half of an outbound European call is in Europe and the carrier's half is not promised to be. We would rather publish that sentence than round it up to a claim we cannot stand behind.
- Calls that come IN to you are unchanged. A call that arrives over the phone network still reaches us in the United States, is still hosted on our United States media node, and is still transcribed there. Nothing about inbound call handling moved today, and a European workspace therefore has calls in both places depending on which way the call was going.
- We still hold no European telephone number. That requires a legal establishment in Europe to buy a number against, which is in progress and is not done. Until it is, there is no such thing as a European inbound number on this platform, which is the reason the previous point reads the way it does.
- The Telnyx entry on this register has been updated to describe the split rather than saying United States flat, and its region chip now reads US / EU handoff. The privacy policy and the data residency map state the same thing per data type. Our internal capability register continues to record Telnyx's European processing as unconfirmed, because a preference is not a commitment.
- One consequence worth naming for European workspaces. The description of an outbound call that our dashboard shows live is now created in Frankfurt as well, because the systems that write those events are the ones that moved. For a call that arrives over the phone network the event is still created in the United States, as our entry of August 17 says.
|
| August 18, 2026 (later the same day) | Our error tracking moved from the United States to Germany, for every regionLire la suite de cette entrée- What changed. Sentry, the service that tells us when something breaks, now holds our error diagnostics in its German region rather than its United States one. This covers our website and dashboard, our voice assistant, the service behind the live call dashboard, and our internal reporting tools. The Sentry entry on this register now reads Germany rather than United States.
- What this data is, unchanged from before: diagnostic reports produced when something goes wrong. They may include IP addresses and user identifiers, and, from a browser, the page you were on when the error happened. It is not call audio, transcripts, messages or contact records.
- For European workspaces this removes a transfer out of your region. Error diagnostics from a European workspace previously went to the United States; they now stay in the EU.
- For Canadian, United States and Asia-Pacific workspaces this is a change of destination, not a removal, and it goes the other way. Your error diagnostics now go to Germany rather than to the United States. We are naming that rather than describing this as an improvement for everyone: as our August 17 entry said of our support desk, one provider region still serves all four of our regions, so this category still does not stay in your region unless your region is Europe.
- One honest caveat about timing, which applies to browsers only. A page already loaded from our site carries the older reporting address inside it, so for as long as a visitor's cached copy of our site is in use, an error from that page can still be reported to the United States. That ends as those cached copies expire. Everything running on our own machines switched over at once.
- The data residency map has been updated to match.
|
| August 17, 2026 | Correction: our speech engines were listed as United States only, when European workspaces already used their European endpoints; and live call events cross to the United StatesLire la suite de cette entrée- Correction. The Deepgram and AssemblyAI entries said their region was the United States, flat. That was wrong for European workspaces, and it was wrong on the same page that said the opposite: our August 16 entry stated that speech-to-text for European workspaces was already processed in the EU. A European workspace's speech-to-text and Deepgram speech synthesis run on those vendors' European endpoints (api.eu.deepgram.com and streaming.eu.assemblyai.com), and have done since before that entry. Both entries now say so, and the region chip on each reads US / EU rather than US.
- Nothing about where your audio goes changed with this correction. What changed is that the register now describes it accurately. Canadian and Asia-Pacific workspaces are still processed in the United States by both vendors, because neither publishes a Canadian endpoint, and neither publishes one in Singapore, where our Asia-Pacific region runs.
- New disclosure, and it is a hop out of your region that we had not written down anywhere. While a call is in progress and when it ends, we send an event describing the call to an internal message bus (Google Cloud Pub/Sub) in the United States, so that the live dashboard can show the call as it happens. This runs for every region, including Europe. It covers calls that arrive over the phone network; a meeting or video call held in the browser produces no such event.
- What is in those events: the caller's name and the phone numbers on the call, at the moment the call starts, and, when a call that arrived over the phone network ends, the transcript, the AI summary and the link to the recording. The call audio itself is not sent to the bus.
- So, stated plainly: a European workspace's in-browser call audio is processed in Frankfurt and its speech-to-text in the EU, and the description of a call that reaches that workspace over the phone network still crosses to the United States. We would rather publish that than let a reader infer from our August 16 entry that nothing about a European call leaves Europe. Removing this hop for European workspaces is work we intend to do; until it is done, this is what happens.
- The Google Cloud entry has been extended to name the message bus, what it carries, and that it sits in the United States for every region. The data residency map states the same thing per data type.
|
| August 17, 2026 (later the same day) | Our shared operational cache is now disclosed; our support desk's hosting realm is Canada; and our backups are in two different R2 jurisdictions, not oneLire la suite de cette entrée- New disclosure. Our Redis entry described one database in the United States. There are four, and the register now names what each one does and where it is. This is operational state rather than call content, but one of those databases is touched on every single request in every region, including Europe, and that had not been written down anywhere.
- The fleet-wide one runs in the United States (us-east4) and holds rate limits, short-lived caches, webhook idempotency claims and the lock that decides which of our four origins runs each scheduled job. A second, in Frankfurt, holds only the rate-limit counters for requests reaching our European origin. The other two are the signalling buses for our United States media node and our European one, which carry live-call room and participant state and no audio. Requests to our Asia-Pacific origin have no counter database of their own and use the United States one.
- What is in those keys: counters and short-lived cached values, keyed to identifiers such as an account, a workspace, a call or an IP address. Where a key name would otherwise contain an email address, a phone number or an IP address, it carries a one-way keyed hash of that value instead, so the name itself does not read as a person. The region chip on the Redis entry now reads US / EU rather than US.
- Our support desk's hosting realm is Canada, and it is now published as a fact rather than as something we were still confirming. Our August 15 entry said we were confirming it and would publish it here; our organisation administrator read the setting in the Atlassian admin console on August 17 and it is Canada. (The realm was briefly recorded as the European Union in our own repository earlier that same day, before the organisation administrator corrected it to Canada; that wording was never published on this site.) Atlassian exposes this setting in that console only, and its administration API has no endpoint that reports it, which is why this took two days rather than one query.
- The narrowing that comes with it, stated plainly. One Atlassian site still serves all four regions, so support data still does not stay in your workspace's region. What has changed is that we can now say where it goes: for a Canadian workspace the desk is in your region, and for a European, United States or Asia-Pacific workspace your support request is held in Canada rather than in your own region. For a European workspace that is a transfer out of your region, to a country the European Commission recognises as providing adequate protection for personal data held by commercial organisations. The claim gets narrower and more specific; it does not go away.
- Correction to how we described our encrypted backups. This page said they were held with Cloudflare, without saying that they sit in two different R2 jurisdictions. European backups are written to a bucket created in Cloudflare's European jurisdiction, so those objects stay in the EU. The United States, Canadian and Asia-Pacific backups are written to a bucket in R2's default jurisdiction, each region under its own key prefix. A key prefix is a filing convention and not a jurisdiction, and describing the layout without that distinction would have let it read as four regional stores when it is two.
- Every dump is still encrypted inside its own region before it is uploaded, and the decryption key is still held in a managed secret store separate from the company that stores the backups. Moving the Canadian and Asia-Pacific backups into their own jurisdictions is work we intend to do; an R2 bucket's jurisdiction is fixed when it is created, so it means new buckets and a verified copy across, which is exactly how the European move was done.
- The privacy policy and the data residency map have been updated to match on all three points.
|
| August 17, 2026 (later still) | European workspaces' live call events now ride a European message bus, stored in Frankfurt and consumed in EuropeLire la suite de cette entrée- This closes the commitment in our first entry of August 17, which said that removing this hop for European workspaces was work we intended to do. It is done, and this entry says exactly how far it goes.
- What changed. A European workspace's live call events are now published to a message bus in Frankfurt (Google Cloud Pub/Sub, europe-west3), pinned so the messages are stored in that region, and consumed by a dashboard service running on our European machine in Frankfurt. Previously every region's call events went to a message bus in the United States.
- What still touches the United States, stated plainly rather than left to be inferred. The event is CREATED by our United States systems. A call that arrives over the phone network reaches us in the United States, because that is where our telephone carriers terminate calls and where the software that turns a call into these events runs. So for a European workspace the description of a call is written in the United States and then carried and stored in Europe. That is a real narrowing and it is not the same as saying nothing leaves.
- The inbox routing events we push when a message arrives or goes out follow the same bus. Those are created by whichever of our origins served the request, so for a European workspace they are created in Europe as well whenever our European origin answered, and in the United States when our geographic router sent that request to ours there.
- Not covered, and unchanged. The shared operational database disclosed in our second entry of August 17 is still one database in the United States that every region touches on every request. Canadian and Asia-Pacific workspaces' call events are unchanged and still go to the United States bus, because neither region has a dashboard service of its own to consume a regional one, and publishing to a bus nobody reads would stop those dashboards updating.
- The Google Cloud entry now names both message buses and says which workspaces use which. The privacy policy and the data residency map state the same thing per data type.
|
| August 16, 2026 | European in-browser call media now processed in Frankfurt; telephone call media still in the United StatesLire la suite de cette entrée- European workspaces' in-browser calls now have their live audio processed in Frankfurt, on Amazon Web Services, on the same machine that already runs the European website and database. Previously all call media for every region was processed by Google Cloud in the United States.
- This covers calls made and received in the browser, including the relay used when a participant's network blocks a direct connection. The audio is processed in Frankfurt and is not stored there.
- ⚠️ Telephone calls are NOT covered and still have their media processed in the United States, including for European workspaces. Our telephone carriers terminate calls in North America, so a phone call reaches us there; moving that requires a European carrier, which we are pursuing. We would rather state this plainly than describe European call handling in a way that only holds for part of it.
- Amazon Web Services has been updated on this page to disclose call audio for European workspaces, and the Google Cloud entry now says explicitly that it continues to handle telephone call media for every region.
- Correction in our own favour, while checking the above: this page said Google Cloud held call-recording storage in the United States, without noting that recorded audio is already stored per region. A European workspace's call recordings are written to a bucket in Frankfurt, and have been since regional recording storage shipped. The entry now says so.
- Speech-to-text, the live-call language model and speech synthesis for European workspaces were already processed in the EU and are unchanged.
|
| August 15, 2026 | Correction: Amazon Web Services now hosts three regions and was not listed; Akamai / Linode and Civo are gone; Atlassian added for supportLire la suite de cette entrée- This entry records changes already made rather than advance notice of them, and for the hosting change that is a failure on our part rather than a choice. Our Data Processing Agreement promises at least 30 days' notice before we add or replace a sub-processor. We moved three regions onto a new hosting provider without publishing it here first, and this page was wrong for between one and two days as a result. If you have questions or an objection, write to legal@distronode.com.
- Amazon Web Services, Inc. has been added. It now runs the website and dashboard origin, and the workspace database, for the Canadian, European and Asia-Pacific regions. Asia-Pacific moved on 2026-08-13, and Canada and Europe on 2026-08-14, with the origin and the database moving together in each case.
- The cities did not change, and neither did any region's data residency. Canadian data stays in Montreal (ca-central-1), European data in Frankfurt (eu-central-1) and Asia-Pacific data in Singapore (ap-southeast-1). What changed is which company operates the machines, which is exactly what this page exists to tell you.
- Akamai / Linode has been removed. It hosted the Asia-Pacific origin and that region's database until 2026-08-13; the machine was destroyed the same day and the account holds nothing of ours.
- Civo has been removed. It hosted the European origin and the European workspace database until 2026-08-14; that machine was destroyed the same day and the account holds nothing of ours. This means the statement in our 2026-08-02 entry, that the European database sits on a European provider in Frankfurt, is no longer true: it is still in Frankfurt, and the provider is now Amazon Web Services.
- The Google Cloud entry has been corrected in the same pass. It still described Google as holding the Canadian database in Montreal and Asia-Pacific storage in Singapore, and described the European database as having moved to Civo. Google Cloud now holds the default United States region, the cross-region coordination database, real-time call media, call-recording storage, and most AI inference, and the live-call language model for European workspaces still runs in the EU.
- Atlassian Pty Ltd has been added for support. Our support desk moved to Atlassian Jira Service Management on 2026-08-15, and it receives your name, your email address, the subject and the full text of any support request you send us, along with the replies in that conversation. This is the one place where data does not stay in your workspace's region: one desk serves all four regions. We are confirming the hosting realm Atlassian holds our site in and will publish it here.
- Where a workspace chooses the linked support knowledge base, in place of the knowledge base it uploads itself, the text of each question asked is sent to Atlassian to compose the answer. That setting is off unless a workspace turns it on: the default keeps every question and every answer inside the workspace's own region.
- Zernio has been added, and it corrects the record set by our 2026-08-03 entry. That entry said our social publishing had moved onto each platform's own interface and that each platform would be listed on the day it began receiving our posts. Bluesky, Facebook, Instagram, Threads and LinkedIn are published directly, but X and Reddit are published through a relay we had not named, and the other platforms were never listed. No customer personal data is or was involved in any of it, but the statement was still wrong and it is corrected here.
- Three descriptions of how we protect data have been corrected on our compliance pages and in the Data Processing Agreement, because each was inaccurate rather than merely imprecise. Our databases are reachable on a network address restricted to our own servers, and we had described them as having no public endpoint at all. Database storage is encrypted by each hosting provider, and we had attributed all encryption at rest to Google Cloud's key service, which in fact protects stored third-party credentials. Our backup decryption key is held in a managed secret store separate from the company that stores the backups, and we had described it as being held outside the cloud entirely.
|
| August 9, 2026 | Grafana Cloud removed; New Relic added for infrastructure monitoring, held in the EULire la suite de cette entrée- Grafana Cloud has been removed as a sub-processor. Our Grafana Cloud account has been deleted and it no longer receives any telemetry from us.
- New Relic has been added in its place, on a New Relic account in the European Union region, so the operational telemetry it holds for us stays in the EU. This replaces a vendor that held the same category of data in Canada.
- What it is for is unchanged: watching whether our servers, databases and websites are up and performing, and alerting us when they are not. It is infrastructure monitoring, not analytics, and it is not used for advertising of any kind.
- What we send: operational telemetry from the machines and containers we run — resource usage, request and error counts, uptime probe results — together with logs from our own infrastructure, which include container logs from our application servers and system logs from the host machines (including the database service, the SSH service and the container runtime).
- What we do not send: call audio, transcripts, message content, or contact records. Application logs are scoped to operational diagnostics; where a log line necessarily identifies a request or an account, it may contain identifiers such as an account, workspace, or request identifier and an IP address, in the same way our error-tracking sub-processor already receives them.
- This entry records a change already made rather than advance notice of one. It substitutes one infrastructure monitoring provider for another over the same category of data and moves that data from Canada into the EU. If you have questions or an objection, write to legal@distronode.com.
|
| August 7, 2026 | Notice: adding Mixpanel for product analytics, held in the EULire la suite de cette entrée- Mixpanel, Inc. is being added as a sub-processor for product analytics, on a Mixpanel project with European data residency (api-eu.mixpanel.com), so the data it holds for us stays in the EU.
- This is notice of a change we are making, not a change already made. It takes effect no sooner than 30 days from this entry, and you can object in that window by writing to legal@distronode.com.
- What it is for: understanding how the signed-in District dashboard is actually used, so we can see which parts of the product work and which do not. Its scope is the signed-in dashboard only — it does not run on our marketing pages, and it is not used for advertising of any kind.
- First path, in your browser: a consent-gated analytics SDK that runs inside the dashboard. Where prior consent is required it does not load at all until you accept, and you can withdraw at any time using the Cookie preferences link in the site footer. It sets no cookies; it keeps its identifiers in browser storage (localStorage).
- Second path, from our servers: lifecycle events sent when an account is created, a workspace is created, a subscription is purchased, a workflow run completes, or a call is handled. That path involves no cookies and nothing loading in your browser, so it is not something a browser consent choice can govern; it is service telemetry about our own platform, and we are describing it here rather than leaving it unsaid.
- What we send, either way: product usage events keyed to a one-way SHA-256 hashed account identifier, the account email address on the user profile, and the workspace identifier, region, and plan tier.
- What we do not send: call audio, transcripts, message content, contact records, phone numbers, or IP addresses. IP geolocation is switched off in the configuration, so no approximate location is derived from your connection.
- On erasure: when an account is deleted, we forward a deletion request to Mixpanel through its data-deletion API, and it completes within 30 days.
|
| August 3, 2026 | Bluesky added; Postiz removed as social publishing moves in-houseLire la suite de cette entrée- Added Bluesky Social, PBC as a sub-processor for our own marketing. We are moving our social media publishing off a single scheduling intermediary and onto each platform's own interface, one platform at a time; Bluesky is the first to move, and our Bluesky posts now go to Bluesky directly rather than being relayed.
- Earlier in the day this entry recorded Postiz as still listed and still relaying every other platform, with both relationships genuinely existing at that point. We are leaving that record as written rather than rewriting it after the fact.
- Later the same day, Postiz was removed as a sub-processor. The account was closed and its access ended, and the code that sent anything to it has been deleted, so it no longer relays any platform for us.
- Publishing now goes to each platform's own interface directly. Each platform is listed here on the day it begins receiving our posts, and Bluesky remains the only one listed so far.
- As with every entry in this section, this concerns Distronode's own marketing content and no customer personal data — it never did.
|
| August 2, 2026 | Canadian and European workspace databases moved; LinkedIn added for ad measurementLire la suite de cette entrée- The Canadian workspace database moved from Google Cloud SQL onto Google Cloud compute we operate directly, on the same Montreal machine that already served the Canadian website and dashboard. Canadian data residency is unchanged: the database, its encrypted backups, and its point-in-time recovery archive all remain in Montreal, and Google Cloud remains the sub-processor. No customer data changed hands or crossed a border.
- In the same change, the retired Akamai / Linode cluster in Toronto was decommissioned, so Akamai / Linode no longer processes any Canadian data.
- Separately, and on the same day, the European workspace database moved off Google Cloud SQL in Frankfurt onto Civo compute in Frankfurt — the same European provider and city that already served the European website and dashboard. The region is unchanged; the provider changed, and Google no longer holds European workspace storage. Its nightly encrypted backup now runs in Frankfurt rather than being pulled to the United States first, and point-in-time recovery is provided by encrypted write-ahead logs.
- To be clear about what this does NOT change: live call media for European workspaces is still processed by Google Cloud in the United States (us-east4), the shared operational cache remains a single instance in the United States, and off-site encrypted backups are still stored with Cloudflare. European workspace storage is held in Frankfurt by a European provider; European data does not stay exclusively in Europe.
- Later the same day, LinkedIn was added as a sub-processor for advertising measurement of our own LinkedIn campaigns. Two mechanisms are involved: the LinkedIn Insight Tag, which records website events in your browser, and the LinkedIn Conversions API, which sends conversion events from our servers. Both are consent-gated and neither runs unless you have consented; where prior consent is required, nothing loads at all until you choose.
- What we send to LinkedIn is limited to website and conversion events, SHA-256 hashed email addresses, and LinkedIn's own first-party advertising cookie identifier. We do not send plaintext email addresses, IP addresses, or mobile advertising identifiers, and no call audio, transcript, or customer record is involved. This measures our marketing, not your use of the product.
|
| August 1, 2026 | Full audit of every claim on this page: vendors added, omissions and errors correctedLire la suite de cette entrée- Added Inworld (speech), Tavus (video avatars), SerpAPI (enrichment search), and Stape (server-side analytics gateway). Retired the legacy Clearbit enrichment fallback. Clarified that person-level enrichment returns professional contact details, and that the European media node and the EU live-call language model run in the EU — the media-node half of that clarification was itself wrong, and is corrected below.
- Later the same day, after a full code audit, added two sub-processors that were already in use and should already have been listed: Redis Ltd. (managed Redis for call signaling and short-lived operational state) and Google Analytics & Ads (consent-gated server-side conversion measurement). This corrects an omission rather than adding a new processor.
- Corrected four descriptions against the code: the Twilio lookup description (caller-ID and line type; we do not buy spam screening), the Sinch channel list (SMS, WhatsApp, and voice — no MMS), the Telnyx description (first-party carrier; adds MMS), and the Grafana Cloud region (Canada, not the EU). Newly disclosed in the same pass: legacy call-recording audio aging out of Cloudflare R2, and that phone numbers and contact names are sent to enrichment providers as lookup keys.
- Correction, and an apology. This page previously stated that Civo handled European call media from a European real-time media node in Frankfurt. That was wrong. No European media node exists or existed — all live call media, including for European workspaces, is processed by Google Cloud in the United States (us-east4), and Civo hosts the European website and dashboard origin only. The Redis entry carried the same error and has been corrected to name the US media node. We are sorry for the inaccuracy; the disclosure has been corrected, and an automated check now blocks any sub-processor from claiming to host call media unless a media node for it exists in code.
- In the same pass, the Canadian website and dashboard origin moved from Akamai / Linode in Toronto to Google Cloud in Montreal, placing the Canadian web tier in the same region and provider as the Canadian database. Canadian data residency is unchanged and remains in Canada.
- Redesigned the page: every sub-processor now leads with a plain-language summary, with the formal register attached to each entry.
|
| July 23, 2026 | Register first publishedLire la suite de cette entrée |
