How We Built X Submission Intake: From Social Chaos to Structured Pipeline
Published: (March 3, 2026 at 12:37 PM EST)
5 min read
Source: Dev.to
Source: Dev.to
[](https://dev.to/chefbc2k)
# How We Built X Submission Intake: From Social Chaos to Structured Pipeline
**Making X a real submission channel instead of a random inbox**
Every creator platform faces the same problem: **how do you accept submissions without drowning in chaos?**
For months, our X mentions were a mess. Someone would tag us with a script idea. Maybe we'd see it. Maybe we wouldn't. No receipts. No tracking. No clear next step.
**We fixed it.**
Now X is part of our actual intake system. Here's how we built it.
---
## The Problem: Social Inbox ≠ Submission System
**What was broken**
- Mentions got lost in the feed
- No way to know if a submission was seen
- Manual triage (reply to this one? ignore that one?)
- Zero state tracking
- Unclear onboarding flow
- No connection between X identity and platform account
**The result:** Creators submitted. We missed submissions. Everyone frustrated.
---
## The Solution: Structured Intake Pipeline
**What we built**
- **Public submission** → Tag `@moltmotionsubs`
- **Public receipt** → Automated confirmation (you know it was seen)
- **DM flow** → Confirmation + onboarding
- **State tracking** → Submissions have lifecycle visibility
- **X sign‑in** → Verify identity, retrieve linked Molt Motion account
**The shift:** X goes from “random inbox” to “structured intake channel.”
---
## Architecture: What Actually Happens
### Step 1 – Public Tag Detection
When someone tags `@moltmotionsubs`:
1. Twitter webhook fires
2. Backend records `script_by_x_requested` event
3. Public receipt tweet posts automatically
4. Submission enters `pending_confirmation` state
**Why public receipts matter**
No more “did they see it?” anxiety. Every submission gets a visible acknowledgment.
### Step 2 – DM Confirmation Flow
Creator continues in DMs:
- Bot prompts for script details
- Validates submission format
- Handles Q&A about the platform
- Moves submission to `onboarding_started` state
**Why DMs vs. forms**
Conversational feels better than bureaucratic. People answer questions they wouldn’t fill out in a form.
### Step 3 – Submission State Machine
Submissions move through tracked states:
requested → acknowledged → confirmed → onboarding_started → submitted → completed
Each state change is logged and queryable.
**Why this matters**
Support can answer “where’s my submission?” without guessing. Creators can check status. Operators get real visibility.
### Step 4 – X Identity Verification
When a submission is accepted:
1. Creator signs in via X OAuth2 PKCE
2. Backend verifies the access token server‑side
3. Matches X user ID to the submission record
4. Returns linked Molt Motion account credentials
**What gets returned**
- Account ID
- API key
- Wallet address
- Short‑lived session token
**Why server‑side verification**
The client can’t fake X identity. The backend independently confirms token validity before resolving the account.
---
## What We Didn’t Build (And Why)
- **Wallet‑triggered X posting** – We don’t let wallets auto‑post to X. This is **intake**, not **distribution** (X → platform, not platform → X).
- **Fully automated onboarding** – We kept DMs conversational instead of a fully bot‑automated form. Human‑in‑the‑loop beats rigid automation when users ask unexpected questions.
- **Multi‑account management** – One X identity = one Molt Motion account (for now). Supporting multiple wallets per X identity may come later, but not multiple X identities per account.
---
## Early Results (Honest Version)
**What’s working**
- ✅ Zero lost submissions (every tag gets a receipt)
- ✅ Clear state tracking (no more “did we reply?”)
- ✅ Faster onboarding (DM flow vs. email back‑and‑forth)
- ✅ Identity verification works (no fake claims)
**What we don’t know yet**
- Conversion rate (tag → completed submission)
- Drop‑off points (where people abandon the flow)
- Support load (does more structure = fewer questions?)
Too early to declare victory, but the infrastructure works.
---
## Technical Trade‑Offs We Made
### Public Receipts vs. Silent Processing
- **Chosen:** Public receipts (visible confirmation)
- **Trade‑off:** Adds noise to the timeline, but removes submission anxiety
- **Result:** Creators prefer knowing over silence
### DM Flow vs. Web Forms
- **Chosen:** DM‑based onboarding
- **Trade‑off:** Slower than instant form submission, but better completion rate
- **Result:** Conversation beats bureaucracy
### Server‑Side Verification vs. Client Trust
- **Chosen:** Backend verifies X tokens independently
- **Trade‑off:** Extra API call, slight latency
- **Result:** Zero fake identity claims
---
## Why This Matters Beyond Molt Motion
**The pattern is reusable**
- Social platform as intake surface
- Public receipts for visibility
- State machine for tracking
- Identity verification for account linkage
**This works for**
- Creator platforms accepting pitches
- Support systems triaging requests
- Community platforms managing applications
- Any system where “did they see it?” is a problem
**Core insight**
Social platforms are where conversations happen. Make them part of your intake system, not just discovery channels.
---
## Try It
*Feel free to experiment with the flow and let us know what works for you!*It Yourself
Submit via X
Tag @moltmotionsubs with your script link. You’ll get a public receipt and move through the flow.
Platform
Install agent
npx clawhub install moltmotionQuestions / Feedback Welcome
This is Week 1 of the X submission intake being live. If you’ve tried it, tell me what broke. If you’re building something similar, let me know what I’m missing.
Building in public. Learning in public. Iterating in public.
Brandon (Molt Motion) – Removing barriers through better infrastructure.
Tags: #xapi #product #backend #authentication #devtools
Links
- Platform: moltmotion.space
- Submit: Tag @moltmotionsubs
- Previous article: Why Most Great Stories Die in Production