Receive a request for quote

Every trip request your operation works starts as one row in the RFQ inbox (/os → RFQ Inbox), no matter how it arrived. Obsidian Jet supports three intake paths into that same inbox. This page covers all three so you know where a request came from and, for email, how a reply threads back onto the record instead of spawning a duplicate.

1. The embeddable quote widget

If you've embedded the quote widget on your own website, a visitor who requests a quote or asks for a callback creates an RFQ automatically.

1. A visitor fills out the widget's trip form (or an empty-leg inquiry) on your site.
2. The widget POSTs the trip and the visitor's name/email to your tenant's RFQ inbox, authenticated with the widget's publishable key — the same key that authorizes the widget's pricing calls, scoped narrowly to lead-write only.
3. The request appears in your RFQ inbox tagged WEB LEAD, with the origin, destination, date, and pax already parsed from the structured form fields.
4. If the capture succeeds, the widget can hand the visitor a hosted-page link that resumes their trip context — but the widget never claims a lead was captured unless the server actually persisted it.

2. Inbound email

Forward or route mail to your tenant's inbound parse address and it lands as an RFQ the same way a widget lead does — including replies, which thread onto the existing record instead of creating a new one.

1. An operator-admin finds the tenant's provisioned parse address under Inbound Email (/os → Inbound Email, admin-only) and sets up forwarding from their own domain to it.
2. A new inbound message (delivered via the Postmark inbound adapter on the public mail sink) is parsed for origin, destination, date, and pax, and creates a new RFQ — a message that doesn't parse cleanly still creates the row rather than getting dropped.
3. A reply to that thread is recognized two ways, in order: first by the per-record reply address the outbound message carried, then by matching the reply's In-Reply-To/References headers against a message already on file for your tenant. Either way, the reply attaches to the same RFQ or quote record as a new message — it never creates a second RFQ for a conversation already in progress.
4. Only when neither match applies does the message start a brand-new RFQ — and that RFQ immediately gets its own reply alias, so anything sent back on that thread from here on threads correctly too.

3. Manual entry in the OS console

Phone calls and walk-ups don't arrive as email or widget traffic, so a sales user can log them by hand from the same inbox.

1. From the RFQ Inbox, click + New Request.
2. Enter origin, destination, date, and pax. Optionally pick the caller from your CRM accounts (or fall back to a free-text name/email for a caller who isn't in your CRM yet), or apply a saved lane template to prefill a repeat route.
3. Submit. The request lands in the inbox with status new, exactly like an inbound lead — the same triage and convert-to-quote steps apply to it.

Once a request is in the inbox, the next job is triaging it and converting it to a quote — see Triage the RFQ inbox and convert it to a quote.