Capability Checks
Probe whether a handle can receive iMessage or RCS before sending.
Check whether a recipient address supports iMessage or RCS before sending a message.
Use capability checks to pick the right protocol, to gate rich-only features (effects, decorations), or to fall back gracefully to SMS when a richer service isn’t available.
You do not need to capability-check every send — the API selects the best available service automatically when preferred_service is omitted. Capability checks matter when you want to make product decisions before calling POST /v3/chats.
Check iMessage capability
Section titled “Check iMessage capability”POST the recipient handle to /v3/capability/check_imessage. The response includes an available boolean — branch on it to decide whether to use iMessage-only features. See the Check iMessage API reference.
curl -X POST https://api.linqapp.com/api/partner/v3/capability/check_imessage \ -H "Authorization: Bearer $LINQ_API_KEY"await client.capability.checkiMessage();client.capability.checki_message()client.Capability.CheckiMessage(context.TODO())Check RCS capability
Section titled “Check RCS capability”Same shape against /v3/capability/check_rcs. See the Check RCS API reference.
curl -X POST https://api.linqapp.com/api/partner/v3/capability/check_rcs \ -H "Authorization: Bearer $LINQ_API_KEY"await client.capability.checkRCS();client.capability.check_rcs()client.Capability.CheckRCS(context.TODO())Request fields
Section titled “Request fields”| Field | Required | Description |
|---|---|---|
address |
Yes | Recipient handle — phone number (E.164) or email address for iMessage |
from |
No | One of your provisioned numbers to run the check from — pins the result to a specific line |
When to use each service
Section titled “When to use each service”| If the check says… | Do this |
|---|---|
| iMessage capable | Send with preferred_service: "iMessage" to unlock effects, decorations, read receipts, editing |
| RCS capable | Send with preferred_service: "RCS" for rich features on Android |
| Neither | Fall back to SMS/MMS, or let automatic selection pick SMS |
Caching results
Section titled “Caching results”Capability is a property of the recipient’s device and account, not a static attribute of the phone number — a user switching from iPhone to Android, or disabling iMessage, changes the answer. Cache results only briefly (minutes, not days), and refresh on any message.failed event whose error suggests a service mismatch.
Rate limits
Section titled “Rate limits”Capability check endpoints are rate-limited to prevent abuse (e.g. using them to enumerate which numbers are on iMessage). Excessive calls return HTTP 429 with a Retry-After header and error code 1007. Caching results as described above is the easiest way to stay under the limit. See Rate Limits for the full response shape and retry handling.
Related
Section titled “Related”- Protocol Selection — how services are picked and what each supports
- Sending Messages — using
preferred_serviceon send - Key Concepts: Handles — the handle model
- Rate Limits — handling
429responses from capability endpoints - API Reference: Capability — complete endpoint specification