Ridgital Relay Service Schedule

Last updated: 14 July 2026

This Ridgital Relay Service Schedule (the “Schedule”) contains product-specific terms for Ridgital Relay (“Relay”). It supplements and is incorporated into Ridgital’s Terms & Conditions, Privacy Policy, and Refund Policy (the “Master Policies”). By activating, accessing, or using Relay, Customer agrees to this Schedule.

1. Scope and precedence

This Schedule applies only to Relay. Capitalized terms not defined here have the meanings given in the Master Policies. If this Schedule conflicts with a Master Policy, this Schedule controls for Relay-specific technical, acceptable-use, data-processing, retention, suspension, and refund matters. An applicable signed agreement, order, or data processing agreement may contain more specific terms.

2. Relay Service

Relay is a multi-tenant platform for transactional email submission, delivery processing, lifecycle visibility, bounce and suppression management, privacy-aware engagement tracking, webhooks, usage reporting, and related integration and compliance functions.

Authorized Customer applications may submit messages through a versioned API or authenticated SMTP interface. Depending on the active package, Relay may provide message identifiers, status and event timelines, delivery and deferral information, bounce details, tenant-scoped suppression lists, open and click outcomes, webhook notifications, usage information, exports, and recipient deletion workflows.

Relay may deliver accepted messages through an outbound SMTP server or email provider configured or authorized by Customer. Relay is the orchestration and lifecycle layer; the configured provider remains responsible for accepting the outbound SMTP transaction and for the provider-side processing it performs under Customer’s agreement with that provider.

Relay is an email delivery and lifecycle visibility platform. It is not a marketing automation, campaign builder, contact-management platform, behavioral-profiling service, advertising-tracking service, or general-purpose open mail relay.

3. Tenant accounts, users, and roles

Each Customer operates within a logically isolated tenant. Users, credentials, applications, messages, events, webhooks, suppressions, usage records, and compliance requests are associated with that tenant. Customer-facing access is restricted by user role, permission, and tenant ownership.

Customer is responsible for authorizing users, assigning appropriate roles, disabling unnecessary access, protecting accounts, and ensuring that only authorized persons manage API keys, SMTP credentials, webhooks, suppressions, exports, deletion requests, and organization settings.

Standard Customer users may receive operational visibility permitted by their role, while Customer administrators may manage tenant users, applications, credentials, webhooks, suppressions, exports, deletion requests, and organization settings where the active package and interface allow. No Customer role authorizes access to another tenant.

4. API, SMTP, and credentials

API keys, SMTP credentials, sessions, and webhook secrets are confidential. Customer must use secure transport, restrict access, store secrets securely, and rotate or revoke credentials when compromise is suspected. Credentials must not be published, embedded in public client-side code, shared across unrelated tenants, or used to bypass authentication, authorization, quotas, or rate limits.

Complete API keys and webhook secrets may be shown only when created and may not be recoverable later. API keys and SMTP credentials belong to exactly one tenant. Ridgital may disable or revoke credentials where reasonably necessary to protect Customer, recipients, other tenants, deliverability, or the platform.

Relay uses two distinct SMTP concepts:

• SMTP submission credentials authenticate a Customer application when it submits a message to Relay. Successful submission confirms acceptance for asynchronous processing only.
• Outbound SMTP configuration identifies the Customer-authorized server or email provider through which Relay attempts delivery and may include host, port, username, transport-security settings, sender configuration, and a protected password, token, or other provider credential.

Customer authorizes Relay to use the outbound configuration and transmit the message, sender and recipient addresses, headers, and content to the configured provider for delivery. Customer is responsible for the provider account, authorization, sender permissions, domain and mailbox configuration, provider terms, provider quotas, credential rotation, and the legality of that transfer. Relay requires encrypted transport where supported and does not permit plaintext transmission of submission passwords.

Before acceptance or processing, Relay may validate credentials, tenant ownership, sender and recipient syntax, authorized-sender rules, message size, package entitlement, quota, and rate limits. Syntax validation does not verify that a recipient mailbox exists or will accept a message. Invalid, unauthorized, oversized, over-quota, rate-limited, revoked, disabled, or expired submissions may be rejected before entering the delivery pipeline.

User passwords and SMTP submission passwords must not be stored in plaintext. Complete secret values are not included in ordinary lists, logs, exports, dashboards, or support responses. Multi-factor authentication, single sign-on, webhook replay protection, and other advanced authentication capabilities are available only if expressly identified as current features.

5. Packages, features, quotas, and limits

Each Relay tenant has one active package. The package may define:

• daily and monthly email quotas;
• API request and rate limits;
• SMTP message, connection, concurrency, and authentication-attempt limits;
• user, application, API-key, and SMTP-credential limits;
• webhook, event-delivery, and retry limits;
• message, event, engagement, and webhook-log retention;
• available features, integrations, and support level; and
• other resource or security limits shown in the package or documentation.

Submissions or requests exceeding an applicable limit may be rate-limited or rejected. Unused quota does not carry over unless the package expressly says otherwise. A downgrade may require Customer action if existing users, applications, credentials, webhooks, data, or other resources exceed lower limits.

Package upgrades, downgrades, quota changes, retention changes, and feature overrides may change future processing and access. Unless an order states otherwise, an upgrade applies when activated, while a downgrade normally applies from the stated future period and may be delayed until incompatible excess resources are resolved. Relay does not promise paid overage processing unless an overage price and behavior are expressly disclosed.

6. Asynchronous submission and message lifecycle

Relay processes message delivery asynchronously. A successful API response or SMTP acceptance confirms only that Relay accepted the message for processing. It does not confirm delivery, inbox placement, delivery time, opening, clicking, or another recipient action.

Subject to processing outcomes, a message may move through statuses such as Submitted, Accepted, Processing, Delivered, Deferred, Bounced, Suppressed, and Expired. Relay’s event store and status information are the authoritative sources for recorded message state. Customer must not treat submission acceptance as proof of delivery.

Where an idempotency mechanism is offered, Customer must use it as documented to reduce duplicate submissions. Retries performed by Customer without the documented idempotency mechanism may create additional messages, charges, events, or deliveries. Relay may retry temporary delivery failures according to platform or package policy, but it does not promise that every deferred message will be retried or ultimately delivered.

While retained, lifecycle events represent immutable historical facts. Relay does not silently rewrite an event; a correction or later outcome is represented by a new event. Event records may include an event ID, event type, tenant ID, message ID, timestamp, source, schema version, and event-specific metadata. Customer-facing searches may use documented fields such as message ID, recipient, sender, status, application, event type, and date range, but email-body, attachment-content, and general full-text content search are not supported.

Email outcomes depend on recipient data, receiving mail servers, sender reputation, content, authentication and domain configuration, network conditions, provider policies, and other factors outside Ridgital’s reasonable control. Ridgital does not guarantee delivery, inbox placement, delivery time, or engagement.

7. Lawful transactional sending

Customer must use Relay only for legitimate transactional communications and other sending expressly permitted by the applicable package or written agreement. Customer must not:

• send spam, unsolicited bulk email, unlawful marketing, or messages to purchased, harvested, scraped, or unlawfully obtained address lists;
• send without a valid legal basis, required notice, permission, or relevant relationship;
• impersonate another person or organization, forge sender information, engage in phishing, or mislead recipients;
• transmit malware, malicious code, fraud, harassment, threats, or unlawful or infringing content;
• circumvent a bounce, suppression, compliance, security, quota, or rate-limit control; or
• repeatedly submit known invalid, objecting, unsubscribed, or prohibited recipients.

Customer must maintain accurate sender and recipient information, comply with applicable consent, notice, objection, and opt-out requirements, and act appropriately on bounce, complaint, and suppression information.

Customer is responsible for ensuring that a transactional purpose genuinely exists and that each message’s sender identity, subject, content, links, tracking behavior, and routing information are not misleading. Relay controls are not a substitute for Customer’s own consent, objection, complaint, unsubscribe, recordkeeping, or legal-compliance processes.

8. Relay Customer Content

Relay Customer Content may include sender, recipient, and reply-to addresses; subject; text and HTML bodies; technical headers; tags; custom metadata; application identifiers; webhook destinations; and related instructions.

Customer is responsible for message content, sender identity, recipient selection, lawful basis, required privacy notices, tracking disclosures and consents, and responses to recipient rights requests. Customer grants Ridgital the rights described in the Master Terms to validate, queue, route, technically modify, transmit, deliver, track, store, retain, suppress, export, and delete Relay Customer Content as necessary to provide Relay and follow authorized instructions.

For recipient information and message content submitted by Customer, Customer generally acts as controller or equivalent responsible party and Ridgital generally processes that data on Customer’s behalf. Ridgital acts independently for account administration, billing, security, abuse prevention, legal compliance, and operation of its own business. A data processing agreement may apply where required.

Attachments, templates, scheduled sending, managed sender-domain verification, and other roadmap content features are not supported merely because an API field, database model, planning document, or future specification mentions them. They form part of Relay only when shown in current public documentation or the active package.

9. Bounces and suppressions

Relay may classify delivery failures as hard or soft bounces. Relay may automatically suppress a recipient after a hard bounce, repeated bounce activity, compliance action, or another platform-defined deliverability condition. Authorized Customer administrators may create or remove tenant-scoped suppressions where permitted.

Bounce and complaint information may be obtained from the configured outbound provider, delivery responses, delivery-status notifications, feedback-loop reports, or other supported sources. Classifications and human-readable reasons depend on the information available from those sources and may be incomplete or normalized by Relay.

A suppression prevents future delivery attempts within the applicable tenant until removed through an authorized workflow. Suppressions do not affect unrelated tenants. Customer must not evade a suppression or repeatedly submit known invalid or prohibited addresses.

Suppression records are operational and may remain active independently from normal message-retention periods until removed manually, administratively, or through a compliance workflow.

A recipient deletion or objection workflow may create or preserve a minimal compliance suppression so that deleted or objecting recipients are not contacted again. Removing an automatic, manual, administrative, or compliance suppression may be restricted, require additional authorization, or be refused where continued suppression is reasonably necessary for law, safety, abuse prevention, or sender reputation.

10. Privacy-aware open and click tracking

If engagement tracking is included and enabled, Relay may technically modify HTML content by adding a tracking pixel and may rewrite eligible links through a tracked redirect. A pixel request may record an open, and activation of a tracked redirect may record a click. Engagement records may include event ID, tenant ID, message ID, recipient, event type, timestamp, and an outcome such as “Opened = True” or “Clicked = True”.

The Relay engagement subsystem is designed not to store the recipient’s IP address, user agent, browser, operating system, device information, device or browser fingerprint, geolocation, country, city, region, ISP, ASN, network fingerprint, behavioral profile, or advertising identifier.

This restriction concerns recipient engagement events. Separate security and access logs for the website, portal, API, or SMTP interface may process an account user’s or connecting system’s IP address and request information for authentication, abuse prevention, troubleshooting, and security.

Open and click information is an operational indicator, not conclusive evidence of an individual’s behavior. Image blocking, caching, security scanners, link rewriting, automated systems, and similar technologies may cause events to be missing, delayed, duplicated, or generated without deliberate recipient action.

Customer is responsible for deciding whether tracking is lawful and appropriate for each message and recipient, providing required notice, obtaining any required consent, and disabling or avoiding tracking where it lacks a lawful basis. Relay engagement tracking must not be used for covert surveillance, profiling, advertising tracking, device tracking, or geolocation tracking.

11. Webhooks and Customer systems

Customer is responsible for the accuracy, security, availability, and lawful operation of webhook endpoints and connected systems. Customer should validate signatures where available, protect webhook secrets, verify payload integrity and timestamps, and ensure endpoints can receive events safely.

A webhook payload may contain an event ID, event type, tenant ID, message ID, timestamp, event-specific data, delivery status, bounce or suppression information, engagement outcome, recipient or sender information, and other fields documented for the subscribed event. By configuring an endpoint, Customer instructs Ridgital to disclose those payloads to that endpoint and is responsible for endpoint recipients, access controls, logs, downstream retention, and any onward processing.

Webhook delivery is asynchronous and must not be treated as the system of record. Failed deliveries may be retried under the applicable platform or package policy, but delivery is not guaranteed. Ridgital may limit, disable, or suspend an invalid, insecure, persistently unavailable, abusive, or operationally harmful endpoint.

Relay may retain webhook names, endpoint URLs, status, subscribed events, secret metadata, request timestamps, response codes, response times or processing durations, attempt numbers, retry counts, failures, and delivery results. Complete webhook secrets are not displayed after creation. Compliance-event webhooks, advanced retry controls, replay APIs, versioning, and endpoint-health features are available only when expressly documented as current.

12. Relay data, retention, and compliance workflows

Relay may process message content, metadata, lifecycle events, delivery attempts, bounce details, suppressions, engagement events, webhook configuration and logs, usage records, credentials metadata, compliance requests, operational logs, and audit records as described in the Privacy Policy.

Message content, message metadata, lifecycle events, engagement events, and webhook logs are retained according to the active package and then automatically expired or deleted. Exact values shown in package materials control. Suppression, audit, authentication, security, payment, operational, and compliance records may follow different retention periods.

Authorized Customers may request data exports, recipient exports, recipient deletion, and compliance suppressions through available portal or API workflows. Requests are subject to identity, authorization, tenant ownership, technical feasibility, platform policy, and legal retention obligations.

A recipient export may include message metadata, lifecycle events, engagement events, bounce information, suppression information, and webhook activity associated with the verified address, depending on available data and retention. An export does not reveal complete passwords, API keys, SMTP credentials, outbound-provider secrets, webhook secrets, private encryption material, another tenant’s data, or security information that would create an unreasonable risk.

A verified recipient deletion may remove retained message content, metadata, lifecycle history, and engagement history associated with that address, subject to technical feasibility and legal requirements. It may not remove immutable audit evidence of the request, payment or account records, security and abuse-prevention records, records Ridgital must retain by law, data already controlled by Customer or a configured third-party provider, or a minimal compliance suppression needed to prevent future sending.

Retention expiration is not necessarily immediate at the exact end of a period; deletion occurs through scheduled cleanup processing. During cleanup, records may briefly remain inaccessible or pending deletion. Retention failures are logged and monitored. Customer must export required information before expiration, downgrade, cancellation, or termination.

13. Tenant isolation and administrative access

Relay enforces tenant ownership across accounts, credentials, messages, events, webhooks, suppressions, analytics, usage, and compliance workflows. A Customer must not attempt to access another tenant’s data or cause cross-tenant processing.

Ridgital administrative access is role-restricted and auditable. Administrative tools are designed around message ID, sender, recipient, tenant, status, event, delivery, bounce, suppression, and operational metadata. Full-text searching of email bodies or attachment content is not supported.

Support administrators may access account information, delivery activity, webhook activity, bounce information, and other operational metadata needed to investigate a request. Operations administrators may access service, queue, event, and incident information. Platform administrators may perform authorized customer, package, retention, security, and compliance operations. Role assignment does not silently bypass tenant isolation, and sensitive administrative actions and investigations generate audit records.

14. Relay suspension and protective action

In addition to the Master Terms, Ridgital may restrict sending, processing, credentials, webhooks, or the Relay account because of excessive bounces, spam complaints, unlawful or abusive sending, sender-reputation harm, attempted suppression evasion, credential misuse, invalid endpoints, quota exhaustion, security risk, or risk to deliverability, platform infrastructure, providers, recipients, or other tenants.

Where practicable, Ridgital will provide notice and an opportunity to remedy the issue. Immediate action may be taken where reasonably necessary to prevent ongoing harm, unlawful activity, provider blocking, security compromise, or cross-tenant risk.

15. Relay-specific refund limitations

In addition to the Refund Policy, Relay fees are generally not refundable because messages are deferred, bounced, suppressed, rejected, delayed, delivered to spam, not opened, or not clicked, or because a receiving mail system rejects or filters a message. Unused email, API, SMTP, webhook, retention, or other package capacity is generally non-refundable.

Refunds are also generally unavailable for outcomes caused by invalid recipient data, sender reputation, Customer content, domain or sender configuration, Customer credentials or systems, unavailable webhook endpoints, image blocking, link scanning, network conditions, receiving-provider policies, quota enforcement, or Customer breach.

16. Roadmap and unsupported features

Unless expressly included in the active package or confirmed in writing, roadmap capabilities are not part of Relay. Possible future features such as advanced domain verification, managed DKIM/SPF/DMARC, templates, scheduling, dedicated infrastructure, advanced analytics, multi-region options, MFA, SSO, advanced event replay, message attachments, AI-assisted operations, or other enterprise features are not current commitments merely because they appear in planning materials.

Compliance-event webhooks, legal hold, retention exceptions, customer-managed keys, compliance certifications, advanced roles, fine-grained permissions, event streaming, dedicated queues or storage, and managed regional processing are likewise unavailable unless current documentation or a written agreement expressly includes them.

17. Availability and support

Relay package materials may identify a support level, but a named support level does not create a guaranteed response time, resolution time, delivery throughput, availability percentage, recovery objective, or service credit unless a separate written service-level agreement expressly states the metric and remedy. Maintenance, provider failures, queue conditions, receiving systems, Customer configuration, and security or compliance actions may affect availability and processing time.

18. Contact

For questions about Relay, this Schedule, sending, integrations, privacy, or billing, contact:

Ridgital LLC
9/1 Halabyan Street, Ajapnyak, Yerevan, Republic of Armenia
Email: info@ridgital.com
Phone: +374 93 949 121