Վերջին թարմացումը՝ 14 հուլիսի 2026 թ.

Սույն Ridgital Relay-ի հատուկ պայմանները («Հատուկ պայմաններ») պարունակում են Ridgital Relay-ին («Relay») վերաբերող պրոդուկտին հատուկ դրույթներ։ Դրանք լրացնում են և ներառված են Ridgital-ի Պայմաններում և դրույթներում, Գաղտնիության քաղաքականությունում և Գումարի վերադարձի քաղաքականությունում («Հիմնական քաղաքականություններ»)։ Ակտիվացնելով, մուտք գործելով կամ օգտագործելով Relay-ը՝ Հաճախորդը համաձայնում է սույն Հատուկ պայմաններին։

1. Կիրառման շրջանակը և գերակայությունը

Սույն Հատուկ պայմանները կիրառվում են միայն Relay-ի նկատմամբ։ Այստեղ չսահմանված՝ մեծատառով սկսվող տերմիններն ունեն Հիմնական քաղաքականություններով սահմանված նշանակությունը։ Եթե սույն Հատուկ պայմանները հակասում են Հիմնական քաղաքականությանը, Relay-ին հատուկ տեխնիկական, թույլատրելի օգտագործման, տվյալների մշակման, retention-ի, suspension-ի և refund-ի հարցերում գերակայում են սույն Հատուկ պայմանները։ Կիրառելի ստորագրված համաձայնագիրը, պատվերը կամ data processing agreement-ը կարող է պարունակել առավել հատուկ պայմաններ։

2. Relay Ծառայությունը

Relay-ը multi-tenant հարթակ է, որը նախատեսված է transactional email-ների ներկայացման, առաքման մշակման, կյանքի ցիկլի տեսանելիության, bounce-երի և suppression-ների կառավարման, privacy-aware engagement tracking-ի, webhook-ների, usage reporting-ի և հարակից integration ու compliance գործառույթների համար։

Հաճախորդի լիազորված հավելվածները կարող են հաղորդագրություններ ներկայացնել versioned API-ի կամ authenticated SMTP interface-ի միջոցով։ Կախված ակտիվ փաթեթից՝ Relay-ը կարող է տրամադրել message ID-ներ, status և event timeline-ներ, delivery և deferral information, bounce detail-ներ, tenant-scoped suppression list-եր, open և click outcome-ներ, webhook notification-ներ, usage information, export-ներ և recipient deletion workflow-ներ։

Relay-ը կարող է ընդունված հաղորդագրություններն առաքել Հաճախորդի կողմից կարգավորված կամ լիազորված outbound SMTP server-ի կամ email provider-ի միջոցով։ Relay-ը orchestration և lifecycle շերտն է, իսկ կարգավորված provider-ը պատասխանատու է outbound SMTP transaction-ն ընդունելու և Հաճախորդի հետ իր համաձայնագրի համաձայն provider-side processing կատարելու համար։

Relay-ը email delivery և lifecycle visibility հարթակ է։ Այն marketing automation, campaign builder, contact-management platform, behavioral-profiling service, advertising-tracking service կամ general-purpose open mail relay չէ։

3. Tenant հաշիվները, օգտվողները և դերերը

Յուրաքանչյուր Հաճախորդ գործում է տրամաբանորեն մեկուսացված tenant-ի շրջանակում։ Օգտվողները, credential-ները, հավելվածները, հաղորդագրությունները, event-ները, webhook-ները, suppression-ները, usage record-ները և compliance request-ները կապակցված են այդ tenant-ին։ Հաճախորդի հասանելիությունը սահմանափակվում է օգտվողի դերով, permission-ով և tenant ownership-ով։

Հաճախորդը պատասխանատու է օգտվողներին լիազորելու, համապատասխան դերեր նշանակելու, ոչ անհրաժեշտ հասանելիությունն անջատելու, հաշիվները պաշտպանելու և ապահովելու համար, որ միայն լիազորված անձինք կառավարեն API key-երը, SMTP credential-ները, webhook-ները, suppression-ները, export-ները, deletion request-ները և կազմակերպության setting-ները։

Սովորական Customer user-ները կարող են ստանալ իրենց դերով թույլատրված operational visibility, իսկ Customer administrator-ները կարող են կառավարել tenant-ի user-ները, application-ները, credential-ները, webhook-ները, suppression-ները, export-ները, deletion request-ները և organization setting-ները, երբ դա թույլ են տալիս ակտիվ փաթեթը և interface-ը։ Customer-ի ոչ մի դեր այլ tenant-ի տվյալներին հասանելիություն չի տալիս։

4. API-ն, SMTP-ն և credential-ները

API key-երը, SMTP credential-ները, session-ները և webhook secret-ները գաղտնի են։ Հաճախորդը պարտավոր է օգտագործել secure transport, սահմանափակել հասանելիությունը, secret-ները անվտանգ պահպանել և հնարավոր արտահոսքի դեպքում փոխարինել կամ հետ կանչել credential-ները։ Արգելվում է credential-ները հրապարակել, տեղադրել public client-side code-ում, կիսել կապ չունեցող tenant-ների միջև կամ օգտագործել authentication-ը, authorization-ը, quota-ն կամ rate limit-ը շրջանցելու համար։

Ամբողջական API key-երը և webhook secret-ները կարող են ցուցադրվել միայն ստեղծման պահին և հետագայում չվերականգնվել։ API key-երը և SMTP credential-ները պատկանում են միայն մեկ tenant-ի։ Ridgital-ը կարող է անջատել կամ հետ կանչել credential-ները, եթե դա ողջամտորեն անհրաժեշտ է Հաճախորդին, recipient-ներին, այլ tenant-ներին, deliverability-ն կամ հարթակը պաշտպանելու համար։

Relay-ում կիրառվում են SMTP-ի երկու տարբեր հասկացություններ՝

SMTP submission credential-ները authenticate են անում Հաճախորդի application-ը, երբ այն հաղորդագրություն է ներկայացնում Relay-ին։ Հաջող ներկայացումը հաստատում է միայն asynchronous processing-ի համար ընդունումը։
Outbound SMTP configuration-ը նույնականացնում է Հաճախորդի կողմից լիազորված server-ը կամ email provider-ը, որի միջոցով Relay-ը փորձում է կատարել առաքումը, և կարող է ներառել host, port, username, transport-security setting-ներ, sender configuration և պաշտպանված password, token կամ provider-ի այլ credential։

Հաճախորդը Relay-ին լիազորում է օգտագործել outbound configuration-ը և հաղորդագրությունը, sender ու recipient հասցեները, header-ները և content-ը առաքման նպատակով փոխանցել կարգավորված provider-ին։ Հաճախորդը պատասխանատու է provider account-ի, authorization-ի, sender permission-ների, domain ու mailbox configuration-ի, provider-ի պայմանների, provider quota-ների, credential rotation-ի և այդ փոխանցման օրինականության համար։ Relay-ը պահանջում է encrypted transport, երբ այն աջակցվում է, և թույլ չի տալիս submission password-ների plaintext փոխանցում։

Մինչև ընդունումը կամ processing-ը Relay-ը կարող է validate անել credential-ը, tenant ownership-ը, sender և recipient syntax-ը, authorized-sender rule-երը, message size-ը, package entitlement-ը, quota-ն և rate limit-ը։ Syntax validation-ը չի հաստատում recipient mailbox-ի գոյությունը կամ հաղորդագրություն ընդունելու հնարավորությունը։ Invalid, unauthorized, oversized, over-quota, rate-limited, revoked, disabled կամ expired submission-ը կարող է մերժվել մինչև delivery pipeline մուտք գործելը։

User password-ները և SMTP submission password-ները չպետք է պահպանվեն plaintext ձևով։ Secret-ի ամբողջական արժեքները չեն ներառվում սովորական list-երում, log-երում, export-ներում, dashboard-ներում կամ support response-ներում։ Multi-factor authentication-ը, single sign-on-ը, webhook replay protection-ը և authentication-ի այլ advanced capability-ները հասանելի են միայն այն դեպքում, երբ հստակ նշված են որպես ընթացիկ գործառույթներ։

5. Փաթեթները, գործառույթները, quota-ները և սահմանաչափերը

Relay-ի յուրաքանչյուր tenant ունի մեկ ակտիվ փաթեթ։ Փաթեթը կարող է սահմանել՝

օրական և ամսական email quota-ները,
API request և rate limit-երը,
SMTP message, connection, concurrency և authentication-attempt limit-երը,
user, application, API-key և SMTP-credential limit-երը,
webhook, event-delivery և retry limit-երը,
message, event, engagement և webhook-log retention-ը,
հասանելի գործառույթները, integration-ները և support level-ը, և
փաթեթում կամ documentation-ում ներկայացված այլ resource կամ security limit-երը։

Կիրառելի սահմանաչափը գերազանցող ներկայացումների կամ հարցումների արագությունը կարող է սահմանափակվել, կամ դրանք կարող են մերժվել։ Չօգտագործված quota-ն հաջորդ ժամանակահատված չի փոխանցվում, եթե փաթեթում հստակ այլ բան նշված չէ։ Downgrade-ը կարող է պահանջել Հաճախորդի գործողություն, եթե առկա օգտվողները, հավելվածները, credential-ները, webhook-ները, տվյալները կամ այլ ռեսուրսները գերազանցում են ավելի ցածր սահմանաչափերը։

Package upgrade-ը, downgrade-ը, quota change-ը, retention change-ը և feature override-ը կարող են փոփոխել հետագա processing-ը և access-ը։ Եթե պատվերում այլ բան նշված չէ, upgrade-ը կիրառվում է activation-ի պահին, իսկ downgrade-ը սովորաբար կիրառվում է նշված ապագա ժամանակահատվածից և կարող է հետաձգվել մինչև անհամատեղելի excess resource-ների կարգավորումը։ Relay-ը չի խոստանում վճարովի overage processing, եթե overage price-ը և behavior-ը հստակ չեն ներկայացվել։

6. Asynchronous ներկայացումը և հաղորդագրության կյանքի ցիկլը

Relay-ը հաղորդագրությունների առաքումը մշակում է ոչ համաժամանակյա եղանակով։ API-ի հաջող պատասխանը կամ SMTP-ի կողմից ընդունումը հաստատում է միայն, որ Relay-ն ընդունել է հաղորդագրությունը մշակման համար։ Դա չի հաստատում առաքումը, inbox placement-ը, առաքման ժամանակը, բացվելը, click-ը կամ recipient-ի որևէ այլ գործողություն։

Կախված մշակման արդյունքից՝ հաղորդագրությունը կարող է անցնել Submitted, Accepted, Processing, Delivered, Deferred, Bounced, Suppressed և Expired կարգավիճակներով։ Relay-ի event store-ը և status information-ը գրանցված հաղորդագրության կարգավիճակի պաշտոնական աղբյուրներն են։ Հաճախորդը չպետք է ներկայացման ընդունումը համարի առաքման ապացույց։

Եթե առաջարկվում է idempotency mechanism, Հաճախորդը պետք է այն օգտագործի documentation-ի համաձայն՝ duplicate submission-ների ռիսկը նվազեցնելու համար։ Առանց documentation-ով սահմանված idempotency mechanism-ի Հաճախորդի կատարած retry-ները կարող են ստեղծել լրացուցիչ message-ներ, charge-եր, event-ներ կամ delivery-ներ։ Relay-ը կարող է platform կամ package policy-ի համաձայն կրկին փորձել ժամանակավոր delivery failure-ները, սակայն չի խոստանում, որ յուրաքանչյուր deferred message կրկին կփորձարկվի կամ վերջնականապես կառաքվի։

Պահպանման ընթացքում lifecycle event-ները ներկայացնում են immutable historical fact-եր։ Relay-ը event-ը լուռ չի վերագրում. correction-ը կամ հետագա outcome-ը ներկայացվում է նոր event-ով։ Event record-ը կարող է ներառել event ID, event type, tenant ID, message ID, timestamp, source, schema version և event-specific metadata։ Հաճախորդի search-ը կարող է օգտագործել document-ավորված field-եր, ինչպիսիք են message ID-ն, recipient-ը, sender-ը, status-ը, application-ը, event type-ը և date range-ը, սակայն email body-ի, attachment content-ի և ընդհանուր full-text content-ի search չի աջակցվում։

Email-ի արդյունքները կախված են recipient data-ից, ստացող mail server-ներից, sender reputation-ից, content-ից, authentication և domain configuration-ից, network condition-ներից, provider policy-ներից և Ridgital-ի ողջամիտ վերահսկողությունից դուրս այլ գործոններից։ Ridgital-ը չի երաշխավորում delivery-ն, inbox placement-ը, delivery time-ը կամ engagement-ը։

7. Օրինական transactional ուղարկումը

Հաճախորդը պարտավոր է Relay-ն օգտագործել միայն օրինական transactional հաղորդակցությունների և կիրառելի փաթեթով կամ գրավոր համաձայնագրով հստակ թույլատրված այլ ուղարկումների համար։ Արգելվում է՝

ուղարկել spam, unsolicited bulk email, unlawful marketing կամ հաղորդագրություններ purchased, harvested, scraped կամ ապօրինի ստացված address list-երին,
ուղարկել առանց իրավաչափ հիմքի, պահանջվող ծանուցման, թույլտվության կամ համապատասխան հարաբերության,
ներկայանալ այլ անձի կամ կազմակերպության անունից, կեղծել sender information-ը, իրականացնել phishing կամ մոլորեցնել recipient-ին,
փոխանցել malware, malicious code, fraud, harassment, threat կամ անօրինական կամ իրավունք խախտող content,
շրջանցել bounce, suppression, compliance, security, quota կամ rate-limit control-ը, կամ
բազմիցս ներկայացնել հայտնի invalid, objecting, unsubscribed կամ prohibited recipient-ներ։

Հաճախորդը պարտավոր է պահպանել sender և recipient information-ի ճշգրտությունը, կատարել կիրառելի consent, notice, objection և opt-out requirement-ները և համապատասխան միջոցներ ձեռնարկել bounce, complaint և suppression information-ի հիման վրա։

Հաճախորդը պատասխանատու է ապահովելու համար, որ իրական transactional purpose գոյություն ունի, և յուրաքանչյուր հաղորդագրության sender identity-ն, subject-ը, content-ը, link-երը, tracking behavior-ը և routing information-ը մոլորեցնող չեն։ Relay-ի control-ները չեն փոխարինում Հաճախորդի consent, objection, complaint, unsubscribe, recordkeeping կամ legal-compliance process-ներին։

8. Relay-ի Հաճախորդի բովանդակությունը

Relay-ի Հաճախորդի բովանդակությունը կարող է ներառել sender, recipient և reply-to հասցեներ, subject, text և HTML body-ներ, technical header-ներ, tag-եր, custom metadata, application ID-ներ, webhook destination-ներ և հարակից հրահանգներ։

Հաճախորդը պատասխանատու է message content-ի, sender identity-ի, recipient selection-ի, իրավաչափ հիմքի, պահանջվող privacy notice-ների, tracking disclosure-ների և consent-ների, ինչպես նաև recipient rights request-ներին պատասխանելու համար։ Հաճախորդը Ridgital-ին տրամադրում է Հիմնական պայմաններում նկարագրված իրավունքները՝ Relay-ի Հաճախորդի բովանդակությունը validate, queue, route, տեխնիկապես փոփոխելու, transmit, deliver, track, store, retain, suppress, export և delete անելու համար՝ Relay-ը տրամադրելու և լիազորված հրահանգները կատարելու չափով։

Հաճախորդի ներկայացրած recipient information-ի և message content-ի նկատմամբ Հաճախորդը սովորաբար գործում է որպես controller կամ համարժեք պատասխանատու կողմ, իսկ Ridgital-ը, որպես կանոն, այդ տվյալները մշակում է Հաճախորդի անունից։ Account administration-ի, billing-ի, security-ի, abuse prevention-ի, legal compliance-ի և սեփական գործունեության կառավարման համար Ridgital-ը գործում է ինքնուրույն։ Անհրաժեշտության դեպքում կարող է կիրառվել data processing agreement։

Attachment-ները, template-ները, scheduled sending-ը, managed sender-domain verification-ը և roadmap-ի content-ի այլ գործառույթները չեն համարվում աջակցվող միայն այն պատճառով, որ դրանց մասին հիշատակում կա API field-ում, database model-ում, planning document-ում կամ future specification-ում։ Դրանք Relay-ի մաս են կազմում միայն այն դեպքում, երբ ներկայացված են ընթացիկ public documentation-ում կամ ակտիվ փաթեթում։

9. Bounce-երը և suppression-ները

Relay-ը կարող է առաքման failure-ները դասակարգել որպես hard կամ soft bounce։ Relay-ը կարող է recipient-ին ավտոմատ suppression-ի ենթարկել hard bounce-ից, repeated bounce activity-ից, compliance action-ից կամ platform-defined այլ deliverability condition-ից հետո։ Լիազորված Customer administrator-ները կարող են ստեղծել կամ հեռացնել tenant-scoped suppression-ները, երբ դա թույլատրված է։

Bounce և complaint information-ը կարող է ստացվել կարգավորված outbound provider-ից, delivery response-ներից, delivery-status notification-ներից, feedback-loop report-ներից կամ աջակցվող այլ աղբյուրներից։ Classification-ները և human-readable reason-ները կախված են այդ աղբյուրներից հասանելի տեղեկությունից և կարող են լինել ոչ ամբողջական կամ Relay-ի կողմից normalized։

Suppression-ը կանխում է համապատասխան tenant-ի շրջանակում հետագա առաքման փորձերը մինչև այն լիազորված workflow-ով հեռացնելը։ Suppression-ը չի ազդում կապ չունեցող tenant-ների վրա։ Հաճախորդը չպետք է շրջանցի suppression-ը կամ բազմիցս ներկայացնի հայտնի invalid կամ prohibited հասցեներ։

Suppression record-ները operational են և կարող են ակտիվ մնալ message retention-ի սովորական ժամկետից անկախ՝ մինչև manual, administrative կամ compliance workflow-ով հեռացվելը։

Recipient deletion կամ objection workflow-ը կարող է ստեղծել կամ պահպանել minimal compliance suppression, որպեսզի ջնջված կամ առարկություն ներկայացրած recipient-ին այլևս հաղորդագրություն չուղարկվի։ Automatic, manual, administrative կամ compliance suppression-ի հեռացումը կարող է սահմանափակվել, պահանջել լրացուցիչ authorization կամ մերժվել, եթե suppression-ի շարունակումը ողջամտորեն անհրաժեշտ է օրենքի, անվտանգության, abuse prevention-ի կամ sender reputation-ի համար։

10. Privacy-aware open և click tracking

Եթե engagement tracking-ը ներառված և միացված է, Relay-ը կարող է տեխնիկապես փոփոխել HTML content-ը՝ ավելացնելով tracking pixel, և eligible link-երը կարող է rewrite անել tracked redirect-ի միջոցով։ Pixel request-ը կարող է գրանցել open event, իսկ tracked redirect-ի activation-ը՝ click event։ Engagement record-ը կարող է ներառել event ID, tenant ID, message ID, recipient, event type, timestamp և այնպիսի արդյունք, ինչպիսին է «Opened = True» կամ «Clicked = True»։

Relay-ի engagement subsystem-ը նախագծված է recipient-ի IP address-ը, user agent-ը, browser-ը, operating system-ը, device information-ը, device կամ browser fingerprint-ը, geolocation-ը, country-ն, city-ն, region-ը, ISP-ն, ASN-ը, network fingerprint-ը, behavioral profile-ը կամ advertising identifier-ը չպահպանելու համար։

Այս սահմանափակումը վերաբերում է recipient engagement event-ներին։ Կայքի, portal-ի, API-ի կամ SMTP interface-ի առանձին security և access log-երը կարող են մշակել account user-ի կամ միացող համակարգի IP address-ը և request information-ը՝ authentication-ի, abuse prevention-ի, troubleshooting-ի և անվտանգության համար։

Open և click information-ը գործառնական ցուցանիշ է և ոչ թե անձի վարքագծի անվիճելի ապացույց։ Image blocking-ը, caching-ը, security scanner-ները, link rewriting-ը, automated system-ները և նման տեխնոլոգիաները կարող են հանգեցնել event-ների բացակայությանը, ուշացմանը, կրկնությանը կամ դրանց ստեղծմանը՝ առանց recipient-ի գիտակցված գործողության։

Հաճախորդը պատասխանատու է որոշելու համար, թե յուրաքանչյուր հաղորդագրության և recipient-ի համար tracking-ը օրինական և նպատակահարմար է արդյոք, պահանջվող notice-ը տրամադրելու, անհրաժեշտ consent-ը ստանալու և tracking-ը չօգտագործելու համար, երբ դրա իրավաչափ հիմքը բացակայում է։ Relay-ի engagement tracking-ը չպետք է օգտագործվի covert surveillance-ի, profiling-ի, advertising tracking-ի, device tracking-ի կամ geolocation tracking-ի համար։

11. Webhook-ները և Հաճախորդի համակարգերը

Հաճախորդը պատասխանատու է webhook endpoint-ների և միացված համակարգերի ճշգրտության, անվտանգության, հասանելիության և օրինական աշխատանքի համար։ Հաճախորդը պետք է հնարավորության դեպքում վավերացնի signature-ը, պաշտպանի webhook secret-ը, ստուգի payload integrity-ն ու timestamp-ը և ապահովի, որ endpoint-ը կարող է անվտանգ ընդունել event-ները։

Webhook payload-ը կարող է ներառել event ID, event type, tenant ID, message ID, timestamp, event-specific data, delivery status, bounce կամ suppression information, engagement outcome, recipient կամ sender information և subscribed event-ի համար document-ավորված այլ field-եր։ Endpoint կարգավորելով՝ Հաճախորդը Ridgital-ին հանձնարարում է այդ payload-ները փոխանցել տվյալ endpoint-ին և պատասխանատու է endpoint-ի recipient-ների, access control-ների, log-երի, downstream retention-ի և հետագա processing-ի համար։

Webhook delivery-ն ոչ համաժամանակյա է և չպետք է համարվի system of record։ Ձախողված առաքումները կարող են կրկին փորձարկվել կիրառելի platform կամ package policy-ի համաձայն, սակայն առաքումը չի երաշխավորվում։ Ridgital-ը կարող է սահմանափակել, անջատել կամ կասեցնել invalid, insecure, persistently unavailable, abusive կամ operationally harmful endpoint-ը։

Relay-ը կարող է պահպանել webhook name-ը, endpoint URL-ը, status-ը, subscribed event-ները, secret metadata-ն, request timestamp-ը, response code-ը, response time-ը կամ processing duration-ը, attempt number-ը, retry count-ը, failure-ը և delivery result-ը։ Ամբողջական webhook secret-ը ստեղծումից հետո չի ցուցադրվում։ Compliance-event webhook-ները, advanced retry control-ները, replay API-ները, versioning-ը և endpoint-health feature-ները հասանելի են միայն այն դեպքում, երբ հստակ document-ավորված են որպես ընթացիկ գործառույթներ։

12. Relay-ի տվյալները, retention-ը և compliance workflow-ները

Relay-ը կարող է մշակել message content, metadata, lifecycle event-ներ, delivery attempt-ներ, bounce detail-ներ, suppression-ներ, engagement event-ներ, webhook configuration և log-եր, usage record-ներ, credential metadata, compliance request-ներ, operational log-եր և audit record-ներ՝ Գաղտնիության քաղաքականությունում նկարագրված կարգով։

Message content-ը, message metadata-ն, lifecycle event-ները, engagement event-ները և webhook log-երը պահպանվում են ակտիվ փաթեթի համաձայն, այնուհետև ավտոմատ expire կամ delete են արվում։ Փաթեթի նյութերում ներկայացված ճշգրիտ արժեքները գերակայում են։ Suppression, audit, authentication, security, payment, operational և compliance record-ների համար կարող են կիրառվել այլ retention period-ներ։

Լիազորված Հաճախորդները կարող են հասանելի portal կամ API workflow-ների միջոցով պահանջել data export, recipient export, recipient deletion և compliance suppression։ Հարցումները ենթակա են identity-ի, authorization-ի, tenant ownership-ի, տեխնիկական իրագործելիության, platform policy-ի և օրենքով սահմանված պահպանման պարտավորությունների։

Recipient export-ը կարող է ներառել ստուգված հասցեի հետ կապված message metadata, lifecycle event-ներ, engagement event-ներ, bounce information, suppression information և webhook activity՝ կախված հասանելի տվյալներից և retention-ից։ Export-ը չի բացահայտում ամբողջական password-ներ, API key-եր, SMTP credential-ներ, outbound-provider secret-ներ, webhook secret-ներ, private encryption material, այլ tenant-ի տվյալներ կամ անվտանգության այնպիսի տեղեկություն, որի բացահայտումը կստեղծի անհամաչափ ռիսկ։

Ստուգված recipient deletion-ը կարող է հեռացնել տվյալ հասցեի հետ կապված պահպանված message content-ը, metadata-ն, lifecycle history-ն և engagement history-ն՝ տեխնիկական իրագործելիության և իրավական պահանջների պահպանմամբ։ Այն կարող է չհեռացնել request-ի մասին immutable audit evidence-ը, payment կամ account record-ները, security և abuse-prevention record-ները, օրենքով պարտադիր պահպանվող record-ները, Հաճախորդի կամ կարգավորված third-party provider-ի վերահսկողության ներքո արդեն գտնվող տվյալները կամ future sending-ը կանխելու համար անհրաժեշտ minimal compliance suppression-ը։

Retention period-ի ավարտը պարտադիր չէ, որ հանգեցնի նույն պահին կատարվող deletion-ի. deletion-ը կատարվում է scheduled cleanup processing-ի միջոցով։ Cleanup-ի ընթացքում record-ները կարող են կարճ ժամանակով մնալ inaccessible կամ pending deletion վիճակում։ Retention failure-ները log և monitor են արվում։ Հաճախորդը պարտավոր է անհրաժեշտ տեղեկությունն export անել մինչև expiration-ը, downgrade-ը, cancellation-ը կամ termination-ը։

13. Tenant isolation-ը և administrative access-ը

Relay-ը tenant ownership է կիրառում հաշիվների, credential-ների, հաղորդագրությունների, event-ների, webhook-ների, suppression-ների, analytics-ի, usage-ի և compliance workflow-ների նկատմամբ։ Հաճախորդը չպետք է փորձի մուտք ստանալ այլ tenant-ի տվյալներին կամ առաջացնել cross-tenant processing։

Ridgital-ի administrative access-ը սահմանափակված է ըստ դերի, իսկ գործողությունները ենթակա են audit-ի։ Administrative tool-երը նախագծված են message ID-ի, sender-ի, recipient-ի, tenant-ի, status-ի, event-ի, delivery-ի, bounce-ի, suppression-ի և operational metadata-ի շուրջ։ Email body-ի կամ attachment content-ի full-text search չի աջակցվում։

Support administrator-ները կարող են հասանելիություն ունենալ account information-ին, delivery activity-ին, webhook activity-ին, bounce information-ին և հարցումը ուսումնասիրելու համար անհրաժեշտ այլ operational metadata-ին։ Operations administrator-ները կարող են հասանելիություն ունենալ service, queue, event և incident information-ին։ Platform administrator-ները կարող են կատարել լիազորված customer, package, retention, security և compliance operation-ներ։ Role assignment-ը չի շրջանցում tenant isolation-ը լուռ կերպով, իսկ sensitive administrative action-ները և investigation-ները ստեղծում են audit record-ներ։

14. Relay-ի կասեցումը և պաշտպանական միջոցները

Բացի Հիմնական պայմաններով նախատեսված դեպքերից՝ Ridgital-ը կարող է սահմանափակել sending-ը, processing-ը, credential-ները, webhook-ները կամ Relay account-ը excessive bounce-երի, spam complaint-ների, unlawful կամ abusive sending-ի, sender-reputation harm-ի, suppression evasion-ի փորձի, credential misuse-ի, invalid endpoint-ի, quota exhaustion-ի, security risk-ի կամ deliverability-ի, platform infrastructure-ի, provider-ների, recipient-ների կամ այլ tenant-ների համար վտանգի պատճառով։

Երբ դա գործնականում հնարավոր է, Ridgital-ը կտրամադրի ծանուցում և խնդիրը շտկելու հնարավորություն։ Անհապաղ գործողություն կարող է ձեռնարկվել շարունակական վնասը, unlawful activity-ն, provider blocking-ը, security compromise-ը կամ cross-tenant risk-ը կանխելու համար։

15. Relay-ին հատուկ refund սահմանափակումները

Բացի Գումարի վերադարձի քաղաքականությամբ նախատեսված դեպքերից՝ Relay-ի վճարները, որպես կանոն, վերադարձման ենթակա չեն այն պատճառով, որ հաղորդագրությունները deferred, bounced, suppressed, rejected, delayed, spam folder առաքված, չբացված կամ առանց click-ի են, կամ ստացող mail system-ը մերժում կամ filter է անում հաղորդագրությունը։ Չօգտագործված email, API, SMTP, webhook, retention կամ package-ի այլ capacity-ն, որպես կանոն, վերադարձման ենթակա չէ։

Refund-ը նաև սովորաբար հասանելի չէ invalid recipient data-ով, sender reputation-ով, Հաճախորդի content-ով, domain կամ sender configuration-ով, Հաճախորդի credential-ով կամ համակարգով, unavailable webhook endpoint-ով, image blocking-ով, link scanning-ով, network condition-ով, receiving-provider policy-ով, quota enforcement-ով կամ Հաճախորդի խախտմամբ պայմանավորված արդյունքների համար։

16. Roadmap-ը և չաջակցվող գործառույթները

Եթե roadmap capability-ն հստակ ներառված չէ ակտիվ փաթեթում կամ գրավոր հաստատված չէ, այն Relay-ի մաս չի կազմում։ Advanced domain verification-ը, managed DKIM/SPF/DMARC-ը, template-ները, scheduling-ը, dedicated infrastructure-ը, advanced analytics-ը, multi-region option-ները, MFA-ն, SSO-ն, advanced event replay-ը, message attachment-ները, AI-assisted operation-ները կամ planning material-ներում նշված enterprise այլ գործառույթները միայն այդ հիշատակումով ընթացիկ պարտավորություն չեն դառնում։

Compliance-event webhook-ները, legal hold-ը, retention exception-ները, customer-managed key-երը, compliance certification-ները, advanced role-երը, fine-grained permission-ները, event streaming-ը, dedicated queue կամ storage-ը և managed regional processing-ը նույնպես հասանելի չեն, եթե ընթացիկ documentation-ը կամ գրավոր համաձայնագիրը հստակ չի ներառում դրանք։

17. Հասանելիությունը և աջակցությունը

Relay-ի package material-ները կարող են նշել support level, սակայն support level-ի անվանումը չի ստեղծում երաշխավորված response time, resolution time, delivery throughput, availability percentage, recovery objective կամ service credit, եթե առանձին գրավոր service-level agreement-ը հստակ չի սահմանում տվյալ metric-ը և remedy-ն։ Maintenance-ը, provider failure-ը, queue condition-ը, receiving system-ը, Հաճախորդի configuration-ը և security կամ compliance action-ը կարող են ազդել availability-ի և processing time-ի վրա։

18. Կապ

Relay-ի, սույն Հատուկ պայմանների, sending-ի, integration-ների, privacy-ի կամ billing-ի վերաբերյալ հարցերի համար կապ հաստատեք՝

Ridgital ՍՊԸ
Հայաստանի Հանրապետություն, Երևան, Աջափնյակ, Հալաբյան փողոց 9/1,
Էլ. փոստ՝ info@ridgital.com
Հեռախոս՝ +374 93 949 121