Start with the workflow, question, or correction

The only general contact destination evidenced on the current DewEngine site is roki@dewx.com. Use it for a design-partner introduction, a factual correction, or a question about the development project. There is no published form, physical office location, telephone line, customer help desk, or response-time commitment, and sending email does not create production access or an agreement.

Talk to us ↗Read technical guides →

General contact

Email is the current conversation path

Write to roki@dewx.com with a subject that names why you are contacting DewEngine. A concise first message is enough. The address appears in the repository's existing site calls to action, so it is the one contact fact this page can publish without inventing an organization directory. It should not be treated as proof of a registered office, a staffed support operation, or twenty-four-hour monitoring. No acknowledgement or reply schedule is promised.

Product discussions

Describe one concrete workflow before requesting breadth

For a design-partner conversation, explain the product you are building, who owns the provider account, the smallest action or synchronization outcome required, and what evidence your application needs after it runs. Include the provider and whether official access has already been approved for your use. Do not send live credentials or private message content. This context helps evaluate fit, but the inquiry does not reserve capacity, guarantee a connector, or open paid production service.

Factual corrections

Point to the exact route and statement

If a public page appears inaccurate, include its URL, quote the short statement at issue, and describe the evidence that conflicts with it. Provider documentation and policies can change, so a dated primary source is especially helpful. A correction request is distinct from a capability request: it asks the project to make public information truthful, not to implement or release the subject of that information. Avoid attaching material you are not authorized to share.

Security concerns

Share enough to locate risk without exposing a secret

The repository does not publish a dedicated vulnerability-reporting program, encryption key, safe-harbor policy, or emergency hotline. A first email can identify the affected component, observed behavior, and a safe way to continue the conversation. Do not include access tokens, passwords, personal message bodies, destructive proof, or data belonging to another person. This page cannot promise bounty eligibility, confidentiality terms, remediation timing, or formal incident handling that has not been established.

Legal and privacy questions

An inquiry is not automatically formal notice

Questions about draft terms, privacy planning, or the legal-notice placeholder may be sent to the same general address. The mailbox is not identified as an official service destination for court papers, regulator correspondence, data-rights requests, or contractual notices. Because the future operator and procedures are not yet published, this page cannot define when a legal communication is received or what verification will be required. Those routes must be documented before customer launch.

Message safety

Keep the first contact minimal

A useful introduction rarely needs sensitive information. Use role-level context, redacted examples, and approximate scale until there is an appropriate channel and a reason to share more. Do not send provider sessions, API keys, identity documents, payment information, candidate records, confidential customer exports, or health data. The current public materials do not state an inquiry retention schedule or deletion process, so the safest message is the smallest one that lets the question be understood.

What happens next

Conversation does not change release status

A reply, meeting, technical discussion, or repository issue does not make a capability available, approve a provider access path, establish an employment process, or finalize legal terms. Release labels continue to follow product evidence and decision gates. If a discussion progresses, any scope, confidentiality, commercial condition, or service commitment would need its own authorized written record. This contact page supplies a doorway for questions, not a shortcut around those decisions.

Implemented control plane

Keep the integration boundary consistent.

The development API already uses consistent account identifiers, command state, errors, and webhook envelopes. A provider method appears only when its implementation and evidence exist.

Explicit connected-account ownership
Stable public resource identifiers
Truthful provider outcome state
Release status beside every capability

Implemented development APITypeScript

const accounts = await dew.connectedAccounts.list();

const active = accounts.filter(
  (account) => account.status === "ACTIVE"
);

Tenant-scoped records · lifecycle metadata only

Questions

Before you build.

What should I include in a DewEngine product inquiry?+

Name the product, provider account owner, smallest required workflow, expected evidence, and most important failure case. Keep examples redacted and do not include credentials or private message content in the first email.

Is roki@dewx.com a guaranteed support or legal-notice channel?+

No. It is the general contact address evidenced on the current site. No staffing, response time, emergency handling, statutory-service function, or customer support commitment is published for it.

Build with us

Does this match the workflow your users need?

DewEngine is in development. Real use cases decide what ships first.

Share your use case ↗