Data processing agreement

Last updated: November 5, 2026

This DPA has 2 parts: (1) the Key Terms on this Cover Page and (2) the Common Paper DPA Standard Terms Version 1.1 posted at commonpaper.com/standards/data-processing-agreement/1.1/, which is incorporated by reference. Capitalized words not defined here have the meanings given in the Standard Terms.

How you accept it. You do not need to sign anything. This DPA is part of our Terms of service. By creating an everydeck account or using the Service, Customer electronically accepts the Agreement and this Cover Page, and the DPA applies whenever everydeck processes Customer Personal Data. If your organization needs a countersigned copy, write to support@everydeck.ai.

Key terms

Provider: XAVR LLC, a Wyoming limited liability company, operating everydeck. 30 N Gould St # 70950, Sheridan, WY 82801, USA.
Customer: The person or organization that holds the everydeck account, as identified in the account.
Agreement: This DPA supplements the everydeck Terms of service in force between Provider and Customer, as accepted by Customer when creating the account.
Approved Subprocessors: List of Subprocessors available at everydeck.ai/subprocessors.
Provider Security Contact: support@everydeck.ai, XAVR LLC, 30 N Gould St # 70950, Sheridan, WY 82801, USA.
Security Policy: The technical and organizational measures in Annex II below.
Service Provider Relationship: To the extent the California Consumer Privacy Act, Cal. Civ. Code § 1798.100 et seq. (“CCPA”) applies, Provider is Customer’s service provider and will not sell, share, retain, use or disclose Customer Personal Data for any purpose other than providing the Service, as further described in the Standard Terms.
Governing Member State: EEA Transfers: Ireland.
UK Transfers: England and Wales.

Annex I(A): List of parties

Data Exporter: Name: Customer.
Address and contact person: as provided in Customer’s everydeck account (the account owners).
Activities relevant to transfer: see Annex I(B).
Role: Controller, or Processor where Customer processes the data for its own customer.
Data Importer: Name: XAVR LLC (everydeck).
Address: 30 N Gould St # 70950, Sheridan, WY 82801, USA.
Contact: support@everydeck.ai.
Activities relevant to transfer: see Annex I(B).
Role: Processor.

Annex I(B): Description of transfer and processing

Service

everydeck, a backend for the apps Customer runs: people, objects, payments, errors, jobs and actions of the apps Customer connects, with a protocol of actions.

Categories of Data Subjects

Customer’s end users or customers (the users of the apps Customer connects). Authors of code changes in repositories Customer connects (GitHub login only).

Categories of Personal Data

Name and contact information, only when Customer sends them through identify() or chooses them in “What everydeck reads”: display name, email address, phone or WhatsApp number. By default the read bridge does not read email, phone or IP columns.
Identifiers: Customer’s own user and account references, sign-in method, sign-in provider user ID, organization name.
User activity and analysis: page views as route patterns, sign-ins, usage of objects (with the user only where the user consented in Customer’s app), session IDs, campaign source (UTM) and referring domain, device class and operating system, web vitals.
Transactional information: payment and refund events with amounts, currency and product (never card numbers), AI usage counts.
Records in Customer’s app that Customer chose: titles, statuses and approved fields of objects, including free-text fields unless Customer turns them off.
Technical data: errors with redacted messages and stack traces, failed requests (method, route, status), short redacted excerpts of source code and source maps, table and column names.
Messages between end users: not stored. Read live only when a Customer team member opens one conversation and gives a reason; the opening is logged without the text.

Special Category Data

No. Customer will not configure the Service to send special category data. If Customer’s approved fields nevertheless contain it, the measures in Annex II apply.

Frequency of Transfer

Continuous.

Nature and Purpose of Processing

Receiving, holding, using, protecting, sharing (with the Approved Subprocessors), returning (export) and erasing data, to provide the Service: showing Customer its apps’ people, objects, payments, errors and jobs; detecting and reporting problems; running actions Customer approves; and, only if Customer’s setup review is turned on, a one-time review of the setup by an AI model provider listed as a subprocessor.

Duration of Processing

Provider will process Customer Personal Data as long as required (i) to conduct the Processing activities instructed in Section 2.2(a)-(d) of the Standard Terms; or (ii) by Applicable Laws. Specific retention periods are in Annex II.

Annex I(C): Competent supervisory authority

The supervisory authority will be the supervisory authority of the data exporter, as determined in accordance with Clause 13 of the EEA SCCs or the relevant provision of the UK Addendum.

Annex II: Technical and organizational security measures

Encryption in transit: All connections to the Service use TLS; HSTS is enforced in production.
Encryption at rest: Access tokens and connection secrets are encrypted with AES-256-GCM using a versioned key held outside the database. App keys are stored only as SHA-256 hashes.
Separation and access control: Each workspace’s data is separated by enforced row-level security; the service account cannot bypass it. Team roles (owner, admin, support, agency, viewer) deny by default, and members can be limited to specific apps. Sign-in supports a second factor. Provider has no feature to sign in as a Customer.
Data minimization: The SDKs never send request bodies, headers, form values or query strings, remove emails and tokens from error messages, and send pages as route patterns. Provider removes them again before storing. The read bridge reads only approved tables and columns, keeps contact fields and IP addresses out by default, and stores no messages. Customer chooses what is read and can turn it off; turning it off deletes values already stored.
Event logging: Actions, data deletions and openings of conversations are written to an audit log and protocol. Server logs contain no request headers and redact tokens and secret path segments.
Limited retention: Raw events and page views: 30 days on the Free plan. Audit log and protocol: 90 days. Evidence of closed cases: 30 days; open cases: 90 days. Exports: 24 hours. Database backups: 7 days.
Portability and erasure: Customer can export all workspace data, delete a single end user’s data (with a deletion marker that blocks new data, using hashes for contact data), delete an app, or delete the workspace (24-hour undo window, then deleted; backups expire within 7 days).
Restoration: Daily database backups kept for 7 days. If a backup is restored, deletions recorded since then are applied again.
Subprocessors: Only the subprocessors on the list, each receiving only what its function needs.

The Cover Page follows the Common Paper Data Processing Agreement, free to use under CC BY 4.0. The Standard Terms are not modified.