Contacting support

Email [email protected], or use the support panel in the app. A real person reads it.

What to include

The difference between one reply and four is usually three lines of context.

What you were doing. “Pushing a document to WordPress”, not “it broke”.

The exact message. Copy it rather than paraphrasing — the wording distinguishes between causes that look identical in a summary.

Which document or site. The document URL, and the site it is connected to. That is enough for us to find it.

When it started, and whether it ever worked. “Worked yesterday, fails today” and “never worked” point at completely different things.

What you have already tried, so we do not send you round the same loop.

A screenshot of the error helps. A screenshot of a whole screen with the error somewhere in it helps less than the copied text.

What we can see

We can see your account, your projects, and the state of your documents. We cannot see your WordPress password, and we do not have access to your site beyond the application password you granted — which you can revoke at any time.

We cannot read the contents of your documents as a matter of routine. If a problem needs us to look at a specific document, we will ask.

Faster than a ticket

A lot of what reaches support is covered here:

Common errors — the errors people hit most, and what each means.
A push to WordPress failed — an ordered walkthrough.
“Application passwords not available” — the connection problem.
Allowlisting Workover — when your firewall is the problem.

Security

To report a vulnerability, email [email protected] rather than using the normal support channel, and please give us a reasonable window before disclosing.

Feature requests and bugs

Both welcome through the same channel. A bug report that includes what you expected to happen is worth several that say what did.