Feedback, bug reports and waitlists

Your apps send three kinds of requests to the inbox (feedback, bug reports and messages) and signups to the waitlist, through the ingest API under /_care/. Build the form your way; LogSure stores what it sends and shows it in every console.

From the page

With the tracker on the page, each call resolves to the JSON answer, or rejects with an Error carrying .status and the server's message:

await logsure.feedback({ message: 'Love the new editor', rating: 5, email: '[email protected]' });

await logsure.bug({
  title: 'Export does nothing',
  description: 'Clicking Export leaves the dialog open.',
  steps: '1. Open a document\n2. Click Export',
  expected: 'A PNG download',
  version: '1.4.2',
  email: '[email protected]',
  attachments: [{ name: 'screenshot.png', data: screenshotDataUrl }],
});

await logsure.message({ email: '[email protected]', subject: 'An invoice for March', message: 'Could I have one?' });

await logsure.waitlist({ email: '[email protected]', name: 'Ann', list: 'beta' });

The page's address is added for you. Without the tracker, send the same JSON with fetch to /_care/feedback, /_care/bug, /_care/message or /_care/waitlist; the app is found from the request's Origin, or from app in the body.

What each kind takes

Kind	Required	Optional
Feedback	`message` (up to 5,000 characters)	`rating` (1 to 5 stars), `category`
Bug report	`title` (3 to 150), `description`	`steps`, `expected`, `version`, `attachments` (up to 3)
Message	`message`, `email`	`subject`
Waitlist signup	`email`	`name`, `list`, `consent`, `props`

Every request also takes email, name, url, props (your own context, such as a plan or an account id) and fields (the app's own fields, below). The answer to a request is 201 with {"ok": true, "id": "t_…"}.

Attachments

A bug report carries up to three attachments, each as base64 or a data URL. PNG, JPEG, GIF, WEBP, UTF-8 text and JSON are taken, 5 MB each and 8 MB together; an app's settings can allow more files, larger ones and other types described by their contents. The type is always read from the bytes, never from the name or the declared type. In the console, attachments are only downloaded, or shown as images.

Waitlists

An app has any number of lists, named in lower case (beta, android); without list a signup joins the app's default list. A repeat signup gets the same answer as a new one, so the form never tells anyone whether an address is already on the list. When the app's waitlist rules ask for consent, signups must send consent: true, and the signup keeps the version of the consent text it agreed to.

Earlier signups from another tool come in with POST /_care/import/waitlist and the server key: up to 1,000 per call, each with its own time and status.

Your own fields

Under Settings › Apps, an app's Forms section adds fields of its own to bug reports, feedback or messages: text, long text, number, select, checkbox, email, URL, date or JSON, each optional or required. Send them in fields; unknown keys are refused. A form can be rendered from the definition:

const { fields } = await logsure.form('bug');   // GET /_care/form/bug
await logsure.bug({ title, description, fields: { plan: 'pro', browserLog: [{ kind: 'step', t: 0 }] } });

The console shows the fields with the request.

Spam and abuse

Honeypot. Give every form a hidden, empty input named website and send it. Bots fill it in; a filled one gets the success answer and nothing is stored.
Turnstile. With a Cloudflare Turnstile secret set on the app, requests and signups also need token, the widget's response.
Rate limits and daily caps. What was turned away today shows on the app's settings page.
Spam status. Mark a request as spam in the inbox; spam is deleted after 30 days by default.

From a back-end or a native app

Back-ends and native apps send the same bodies with the app's server key as Authorization: Bearer cc_… and no Origin, and may add the person's userAgent and country. Never ship the server key inside a browser page.

What happens next

New requests and signups show in the inbox and the waitlist of every console, raise the bell in the web console, post a notification on the Mac, and call the webhooks you set (one for the server, one per app). From the inbox, a request moves between open, in progress, resolved and spam, gets private notes the sender never sees, and can be answered by email. See The console and Settings.