How Nestarc Webhooks communicates incidents and handles support today.

Nestarc Webhooks is currently operated as an individual based in Republic of Korea. Paid plans are processed by Paddle.com Market Ltd, which acts as Merchant of Record and is the seller of record for tax purposes — see the Privacy Policy and Terms of Service for the role each party plays in billing, taxation, and data handling.

Korean business registration is planned before paid plans launch publicly. Incorporation as a legal entity is planned once paying customers exceed standard thresholds that require enterprise contracting capability (Master Service Agreement, direct invoicing, custom Data Processing Addendum). This page is updated when each milestone is reached.

This disclosure exists so that teams evaluating Nestarc for production use can see the current operating reality and the documented path forward, instead of inferring either from the absence of information.

All Nestarc Webhooks production data is processed and stored in AWS region ap-northeast-2 (Seoul, Republic of Korea). This includes the relational database, the delivery worker, the HTTP API, and the dashboard. There is currently no cross-region replication; data does not transit other AWS regions during normal operation.

Off-instance backups are written to an Amazon S3 bucket in the same region with AES-256 server-side encryption applied by default. Public access to the backup bucket is blocked at the account and bucket-policy level.

Webhook payload retention follows the per-plan delivery log retention period (7, 30, or 90 days depending on plan tier). After the retention window ends, payloads are purged from primary storage and overwritten in subsequent backup cycles. Account-level data (organizations, members, application configuration) is retained for the lifetime of the account and removed on account deletion request.

For European customers: the European Commission recognized Republic of Korea as offering an adequate level of personal-data protection under the EU GDPR (Adequacy Decision, December 2021). This means personal data of EU residents may lawfully be transferred to Nestarc operations in Seoul without additional transfer mechanisms (such as Standard Contractual Clauses) for the EU-to-Korea leg of the journey.

The infrastructure described above runs on a single EC2 instance within the Seoul region, by deliberate operational choice during public beta. Multi-AZ database failover and cross-region disaster recovery are not currently in place; see Availability below for the current best-effort posture and the conditions under which that posture will be reconsidered.

Security incidents are handled separately from service-uptime incidents. A security incident is any confirmed or high-confidence suspected exposure of customer data, account credentials, or webhook payload contents; unauthorized access to customer Applications or Endpoints; or abuse of signing material.

When Nestarc confirms material impact, affected customers are notified directly by email to the account owner. A corresponding public summary is posted to the status page so the broader user base sees that an event was handled. Direct notification takes precedence over the status page for security events, since the status page alone is not a reliable notification channel.

Our current commitment is to send the first notification within 72 hours of confirming material impact. This window aligns with the Personal Information Protection Act (PIPA) expectations in the Republic of Korea and allows time to verify scope before communicating. Earlier notification is preferred whenever facts can be stabilized sooner.

Security researchers are asked to use coordinated disclosure. Send reports to [email protected] with enough detail to reproduce the issue. A PGP/GPG key is available upon request if you prefer encrypted communication.

Nestarc will not pursue legal action against good-faith security research provided that researchers:

• avoid access to customer data beyond what is necessary to confirm the vulnerability;
• do not modify, exfiltrate, or destroy user data;
• report privately to [email protected] before any public disclosure;
• allow reasonable time to remediate before discussing the issue publicly, and coordinate on the disclosure timeline.

Automated scanning that does not degrade service is permitted; any testing that risks service availability for other customers is not.

Nestarc Webhooks is currently provided on a best-effort basis. We work to maintain reliable service, but we do not currently publish a formal uptime guarantee, response-time target, or service-credit schedule under a public Service Level Agreement (SLA).

Availability may be affected by planned maintenance, upstream provider incidents, network failures, security events, or factors outside our reasonable control.

We expect to revisit this posture when paid plans open to general availability with measurable production workloads, when a customer requirement makes formally documented redundancy necessary, or when the operational cost of multi-AZ failover and cross-region disaster recovery is justified by sustained usage volume. Until then, the current single-instance deployment is an explicit beta trade-off, not the intended long-term end state.