Data, retention and privacy

This page exists for the conversation that happens before the integration: the one with legal, with the data protection officer, with whoever has to answer “what exactly leaves our house, and how long does it stay in yours?”.

It is honest in two directions. It states what the service does, with numbers; and it states clearly what it does not answer, so you never mistake silence for a promise.

---

1. What personal data the API receives

PushMesh asks for no document number, no name, no phone and no end-user e-mail. What it receives is the minimum needed to deliver a notification — and part of that is data you choose to send.

The most important privacy decision in this API is yours, not ours: what you put in external_user_id and in tags. An opaque account identifier keeps the base pseudonymised. A plaintext e-mail or a national ID number turns your push base into a personal data database — with every obligation that carries. Prefer the opaque identifier that only your system can resolve.

Note as well: the export file carries external_user_id, and what protects it is that the URL is impossible to guess. An export URL in a ticket, a chat or a log is a leak. It is valid for 72 hours.

---

2. How long each layer keeps data

Two consequences worth understanding before you build a report:

• Detailed delivery lookups have a deadline; aggregated numbers do not. If your report needs to know which devices received a campaign from two months ago, that granularity is no longer in the fast query. If it needs to know how many received it, it is — and always will be.
• The 90-day receipt window is not generosity. It covers the legitimate worst case: a schedule of up to 28 days plus a delivery deadline of up to 28 days, plus headroom, because the click may come from a notification that sat in the tray for weeks. A receipt arriving after the detailed row has cooled answers {"ok": true, "tardio": true} — it counts, through another path.

---

3. How to honour a deletion request

There is no public route that deletes a device, and the absence is deliberate: device routes are public by design, and a public route able to delete would be a public route able to empty your base.

What does exist, and is the official path:

A practical recipe for a data subject request, when you keep the external_user_id on your side:

1. Find that person’s devices — external_user_id is your index, and the export file carries the column.
2. Do the explicit logout (external_user_id: null) to cut the binding immediately, even before deletion.
3. Delete the devices in the dashboard. Their delivery trail goes with them.

Two honest notes:

• Deleting is not banning. A live device you deleted registers itself again the next time the app is used. To stop talking to someone, the tool is the binding (logout) or your own audience rule.
• Application deletion has a known limit, and it is stated here rather than hidden: images you uploaded to use in a push stay in object storage after the deletion. They stop being reachable (the only reference to them dies with the messages), but the file itself remains. Closing that gap is a recorded pending item.

---

4. What the service does not keep

• Your API key. Only a cryptographic digest of it lives in the database. Nobody — support included — can display it again.
• The key that signs receipts, the Firebase credential and the APNs .p8 are stored encrypted and never leave the server once saved.
• The credential presented in a rejected attempt. The audit record keeps, at most, the key’s public identifier — never the attempted key.
• Personal data in operational logs. Service logs work with identifiers and numbers; it is a project rule that personal data never enters them.

---

5. What this page does not answer

These points are not decided by the API, and inventing an answer here would be worse than having none. Ask for them in writing before signing:

• Where the data physically resides (storage region and country);
• Who the subprocessors are — beyond the obvious Google (FCM) and Apple (APNs), which are inherent to the product: without them there is no push;
• Availability commitment (SLA) and a status page;
• The full privacy policy and the definitive terms.

What is published today is in Privacy and Terms of use, and those pages state in plain words that the complete version comes before commercial launch. For the document your legal team needs now, write to contato@pushmesh.io.

Two things that are already a public commitment and are worth repeating here: we do not sell data, we do not build advertising profiles and we do not share your base with third parties; and delivery receipts exist to account for delivery to you, the owner of the base.

---

See also