Skip to main content
Your users connect their X (Twitter) accounts while staying in your product. They need no Xquik signup, and each account belongs to your Xquik account. Connecting is free. Start with a connect link. Choose the direct API only if your product must own the form.
Create a link from your backend.
Open the answer’s url in a pop-up or a new tab. The page can’t load in a frame. The person enters their X username, email, password & Authenticator App 2FA secret there. The page names your Xquik account, and asks for any code X emails them. Then read the link with its id. Once status reads connected, you get accountId, xUserId, xUsername, health & your reference.
  • A link works for 30 minutes and connects 1 account. Only its hash is stored.
  • 5 refused logins end a link, so it can’t be used to guess passwords.
  • The page takes the token out of the address bar, and sends no cookies.
  • It offers your returnUrl as a button. It never redirects by itself.
  • Send accountId to make a reconnect link. It refuses a sign-in for any other X account.
Treat url like a password until it’s used. Keep it out of logs & analytics. Revoke it if you send it to the wrong person.

​
Use the direct API

With this path, your backend receives each user’s X password and 2FA secret. Your duties lists what that makes you responsible for.

​
Turn on the permission

Open dashboard.xquik.com/api-keys and edit a key. Turn on Connect X accounts. It starts off on every key. Full access doesn’t include it, and only a signed-in dashboard session can change it. A key without it gets 403 x_account_connect_permission_required. OAuth tokens and MCP tools always get 403 session_required. X passwords never reach a model.

​
Connect an account

Generate a connection_attempt_id first. You can then read the result even if the response never arrives.
totp_secret is the long Authenticator App key, not a 6-digit code. Connect X account explains how a user finds it.

​
Handle each answer

A successful attempt read gives accountId too.

​
Reconnect, retry & disconnect

When a password changes or health reads needsReauth, call reconnect with the new password. It answers like a connect. It refuses a sign-in that belongs to another X account. Bulk retry clears passing failures, so you never send a password for those. Disconnect removes an account and its stored session. Account activity records each connect, reconnect & disconnect with the key’s ID.

​
Your duties

Your product collects X passwords, so these become your job.
  • Tell users you collect their password and send it to Xquik.
  • Send it only over HTTPS, and only from your backend.
  • Keep request bodies out of your logs, traces, error reports & analytics.
  • Never store the password or 2FA secret once Xquik answers.
  • Keep this key in a secret store, and set its allowed IPs.
  • Use a separate key for connecting, and pause it when you don’t need it.
Xquik encrypts credentials at rest and never returns them.

​
Act as each account

Send account on each write and DM call to pick which connected account acts. List X accounts gives each account’s status and health.

​
Limits

These hold on both paths. Failed logins slow a caller down. Each account you connect lifts that limit, so onboarding many users isn’t capped. A caller with no connected accounts gets 10 failed logins per 15 minutes. One X account gets 5 refused logins per 15 minutes, across all callers. A 429 always says how long to wait.