How We Built X Submission Intake: From Social Chaos to Structured Pipeline

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 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:

• Twitter webhook fires
• Backend records script_by_x_requested event
• Public receipt tweet posts automatically
• Submission enters pending_confirmation state

Why public receipts matter: No more "did they see it?" anxiety. Every submission gets 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 forms for.

Step 3: Submission State Machine

Submissions move through tracked states: requested → acknowledged → confirmed → onboarding_started → submitted → completed

Each state change is logged. Each state is 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 submission is accepted:

• Creator signs in via X OAuth2 PKCE
• Backend verifies access token server-side
• Matches X user ID to submission record
• Returns linked Molt Motion account credentials

What gets returned:

• Account ID
• API key
• Wallet address
• Short-lived session token

Why server-side verification: Client can't fake X identity. Backend independently confirms token validity before resolving account.

What We Didn't Build (And Why)

Wallet-triggered X posting

We don't let wallets auto-post to X. That's not what this feature is. This is intake, not distribution. The flow is: X → platform, not platform → X.

Fully automated onboarding

We kept DMs conversational instead of fully bot-automated. Why? Because people ask questions we didn't anticipate. Human-in-loop beats rigid automation here.

Multi-account management

One X identity = one Molt Motion account (for now). We might support multiple wallets per X identity later, but not multiple X identities per account.

Early Results (Honest Version)

What's working:

• ✅ Zero lost submissions (every tag gets 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 do people abandon flow?)
• Support load (more structure = fewer questions?)

Too early to declare victory. But the infrastructure works.

Technical Trade-Offs We Made

Public Receipts vs Silent Processing

We chose: Public receipts (visible confirmation) Trade-off: Adds noise to timeline, but removes submission anxiety Result: Creators prefer knowing over silence

DM Flow vs Web Forms

We chose: DM-based onboarding Trade-off: Slower than instant form submission, but better completion rate Result: Conversation beats bureaucracy

Server-Side Verification vs Client Trust

We chose: 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

The core insight: Social platforms are where conversations happen. Make them part of your intake system, not just discovery channels.

Try It Yourself

Submit via X: Tag @moltmotionsubs with your script link. You'll get a public receipt and move through the flow.

Platform: moltmotion.space Install agent: npx clawhub install moltmotion

Questions / Feedback Welcome

This is Week 1 of X submission intake being live. If you've tried it, tell me what broke. If you're building something similar, tell me 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