Support Policy

Support Policy

This Support Policy explains how Etalyon Sàrl-S, operating Squillify ("Squillify", "we", "us", or "our"), provides customer support for the Squillify platform, APIs, dashboard, microskills, billing, and related services.

This policy is a draft and is not effective until published as active by Squillify. It is intended for operational and legal review before launch.

1. Purpose

This policy explains:

• how to contact Squillify support;
• what support covers;
• what support does not cover;
• what information customers should provide;
• what support can and cannot access;
• how execution issues are investigated under Squillify's no-permanent-payload-storage model;
• how support requests relating to security, abuse, privacy, billing, and availability are handled;
• how response targets apply.

This policy does not create a contractual Service Level Agreement ("SLA") unless an applicable plan, order form, enterprise agreement, or written contract expressly says so.

2. Support channels

Customers may contact Squillify through the support channels made available for their plan.

Default support contact:

• Support: [email protected]

Specialised contacts:

• Security issues: [email protected]
• Vulnerability reports: [email protected]
• Abuse reports: [email protected]
• Privacy requests: [email protected]
• Legal requests: [email protected]
• Billing questions: [email protected]

Additional support channels, such as dashboard support, ticketing, chat, dedicated Slack, or enterprise contacts, may be made available depending on the customer's plan.

3. Support availability

Support availability depends on the customer's plan.

Unless expressly stated in a plan, order form, enterprise agreement, or written contract:

• support is provided on a best-effort basis;
• response targets are operational goals, not contractual guarantees;
• resolution times are not guaranteed;
• support is not available 24/7;
• support is provided in English unless otherwise agreed;
• emergency support is not guaranteed.

Squillify may offer different support levels for free, paid, business, or enterprise plans.

4. Scope of support

Support may cover:

• account access questions;
• tenant and organisation administration questions;
• API key management questions;
• dashboard usage questions;
• API usage questions;
• microskill usage questions;
• quota, rate-limit, and fair-use questions;
• billing and invoice questions;
• suspected defects;
• documentation issues;
• service availability questions;
• file handling questions;
• telemetry and usage reporting questions;
• general platform configuration questions.

Support is intended to help customers use Squillify as documented.

5. Out-of-scope support

Unless expressly agreed in writing, support does not include:

• building customer applications;
• writing or debugging customer production code;
• designing customer agent architectures;
• operating customer agents, scripts, automations, or integrations;
• guaranteeing compatibility with undocumented or unsupported clients;
• reverse engineering customer systems;
• recovering customer-side lost secrets or compromised credentials;
• forensic investigation of customer infrastructure;
• legal, tax, regulatory, or compliance advice;
• data protection advice specific to the customer's business;
• security audits of customer systems;
• penetration testing of customer applications;
• training customer employees beyond published documentation;
• custom development;
• consulting services;
• guaranteed incident response;
• guaranteed uptime or SLA remedies;
• support for prohibited, abusive, or unlawful use.

Squillify may offer professional services separately under a separate agreement.

6. Information to include in a support request

To help Squillify investigate efficiently, customers should include:

• tenant name or tenant identifier where available;
• account email or contact email;
• request identifier or run identifier where available;
• API key identifier or partial key label, not the secret key;
• skill key and version;
• approximate time of the issue, including timezone;
• endpoint or dashboard area affected;
• error code, status code, and response body where safe to share;
• expected behaviour;
• actual behaviour;
• whether the issue is reproducible;
• steps to reproduce;
• relevant plan, quota, or rate-limit context;
• sanitized sample input and output if needed;
• screenshots where useful and safe;
• whether the issue affects production.

Customers must not send secrets, full API keys, passwords, private keys, access tokens, session cookies, payment card numbers, regulated data, or unnecessary personal data in support requests.

7. No permanent raw payload storage

Squillify is designed so that raw submitted microskill payloads are not permanently stored as part of normal execution.

Because of this design:

• support may not be able to inspect the exact input submitted to a microskill;
• support may not be able to reconstruct an execution from raw payload content;
• support may rely on metadata such as request identifiers, timestamps, skill keys, status codes, error codes, latency, quota events, and file metadata;
• support may ask the customer to provide sanitized examples;
• support may ask the customer to reproduce the issue using non-sensitive data;
• support may be unable to resolve issues that require raw payload inspection if the customer cannot provide a safe example.

Customers are responsible for removing or masking sensitive, confidential, regulated, or personal data before sending examples to support.

8. Support access to customer data

Support access is limited to what is reasonably necessary to provide support, operate the service, investigate defects, protect the platform, prevent abuse, handle billing, or comply with legal obligations.

Support may access, where available:

• account data;
• tenant metadata;
• plan information;
• billing status;
• API key metadata, not secret key values;
• skill configuration metadata;
• usage metadata;
• telemetry metadata;
• error metadata;
• file metadata;
• support communications;
• security and abuse signals.

Support is not intended to access raw submitted microskill payloads because Squillify is designed not to permanently store them as part of normal execution.

9. Customer responsibilities

Customers are responsible for:

• securing their accounts;
• securing API keys and credentials;
• scoping API keys appropriately;
• rotating compromised keys;
• controlling access for tenant administrators and members;
• monitoring their own applications, agents, scripts, and integrations;
• respecting rate limits, quotas, and fair-use rules;
• implementing retry logic safely;
• maintaining their own logs where needed;
• testing integrations before production use;
• submitting only data they are authorised to process through Squillify;
• providing accurate information when requesting support;
• avoiding unnecessary personal or sensitive data in support requests.

Support does not replace customer-side monitoring, logging, security controls, or operational responsibility.

10. Security issues and vulnerability reports

Security issues must be reported to [email protected].

Vulnerability reports should follow the Vulnerability Disclosure Policy and should use the subject prefix:

[Vulnerability Report]

Do not use standard support channels for urgent vulnerability reports if the security contact is available.

Customers must not publicly disclose vulnerabilities before Squillify has had a reasonable opportunity to investigate and remediate, unless legally required or expressly agreed.

11. Abuse reports

Abuse reports should be sent to [email protected].

Abuse reports may include:

• suspected spam;
• credential abuse;
• misuse of API keys;
• attempts to bypass quotas or rate limits;
• malicious traffic;
• illegal or unauthorised use;
• suspected platform attacks;
• use that violates the Acceptable Use Policy.

Squillify may investigate abuse reports and may restrict, throttle, suspend, block, or terminate access where necessary to protect the platform, customers, infrastructure, providers, or third parties.

12. Privacy and data protection requests

Privacy requests should be sent to [email protected].

Where Squillify acts as processor on behalf of a customer, Squillify may refer the requester to the relevant customer or assist the customer under the Data Processing Agreement.

Support may not process privacy rights requests through ordinary troubleshooting channels where identity verification or legal review is required.

13. Billing support

Billing questions may be sent to [email protected].

Billing support may cover:

• plan questions;
• invoice access;
• failed payments;
• refunds;
• usage and quota questions;
• billing disputes;
• tax or VAT information shown on invoices;
• payment processor issues.

Billing support does not provide tax, accounting, or legal advice. Customers are responsible for consulting their own advisors where needed.

Refunds, credits, cancellations, failed payments, disputes, and chargebacks are governed by the Billing and Refund Policy.

14. Service availability and incidents

Questions about service availability are handled under this policy and the Service Availability Policy.

Unless expressly agreed in a binding SLA:

• support response targets are not uptime guarantees;
• support response targets are not resolution guarantees;
• incident communications are not contractual SLA commitments;
• service unavailability does not automatically entitle customers to refunds or credits.

During incidents, Squillify may prioritise investigation and restoration over individual support replies.

15. Response targets

Specific response targets depend on the customer's plan and will be confirmed before this policy becomes active.

Unless expressly stated in a plan or agreement, any response target is an operational objective only.

Draft example structure, pending plan confirmation:

No active version of this policy should contain pending response targets.

16. Resolution targets

Squillify does not guarantee resolution times unless expressly stated in a plan, order form, enterprise agreement, or written contract.

Resolution depends on factors such as:

• complexity;
• reproducibility;
• severity;
• customer information provided;
• third-party provider involvement;
• whether the issue is caused by customer code or configuration;
• whether a workaround is available;
• whether product changes are required;
• whether legal, privacy, or security review is required.

17. Priority and severity

Squillify may prioritise support requests based on severity, plan, security impact, platform impact, affected customers, abuse risk, billing impact, and operational urgency.

Draft severity model:

Severity classification is determined by Squillify.

18. Feature requests and product feedback

Customers may submit feature requests and product feedback.

Squillify may use feedback to improve the service, but submitting feedback does not create an obligation to implement, maintain, or support any feature.

Unless otherwise agreed in writing, customers grant Squillify the right to use feedback without restriction or compensation for product improvement, documentation, security, reliability, and service development.

19. Customer-provided examples and attachments

Customers may provide examples, files, logs, screenshots, or other materials to support.

Customers must ensure that such materials are:

• lawful to share;
• relevant to the request;
• sanitized where possible;
• free of unnecessary personal data;
• free of secrets and credentials;
• free of confidential data not needed for investigation;
• free of malware or harmful content.

Squillify may delete or refuse attachments that create security, privacy, legal, or operational risk.

20. Support records and retention

Squillify may retain support records for customer service, security, legal, billing, quality, training, and operational purposes.

Support record retention is described in the Data Retention Policy and Privacy Policy.

Support records may contain personal data if provided by the customer. Customers should avoid including unnecessary personal data in support requests.

21. Language

Unless otherwise agreed, Squillify support is provided in English.

Squillify may choose to respond in another language where practical, but does not guarantee multilingual support unless agreed in writing.

22. Professional services

Support does not include consulting, implementation, integration, architecture review, custom development, migration, training, security audit, legal review, or data protection advisory services.

Such services may be offered separately under a written agreement.

23. Changes to this policy

Squillify may update this policy from time to time.

If changes are material, Squillify will provide reasonable notice through appropriate channels, such as the dashboard, website, email, documentation, or other service communications.

The version, last updated date, and effective date are shown at the top of this policy.

24. Contact

For support questions, contact:

• Support: [email protected]

For specialised matters:

• Security: [email protected]
• Vulnerability reports: [email protected]
• Abuse: [email protected]
• Privacy: [email protected]
• Legal: [email protected]