allpass legal
Privacy Policy
What allpass processes when you visit, sign in, add credit and use provider services.
Last updated:
1. Who is responsible
allpass is a product name of CHGROUP – FZCO, a free zone company registered in the United Arab Emirates, at Dubai Silicon Oasis, IFZA Business Park, Building A2, Nadd Hessa, PO Box 342001, Dubai, United Arab Emirates. CHGROUP – FZCO operates allpass. We are the controller for personal data used to run our website, manage accounts, take payments and protect the service. Contact support@bychgroup.com about privacy, or support@bychgroup.com about other matters.
This policy covers visitors, account holders and organization members. The next section explains our different role when a customer uses allpass to process another person's data. Provider access is phased. A listed future integration does not receive your data merely because it is listed.
2. Customer end-user data and the DPA
When you send email or SMS to your users, or store their data in a resource we arrange, you generally decide why and how that data is used. You are the controller, or a processor acting for another controller. allpass generally acts as your processor or subprocessor for that work. This includes recipient addresses, phone numbers, message content and customer database or storage content.
We process that data to carry out your instructions, supply the chosen service and protect its operation, subject to law. We act separately as controller for account administration, billing, fraud prevention and legal obligations. A provider can also have an independent controller role for its own legal or payment duties.
If you need a Data Processing Agreement (DPA), contact support@bychgroup.com and we will provide one. Ask for it before you submit personal data that requires one. This policy is not a substitute for a DPA. The DPA addresses instructions, confidentiality, security, breach support, rights requests, subprocessors, audits, deletion or return and international transfers.
If you are a customer's email recipient, SMS recipient or app user, contact that customer first to exercise rights over its data. We will help the customer respond under the agreed DPA and applicable law.
3. Information we collect
- Account and organization data: your email, name, verification status, profile image if supplied, organization name and slug, member roles, invitations, projects and account status. We also receive information you send in support requests or an account review.
- Sign-in data: a password hash if you choose a password, hashed magic-link tokens, verification records, session tokens and expiry times, session IP address, browser user agent and active organization. Rate-limit records store request keys, counts and last-request times.
- Google or GitHub sign-in: the linked provider and account identifier, basic profile such as name, email and image, granted scopes and OAuth access, refresh or ID tokens where returned. These options work only when configured. We do not receive your Google or GitHub password. Account sign-in does not itself authorize us to read private repositories or email inboxes.
- Payments: Stripe receives payment details through hosted Checkout. allpass never sees your full card number or security code in this flow. We receive payment and checkout identifiers, amount, currency, payment status and the account and wallet references needed to credit you. Stripe handles card data and its own fraud checks.
- Service administration: API key identifiers, verifiers, scopes and limits; resource and provider IDs; domain and DNS verification records; assigned SMS numbers and profiles; resource configuration and usage measurements. Stored provider credentials are encrypted where our credential store is used. Full allpass API key secrets are not stored.
- Requests and billing: request IDs, project, provider, provider message ID, price-book version, times, result status, usage quantities, holds, charges, releases and ledger history. A receipt lets you trace an operation without being a copy of the message you sent.
- Technical data: connection IPs, request paths, error details, timing and security events processed by our hosting and authentication systems. The website also uses cookies, Google Analytics 4 and Google-hosted fonts as described below.
We collect information from you and your members, from apps and agents using your keys, and from authentication, payment and service providers. If SMS registration becomes available, required business and sender information must be collected through its onboarding flow.
4. Messages, direct resources and stored responses
Email addresses, headers, subject and message body pass through our gateway to SES or Resend for delivery. SMS sender and recipient numbers and text pass through to Telnyx or Plivo when enabled. Providers process the content and delivery records under the applicable service arrangements. Recipients, mail systems and mobile carriers also receive what is needed to deliver the message.
The gateway parses request bodies in memory to validate and price a send. It does not normally persist the outgoing message body as a separate message archive. It stores request and billing metadata. For retry protection with an Idempotency-Key, it stores a request fingerprint and the full accepted provider response for 24 hours. A provider response, especially an SMS response, can include numbers or echoed message text. That content is therefore stored too. Expired retry records are removed by the wallet alarm.
Operational logs are intended to contain metadata, not message bodies. Secret redaction covers credentials and connection strings. Provider errors can still contain personal data. Avoid putting unnecessary personal data in resource names, URLs, error text or idempotency keys.
For direct databases, file storage and running hosting traffic, your app or visitors connect to the provider. Routine queries, files and visitor requests do not pass through the allpass gateway. We still process setup and control information, credentials where needed, and usage or billing records. Our provider-account access means we cannot promise that allpass has no administrative access to a resource.
5. Purposes and GDPR legal bases
Where the EU GDPR or UK GDPR applies, we rely on these legal bases:
| Purpose | Basis |
|---|---|
| Create accounts, authenticate you, arrange services, take top-ups and provide support | Contract, or steps you request before a contract. For members of a business customer, legitimate interests in administering that customer's service. |
| Meter usage, hold funds, produce receipts and reconcile charges | Contract and legitimate interests in accurate billing; legal obligation where financial record laws apply. |
| Prevent fraud and abuse, apply rate limits, investigate incidents and protect shared provider access | Legitimate interests in protecting users, recipients and the service, balanced against your rights. Legal obligation where required. |
| Keep tax or payment records and respond to lawful orders | Legal obligation under the laws that apply to the operator. |
| Measure website use with optional analytics cookies | Consent where required. |
Necessary account, payment and security notices are part of running the service. A separate marketing program would need its own notice and lawful basis. We do not use customer message content to train an allpass AI model. An agent you choose has its own data practices, so review them before sharing credentials or content with it.
6. Cookies, analytics and fonts
Authentication uses Secure, HttpOnly, SameSite=Lax cookies to keep you signed in and support authentication flows. Blocking these cookies can prevent sign-in. Sessions have expiry timestamps; a cookie's expiry does not by itself erase the server's session record.
The site loads Google's GA4 script with measurement ID G-PNYFF168MF. Tracking is configured only on allpass.dev. The script request itself still goes to Google on other hosts. Configuration disables Google signals and ad-personalization signals. This is not a declaration that analytics is anonymous or cookie-free.
GA4 can use first-party cookies such as _ga to recognize a browser and measure visits, sessions, approximate location and device or browser information. Page URLs and referrers may be included in measurement. Do not put personal data in public page URLs. Google's analytics collection guidance explains its default collection.
Where the law requires consent for analytics cookies, we ask before setting them and you can withdraw at any time as easily as you gave it. Browser cookie controls and Google's Analytics opt-out tool can limit collection now. Deleting a cookie does not delete records already received.
Fonts load from fonts.googleapis.com and fonts.gstatic.com. Your browser connects to Google for those files and sends normal connection information, including its IP address. Optional Google or GitHub sign-in sends you to that provider's authentication service.
7. Subprocessors and other service providers
The table covers platform infrastructure and every provider integration, including those that are not yet available. A provider processes customer content only when the relevant service is enabled and used. Google and GitHub sign-in and some Stripe processing involve independent controller roles. These are not all solely subprocessors.
Locations below describe regions supported by the integrations or locations that are not fixed in advance. They are not a production residency guarantee. A regional resource can still involve global support, control-plane or security processing. Exact legal entities, downstream subprocessors and transfer terms are set out in the DPA and our provider agreements.
| Provider | Purpose and data | Availability | Location |
|---|---|---|---|
| Cloudflare | Site, API and gateway hosting; account database, wallet storage, caches and operational logs. | Platform infrastructure. Customer Cloudflare services are outside the launch set and need permission. | Global edge. Actual database, wallet, log and backup locations need confirmation. |
| Stripe | Hosted checkout, payment processing, fraud checks and payment references. Some processing is as an independent controller. | Payments. Stripe Connect is not offered by this integration. | Payment processing locations need confirmation under the Stripe agreement. |
| Amazon Web Services (SES) | Account verification and sign-in email; customer email delivery, addresses, message content and sending-domain setup. | Planned launch provider; customer sends depend on enablement and quotas. | SES adapter lists US East, US West, Ireland, Frankfurt and Stockholm. Selected project Region is Stockholm (eu-north-1); production routing needs confirmation. |
| Resend | Customer email delivery, recipients, message content, sending domains and delivery metadata. | Planned launch provider; shares an allpass team reputation. | Adapter regions: US East, Ireland, São Paulo and Tokyo. Actual sending region needs confirmation. |
| Neon | Customer Postgres databases, connection credentials, project setup and usage measurements. | Planned launch provider; paid-plan usage verification remains open. | Adapter regions: US East, US West, Frankfurt, London and Singapore. Actual project region depends on provisioning. |
| Vercel | Customer hosting projects, deployment content, configuration, visitor traffic and usage measurements. | Planned launch provider; written Platforms permission remains open. | Global delivery. Project processing, logs and support locations need confirmation. |
| Telnyx | SMS delivery, sender numbers, recipient numbers, message text, messaging profiles and registration data when required. | Available later; live verification and sender onboarding remain open. | Adapter says global; initial destinations are US and Canada. Processing and carrier locations need confirmation. |
| Plivo | SMS delivery, sender and recipient numbers, message text, project subaccounts and delivery cost records. | Available later; live verification and resale confirmation remain open. | Adapter says global; initial destinations are US and Canada. Processing and carrier locations need confirmation. |
| Aiven | Customer PostgreSQL services, credentials, configuration and usage records. | Available later; resale confirmation remains open. | Adapter supports DigitalOcean Frankfurt and Google Cloud europe-west1. |
| Supabase | Customer database projects and associated project keys, configuration and usage records. | Available later; Platforms agreement and safe paid-plan stop remain open. | Adapter regions: Stockholm, Frankfurt and US East. No production project location verified. |
| Bunny.net | Customer file storage, storage-zone credentials and usage statistics. | Available later; resale confirmation and live verification remain open. | Adapter regions: Germany, New York, Los Angeles and Singapore. |
| DigitalOcean | Customer virtual servers, SSH public keys, snapshots and usage records; also an underlying Aiven hosting option. | Direct server service available later; resale confirmation remains open. | Adapter regions: New York, San Francisco, Amsterdam, Frankfurt, London, Singapore, Toronto, Bangalore and Sydney. |
| Backblaze B2 | Customer object storage, scoped bucket credentials and usage records. | Available later; partner agreement and live verification remain open. | Adapter region: us-west-004 (US West). |
| Wasabi | Customer object storage, bucket credentials and active or deleted-storage billing records. | Available later; partner agreement, regional pricing and live verification remain open. | Adapter region: us-east-1 (US East). |
| Redis Cloud | Customer Redis databases, connection credentials, access restrictions and subscription usage records. | Available later; partner agreement, plan allocation and live verification remain open. | No region specified in the adapter. Confirm before enabling. |
| Optional Google sign-in; GA4 website analytics; hosted web fonts. Google also provides an underlying Aiven hosting option. Roles vary by service. | Fonts and analytics script on the site; sign-in only when configured; Aiven available later. | Web and sign-in processing locations need confirmation. Aiven uses europe-west1; this does not locate other Google processing. | |
| GitHub | Optional account sign-in and linked identity information. GitHub also acts as an independent controller for its own service. | Sign-in only when configured. | Identity processing locations need confirmation under GitHub terms. |
The customer controls message recipients and direct-resource content. We may disclose relevant records when law requires it, to investigate fraud or protect rights, or as part of a business transfer with appropriate safeguards. We do not offer customer lists or message content for sale. Website analytics disclosures still need a sale or sharing assessment under California law; disabled ad-personalization settings alone do not settle that question.
8. International transfers
Using global hosting, email and SMS providers can move personal data outside your country, including outside the EEA or UK. A chosen resource region does not cover every processing activity.
Where the law requires safeguards for international transfers, we use the European Commission's Standard Contractual Clauses (SCCs), or an applicable adequacy decision, with a transfer assessment and supplementary safeguards where required. For UK transfers we use the UK Addendum or the International Data Transfer Agreement.
Contact support@bychgroup.com for applicable safeguards or a copy, subject to appropriate redaction. The European Commission explains SCCs.
9. Retention and deletion
We keep information only as long as the periods below allow, unless the law requires longer.
| Data | Retention period |
|---|---|
| Gateway retry fingerprint and accepted response | 24 hours from creation, then removed by the wallet alarm. Any echoed numbers or content in the response share that period. |
| Account profile, organization and OAuth records | While needed for the account, then deleted or de-identified within 30 days after closure and settlement, except records kept for legal duties. |
| Sessions, verification records, invitations and rate-limit counters | Valid until their recorded expiry or applicable authentication window. Removed within 30 days after expiry, revocation or last rate-limit activity. The rate-limit window is 60 seconds; it is not a database deletion timer. |
| Operational logs, IPs and request receipts without financial records | Routine logs are kept for 30 days and request receipts for 90 days. Incident evidence may be kept until the investigation ends, then up to 2 years where needed for a claim. |
| Security and administrative audit records | Kept for 2 years. |
| Ledger, payment references, invoices and tax records | Kept for 7 years after the end of the relevant financial year, or longer where the operator's legal obligations require it. The ledger is append-only; a privacy deletion request does not automatically erase accounting history. |
| Support correspondence | Kept for 2 years after the request is resolved, unless an active dispute requires longer. |
| GA4 event and user data | Google Analytics data is kept for 2 months, with no reset on new activity. Aggregated reports can follow different rules. |
| Customer resources and retained content | Until you delete them or the funded retention process ends. The reserve uses 14 days of estimated retention cost; actual duration depends on funds and cost. Deletion for lack of funds starts no earlier than 72 hours after the final closing notice. |
| Backup copies under our control | Backup copies are removed within 90 days after primary deletion. Backups exist for our operational use. We do not guarantee that a backup is available or that data can be recovered from it. |
Deleting an organization currently removes its membership link but retains catalog and ledger history. Its wallet must first have no available or held funds. Contact us for a full closure or privacy request. Provider copies and recipients' copies are separate; we cannot recall a delivered message.
We may keep records longer where law or a specific legal hold requires it. We restrict access to that purpose and remove the records when the need ends. Provider-specific deletion and backup periods are set out in the DPA.
10. Security
Our implementation uses HTTPS service endpoints, secure session cookies, role and project checks, scoped API keys, spending limits and authentication rate limits. API key checks use HMAC verifiers instead of stored key secrets. The provider credential store uses authenticated encryption tied to the project and purpose. Error redaction removes known secrets and connection strings.
These controls reduce risk but do not guarantee complete security. Protect your own keys, limit member access and keep independent backups. Report suspected exposure to support@bychgroup.com. Our DPA must set incident cooperation and breach notification duties before customer personal data processing that requires it begins.
11. Your rights and how to use them
Where EU GDPR or UK GDPR applies, you may request access, correction, erasure, restriction or a portable copy of your data, subject to legal conditions. You may object to processing based on legitimate interests and withdraw consent at any time without affecting earlier lawful processing. You may complain to your local supervisory authority or the UK Information Commissioner's Office.
California residents have CCPA/CPRA rights where that law applies: to know and access collected information, correct inaccuracies, request deletion, opt out of sale or sharing, limit qualifying uses of sensitive personal information and receive equal service without unlawful discrimination. You may use an authorized agent. Where required, we honor opt-out requests, including Global Privacy Control signals. See California's explanation of these rights.
To make a request, email support@bychgroup.com or write to CHGROUP – FZCO, Dubai Silicon Oasis, IFZA Business Park, Building A2, Nadd Hessa, PO Box 342001, Dubai, United Arab Emirates. Identify your account and the right you want to use. Do not send passwords, API keys or full card details. We may verify your identity and an agent's authority using proportionate information. We will explain any refusal or legal exception.
We aim to respond within one month for GDPR requests and 45 days for qualifying California requests, with any permitted extension explained. Some opt-out requests have shorter deadlines. Rights are not absolute, and necessary accounting or legal records may be retained. Requests about customer-controlled end-user data should go to that customer; we assist as processor.
Account review, rate limits and spending controls can restrict service. Contact us to ask for a human review of a disputed restriction.
12. Children
allpass accounts are for people aged 18 or older. We do not direct account registration to children or knowingly collect children's account data. If you believe a child created an account, contact support@bychgroup.com so we can investigate and remove data as required.
Customers remain responsible for lawful handling of any children's data in their own applications, including consent and provider restrictions. An adult account does not by itself make a service suitable for that data.
13. Changes and contact
We will post changes here and update the date. For material changes, we will give an email or account notice before they take effect where practical and obtain consent where law requires it. A new purpose for existing data needs its own lawful basis.
Privacy questions and requests: support@bychgroup.com. General and legal questions: support@bychgroup.com. Postal address: CHGROUP – FZCO, Dubai Silicon Oasis, IFZA Business Park, Building A2, Nadd Hessa, PO Box 342001, Dubai, United Arab Emirates. We have not appointed a data protection officer. If you are in the EEA or the UK, you may also complain to your local data protection authority.