ARCO procedures
Marea Alcalina is a Mexican corporation and is subject to LFPDPPP (Articles 16–18), the Mexican federal personal-data-protection statute. Every account holder has four enumerated rights — collectively ARCO:| Right | Spanish | What the user can do |
|---|---|---|
| Acceso | Acceso | Access a copy of their personal data |
| Rectificación | Rectificación | Correct inaccurate or incomplete data |
| Cancelación | Cancelación | Delete their account and all associated data |
| Oposición | Oposición | Object to specific processing of their data |
How users exercise ARCO
Access + Rectification (online, self-serve)
The dashboard at mareaalcalina.com/dashboard exposes:- Account email, displayName, language, currency, country, plan, verification status,
tosAcceptedAt. - Every storefront the account owns + its products.
- Each user key issued for the account (label, prefix, scopes, last used).
| Endpoint | Key | Returns |
|---|---|---|
GET /v1/me | mk_user_* / mk_dev_* | Identity + plan + rate-limit window + dashboard links |
GET /v1/users/:userId | mk_dev_* (developer scope) | The full user DTO for users the dev key bootstrapped |
GET /v1/users | mk_dev_* (developer scope) | Paginated list of users the dev key bootstrapped |
POST / PATCH), so for an LFPDPPP Acceso request that needs storefront contents, direct the user to the dashboard above. Rectification of catalog data goes through PATCH /v1/storefronts/:storefrontId (deep-merge, see Storefronts).
Cancellation (hard delete)
Three paths trigger an LFPDPPP-compliant hard delete:| Path | Triggered by | Idempotent |
|---|---|---|
| Dashboard “Delete account” button | User (interactive) | Yes |
DELETE /public/v1/bootstrap/:previewToken (or two-step GET confirm flow) | Bootstrap-email recipient | Yes |
Scheduled cleanup (30d_unverified or 90d_no_tos) | System | Yes |
- API keys — every
apiKeysdoc whereownerUid == :uid(batched, 500-per-batch). - Verification codes —
apiVerificationCodes/{email}. - Preview tokens — every
apiPreviewTokensdoc for this user. - Storefronts + products —
users/{uid}/menus/**recursive delete. - User document + subcollections —
users/{uid}recursive delete. - Audit trail — one append to
tosAcceptanceLogrecording reason + summary BEFORE the Auth delete. - Firebase Auth user —
auth().deleteUser(uid). Frees the email for re-signup. - Webhook fan-out —
user.cancelledevent (see Webhooks) with one of the lockedreasonvalues.
reason enum in the user.cancelled webhook:
| Value | Triggered by |
|---|---|
user_clicked_cancel | Public bootstrap-cancel endpoint |
squatting_defense | Email squatting defense (PRD-4) |
30d_unverified | Scheduled cleanup — never verified within 30 days |
90d_no_tos | Scheduled cleanup — verified but ToS not accepted within 90 days |
key_revoked | All other administrative or revocation-cascading deletes |
Opposition
To object to a specific processing activity (marketing, analytics, etc.) without cancelling the account, users may write to the contact channel below. Marea applies the change within the LFPDPPP-prescribed response window (20 business days from a verifiable request).Retention
- An active account is retained while it has a paid plan, has not invoked Cancelación, and has accepted ToS (or is within the 90-day window for agent-bootstrapped accounts).
- A hard-deleted account is removed from Firestore + Firebase Auth within the same job invocation. Orphan Cloud Logging entries decay per Google Cloud’s standard retention (default 30 days).
- A revoked API key stops authenticating within ~60 seconds end-to-end and is retained server-side for audit purposes only (the
keyHashis kept; the raw key was never stored).
Contact channel
LFPDPPP / LGPD requests not satisfied by the self-serve paths above should be sent to the contact email on the dashboard footer. Marea’s response SLA matches LFPDPPP statutory timelines (20 business days; 15 days for follow-ups).What an agent should know
- Never create an account on behalf of a user who has not authorized it. The cancel hatch protects misuse, but the user-rights regime treats unauthorized creation as a violation by the creating party.
- If the agent receives
user.cancelled(any reason) for a user it bootstrapped, the agent must stop all downstream automation for that user and delete any local cached state. - The agent cannot accept the ToS on the user’s behalf. See ToS jurisdiction for the 451 flow.
Verification in code
src/api/public/bootstrap.cancel.ts— public unauthenticated cancellation endpoint (preview-token auth).src/api/services/account-delete.service.ts—hardDeleteUserAccountordering + audit-log write.src/api/scheduled/CleanupUnverifiedAccounts.ts— 30d / 90d sweep policy.src/api/services/webhooks.service.ts—user.cancelledevent +CancelReasonenum.