The TikTok DM outreach API

Is there an official TikTok API for sending DMs?

No. As of June 2026, TikTok offers no official API for initiating direct messages to people who haven't contacted you first. The only official messaging surface — the Business Messaging API — is built for inbound support, not outreach.

Its constraints make that explicit: a user must message your business first, you get a 48-hour reply window, you can send roughly 10 automated messages per window, and broadcasting is disallowed. That's exactly why inbound tools built on it (ManyChat being the best-known) cannot initiate a single cold DM.

So every true cold-DM tool on the market operates outside the official API — including Hooka. We say that plainly because it shapes the whole design: the Hooka API is a managed programmatic layer over real TikTok accounts. You call clean REST endpoints; Hooka runs the real Chrome sessions, enforces per-account daily caps and message spacing server-side, and pauses sends for exactly 5 minutes whenever TikTok signals "sending too fast". The numbers behind those defaults are in our guide to TikTok DM limits in 2026.

How does the Hooka API work?

It works the way you'd expect if you've used Stripe: a versioned REST API (current version 2026-06-01), bearer-key auth, typed object IDs and predictable JSON. The conventions:

• Keys: hk_live_ and hk_test_ bearer keys, created self-serve from the Developers page in your dashboard. They're stored as sha256 hashes and shown exactly once — copy them when you create them.
• Typed IDs: every ID tells you what it points at — snd_ for senders, cmp_ for campaigns, tgt_ for targets.
• Idempotency: pass an Idempotency-Key header on writes and retries are safe for 24 hours — no duplicate campaigns, no double sends.
• Tracing: every response carries a Hooka-Request-Id header you can reference in support tickets.
• Rate limit: 300 requests per minute.

Everything the dashboard does for outreach — senders, campaigns, the whole feature set from sender rotation to the unified inbox — sits on the same engine your API calls drive.

Quickstart: from API key to first campaign in four calls

This is the entire core flow. Connect a sender, create a campaign, add targets, start it — then listen for webhooks.

1. Connect a sender

Connection is QR-only and password-free: the call returns a QR code, you scan it from the TikTok app, and the account flips to connected. Hooka keeps session cookies only — never a password.

curl -X POST https://api.hooka.to/v1/senders \
  -H "Authorization: Bearer hk_live_..." \
  -d '{ "label": "outreach-account-1" }'

# → { "id": "snd_...", "status": "pending", "qr": "..." }

2. Create a campaign

Campaigns take message variants (up to 20 per step, picked at random per send), follow_ups (up to 10 steps, each delayed 1–60 days, each with its own variants) and settings. A follow-up only goes out if the lead hasn't replied — replies always stop the sequence.

curl -X POST https://api.hooka.to/v1/campaigns \
  -H "Authorization: Bearer hk_live_..." \
  -H "Idempotency-Key: 1d4e8f2a-launch-june" \
  -d '{
    "name": "UGC outreach — June",
    "variants": [
      "Hey {{handle}} — loved your last video. Quick question...",
      "Hi {{handle}}, we work with creators like you on..."
    ],
    "follow_ups": [
      { "delay_days": 3, "variants": ["Bumping this, {{handle}} — still interested?"] }
    ],
    "settings": { "daily_limit": 100, "spacing_seconds": 7 }
  }'

3. Add targets

Up to 1,000 handles per batch, each with arbitrary per-target variables (like {{first_name}}) you can use in any variant. Duplicates, already-contacted handles and anyone on your Do-Not-Contact list are skipped automatically, with skipped counts returned per batch.

curl -X POST https://api.hooka.to/v1/campaigns/cmp_.../targets \
  -H "Authorization: Bearer hk_live_..." \
  -d '{
    "targets": [
      { "handle": "creator_one", "variables": { "first_name": "Mia" } },
      { "handle": "creator_two", "variables": { "first_name": "Leo" } }
    ]
  }'

4. Start it

curl -X POST https://api.hooka.to/v1/campaigns/cmp_.../start \
  -H "Authorization: Bearer hk_live_..."

From here the engine takes over: sends are spaced server-side (default 7 seconds, configurable 3–300s), capped per account per day, and rotated across up to 10 connected senders. Your job is done — listen for events.

How do webhooks work?

Register an HTTPS endpoint via POST /v1/webhook_endpoints and Hooka pushes 12 event types as your campaigns run, including:

• sender.connected and sender.status_changed — account health changes (cooldown, disconnected, banned)
• campaign.started and campaign.completed
• target.sent — a DM left the queue
• target.replied — carries an opt_out flag when the lead asked to stop (Hooka auto-blacklists them)
• message.received — any inbound message, for piping into your CRM

Every delivery is HMAC-SHA256 signed so you can verify it really came from Hooka:

Hooka-Signature: t=1781222400,v1=4f0a9c2e8b7d6f5a3c1e0d9b8a7f6e5d4c3b2a190817263544536271809f8e7d

Deliveries time out after 10 seconds. Failed deliveries are retried at 1m, 5m, 30m, 2h, 6h and 24h — up to 8 attempts. Can't host an endpoint? Poll GET /v1/events instead: it exposes the same event stream as a fallback or reconciliation sweep.

Frequently asked questions

Keep reading