General FAQ

Log into the Linq Dashboard and click the “code” icon on the left-hand toolbar. There you’ll find your API key, documentation, webhook subscription management, and webhook delivery logs.

Log into the Linq Dashboard and click the “chart” icon on the left-hand toolbar to see a list of numbers and line usage analytics, including inbound/outbound message volume over different timeframes.

There are two ways to view inboxes:

1. Single-inbox view — Log into the Linq Dashboard and click the “chat bubble” icon on the left-hand toolbar.
2. Multi-inbox view — Log in and click the “file drawer” icon on the left-hand toolbar, then select the user’s inbox you’d like to view.

Your Linq line can send iMessage, RCS, and SMS messages, but in V2 there is no way to select which service to send from. When a chat is created with a non-iPhone user, the service falls back to RCS or SMS depending on the recipient’s device capabilities.

Use the Check iMessage Availability POST request, which you can poll up to once per 10 seconds per Linq line to determine what service the recipient supports.

Not before creating a chat. Check iMessage Availability only returns true/false for iMessage capability. However, on each message.sent or message.received webhook the payload includes a service field indicating iMessage, RCS, or SMS.

The Share Contact Card request pushes a contact card to recipients. It uses an iMessage-exclusive feature that presents as a popup at the top of the recipient’s message thread prompting them to add your contact. Even without pressing “Add,” your suggested name and picture display in the recipient’s thread and inbox.

You must set up your contact card first — in the Linq dashboard or via the v3 API. This is a one-time setup per phone number.

Call the Share Contact Card endpoint immediately after creating a chat, then once per 24 hours for active chats (those with activity in the last 5 minutes). Recipients sometimes neglect to add your contact on the first prompt, and if your contact card is updated you’ll want to call the endpoint again to push the latest information.

No — Share Contact Card is iMessage-exclusive.

Send recipients a .vcf file with your name, picture, number, and any other information you wish to share (email, website, address, backup numbers, etc.). Use any online .vcf generator, or create one in the contacts app on your mobile device or desktop and export it.

Automatic typing indicators are on by default. To optimize performance, we recommend controlling them yourself: contact your Linq representative to disable auto typing indicators for your line, then use the start_typing and stop_typing endpoints to drive them manually (up to 60 seconds per indicator). Typing indicators only work for active chats — those with activity in the last 5 minutes.

You can both send and receive reactions via the API. We support basic iMessage reactions: love, like, dislike, laugh, emphasize, and question. You can also subscribe to the reaction.sent and reaction.received webhook events.

Send attachments via the attachments array (binary upload) or attachment_urls (publicly-accessible URLs) on the Send Message request. Supported media includes videos, voice memos (.m4a), audio files, links, PDFs, and more.

You can’t add participants to existing group chats. As a workaround, create a new group chat with the original participants plus the new ones.

You can’t send threaded replies, but you can detect inbound threaded messages via the replied_to_chat_message_id field on the message.received and reaction.received webhook payloads.

Group-chat typing indicators are a recent iOS 26 feature and are not currently supported.

The Chat ID remains stable when participants are added or removed. The one exception: adding an Android participant to an all-iPhone group chat creates a new Chat ID. All other participant changes preserve the original ID.

The API doesn’t currently support inbound calling. You can receive inbound calls by forwarding your Linq line to a number of your choice using the Update Phone Number PUT request.

No, but if you own another phone number that supports caller-ID masking (for example, a Twilio number with Verified Caller ID), you can mask your Linq number over that line so the Linq number displays on outbound calls.

We recommend using a VOIP number (commonly Twilio) along with the inbound/outbound forwarding setups above to route calls to and from your AI voice agent using the Twilio API.

Yes — call transcription data is included in the call.completed webhook whenever a voice call is completed.

No. Webhooks fire for all numbers in your environment.

Webhooks time out after 15 seconds if your server fails to respond. There are currently no automatic retries. You can check delivery logs at the Linq Dashboard in the API tools section.

Linq sends webhooks regardless of what your server returns. Log them on your end and process asynchronously.

You can manage line usage on your side, but to prevent accidental deployment of test features into production we recommend segmenting lines into entirely separate environments.

Reach out to your Linq representative with the setup you want. We’ll separate the numbers; each environment will have its own API key accessible via the admin login we provide for that environment.

We recommend a combined total of up to 5,000 inbound + outbound messages per day per line. Volume beyond this range can degrade performance.

Linq doesn’t impose hard volume limits. The recommendation above is meant to optimize line performance. Control volume via the onboarding flows you build on your end.

It’s nuanced — it depends on how much your AI agent sends and how users interact with it. We recommend running a pilot line, onboarding users, and calculating the average inbound/outbound message count per user. Use that to determine how many users can onboard before hitting the ~5,000 messages/day recommended limit.

Scheduled maintenance is communicated in advance. For platform outages, monitor live status and subscribe to updates via our Status page.

Use a backup Twilio number to maintain service if your Linq line becomes inoperable. Add the backup number to a .vcf file alongside your Linq number and share it with users at onboarding. If service falls back to the Twilio number, messages still appear in the existing thread, preserving continuity.

Flagging is one of the most common reasons. A line can become flagged when iMessage capability is restricted for the number — typically driven by recipient complaints or sudden volume spikes that look automated. We’ll reach out if your line is flagged and offer guidance on resolution, including whether the number can be recovered or whether we’ll issue a new one.

Best practices to reduce flagging risk:

1. Inbound flow — Have users message your number first. Recipient-initiated chats reduce the risk of recipient complaints since the user initiated contact.
2. Load balance — Onboard users evenly across multiple Linq lines.
3. Ramp up usage gradually — Avoid large volume spikes during onboarding.
4. Ensure your AI isn’t aggressive — AI that aggressively follows up (especially unsolicited) can cause users to block your number, which increases the risk of your line being flagged.
5. Honor opt-out language — Detect and respect opt-out keywords from users.
6. Use multiple lines — Shard across multiple numbers so service remains operational if one becomes unavailable. You can also include fallback Linq numbers on the .vcf files you share with users.
7. Have us warm your lines — On request, we can warm new lines before production use. Warming averages 5–7 days and increases line resiliency under real traffic.