Intakes
Intakes are how briefs get into Lithify. Each project can have any number of intakes; each intake has a type (the handler) and a slug (the public identifier). Five types ship out of the box.
Built-in intake types
Web form
Humans · public linkConfigurable form fields rendered at /submit/<slug>. No auth, no API key. Great for customer-facing feedback links.
OpeniOS feedback
iOS apps · API keyJSON-over-HTTP intake with structured fields for device / OS / app version / screen / repro steps.
OpenEmail (IMAP)
Submitters · emailPoint a mailbox at Lithify. Subjects → titles, bodies → descriptions, attachments → brief attachments.
OpenSentry webhook
Sentry · webhook signed bodyMap Sentry issues into briefs. Levels → priorities, stack traces → descriptions, links back to Sentry preserved.
OpenPlanning form
PMs · public linkSame shape as a web form, but produces an initiative (a planning artefact that spawns child briefs) instead of a brief.
OpenHow intakes flow into briefs
inbox stateWhat every intake produces
No matter which channel a brief came from, what lands inside Lithify looks the same: a title, a description, an optional type and priority, and any attachments that came along. Whatever extra context the channel sent — Sentry's release tag, an iOS app version, the email's sender — is kept on the brief so reviewers can always see exactly what came in, even if the agents don't use it.
How each channel is protected
| Intake | Who can submit |
|---|---|
| Web form, planning form | Anyone with the link — these are public by design. |
| iOS feedback | Whoever holds the project's API key. |
| Sentry webhook | Verified by a signed webhook secret you configure on both sides. |
| Whoever can email the mailbox you point at Lithify. |
Per-intake AI settings. An intake can use a different AI model than the project default. Handy when one channel (e.g. iOS feedback) is chatty and you want to keep its costs down without affecting the rest.