Extract data from email

You write what you want, for example "booking reference, guest name, check-in date, check-out date, number of guests, total price, special requests". ParsedMail turns that sentence into a typed schema you can review: field names, types and which fields are required. Adjust anything, add descriptions where a field is ambiguous ("total price including taxes"), and test the schema against a real sample email in the dashboard before switching on live mail.

There is no template per sender and no regular expression to maintain. The same schema reads a booking from a channel manager, a forwarded guest email and a reservation in a PDF. This is the core difference explained on the AI email parser page.

Values are converted to their declared type before delivery, so your code does not have to clean them:

A schema holds up to 60 fields. The exact JSON shape is described on parse email to JSON, and every schema exports as JSON Schema draft 2020-12.

The model is instructed to use only text present in the message and its attachments. Quoted replies, signatures and footers are ignored, so the sender's phone in a signature does not end up as the customer phone of a forwarded order. A value that is not there comes back as null. A value that is there but cannot be converted, such as "sometime next week" in a date field, also becomes null with an entry in warnings.

Each field gets a confidence score from 0 to 1 and the email gets confidence_avg. In the example above the special requests score lower than the booking reference, because they come from a free-text note. Use the scores in your own code, for example to auto-confirm bookings above 0.9, or let ParsedMail route anything under a threshold to the human review queue on Growth and Scale. A missing required field always scores 0.

Data often sits partly in the body and partly in a PDF or CSV. ParsedMail reads up to 8 attachments per email and merges what it finds into the same fields, including tables of line items. Scanned PDFs and images are read as images on paid plans. See parsing email attachments for formats and page counting.

Requirements change: finance wants a cost center, the warehouse wants the delivery window. Edit the schema and its version number increments. Each parsed email records the schema_version it used, and you can replay stored emails against the new version. A replay of an email that was already counted is not counted again, so fixing a schema does not eat your quota.

Extraction is not only about copying values. An enum field turns a free-text email into a decision your automation can branch on. Define "request type, one of new order, change, cancellation, complaint" and every email comes back with exactly one of those options, never a fifth variant spelled differently. A boolean such as "refund requested" or "urgent" works the same way. Your Zapier path, n8n switch node or own code can route on these fields without any text matching.

This is where reading meaning pays off. A customer who writes "please do not send the second box after all" never uses the word cancellation, but the enum still comes back as cancellation, with a confidence score that tells you how sure the model is. The support email use case shows a full routing setup.

• Forwarding. Each inbox has an address such as [email protected]. Point a Gmail filter, an Outlook rule, a mail server alias or a BCC at it. Plus tags such as [email protected] reach the same inbox.
• API. Post raw MIME, pasted text or structured fields to POST /inboxes/{id}/emails, or call POST /parse for a synchronous result.
• Own domain. On Scale, receive on an address like [email protected] with an MX record.

Allowed senders per inbox (single addresses or whole @domain entries) keep stray mail out; anything else is logged as blocked_sender and not counted. Duplicates by Message-ID, or by the same sender, subject and body within 30 days, are marked duplicate and not charged.