Pull shipment details from notification emails

Read every inbound shipment notification email and pull out carrier, tracking number, origin, destination, and ETA. Structured records land in your tracking table without anyone typing.

The prompt

I want to monitor my inbox for inbound shipment notification emails and pull the key details out of them. Can you build me a flow that reads incoming emails, uses AI to extract carrier, tracking number, origin, destination, and ETA, and loads the structured records into a table?

Just copy and paste the prompt into a new Parabola flow to get started.

What Parabola builds

A workflow with six steps you can edit:

1. Monitor the inbox. The flow watches the shared shipment inbox for new notification emails. It picks up everything that matches the carrier sender list.

2. Classify the email. Is this a booking confirmation, a milestone update, or an exception notice? Each type gets routed to the right extraction template.

3. Extract the structured fields. Carrier, tracking number, origin, destination, ETA, service level, weight, container or BOL number. The AI step reads the email body and pulls the values.

4. Normalize the data. Carrier names get mapped to your canonical list. Dates land in one format. ETA gets converted to your operating timezone.

5. Dedupe against the existing record. If the same shipment already exists in the table, the new email updates the milestone instead of creating a duplicate row.

6. Write the record. Push it to your shipment tracking table, your TMS, your ERP, or a shared spreadsheet the team works from.

Why teams stop doing this manually

Shipment data lives in the inbox. Carriers email booking confirmations. Forwarders send milestone updates. 3PLs forward exception notices. Each one carries the same five fields the team needs, but in five different formats, with three different sender domains, and in body copy that changes slightly every month when the carrier updates their template.

The manual version is one person on the ops team treating their inbox as a queue. Open the email, read the body, copy the tracking number, type it into the shipment sheet, set the ETA, mark the row, move to the next email. A team of two operators can keep up with a few dozen a day. The volume that comes with a real freight book outpaces that work within a week of onboarding a new shipper.

The cost of falling behind is visibility. The customer asks for an ETA and the team has to dig through the inbox to find the latest. The shipment lands in port and nobody updates the operating system. The customer service team gives the wrong answer because the data lives in someone's email instead of the shared table.

How it works

Step 1. Paste the prompt.

Open Parabola, paste the prompt in section 2, and let it ask follow-up questions about which inbox, which carrier senders, and what fields you want extracted on every record.

Step 2. Connect your data.

Inbox connector for the shared mailbox. Destination connector for whichever system holds the shipment table. Optional carrier reference list for the canonical name mapping.

Step 3. Run it on every email.

The flow triggers when a new email lands, runs the extraction, and writes the record. Customer service and the ops team work from a table that's always current.

FAQ

Does this work on emails that have the data in a PDF attachment instead of the body?

Yes. The flow checks the body first and falls back to the attachment when the body doesn't carry the fields. PDF parsing is the same AI step that handles other freight documents.

What if a carrier changes their email template?

The AI extraction is layout-agnostic and adapts to format changes on the next inbound. No code update needed. If a template change introduces a new field, add it to the schema and the flow picks it up on the next run.

How does the flow handle duplicate or partial updates on the same shipment?

A dedupe step matches the new email against the existing record on tracking number and BOL. New milestones update the row. Conflicting data gets flagged for a human to resolve.

Can the flow write back to multiple downstream systems?

Yes. Add as many destinations as you need. A common setup is to write to the shipment table for ops, push a milestone to the customer portal, and post an alert to a Slack channel for critical shipments.

What about emails that aren't shipment notifications at all?

The classification step filters them out. Internal threads, replies, and unrelated emails get ignored. Only the recognized notification types flow into the extraction.
Your inbox is a shipment table waiting to be parsed.
Paste the prompt, point it at your shared mailbox, and let the extraction load every record automatically.
Start for free