Verify a key without sending
POST is recommended for client integrations. GET remains supported for compatibility. Both methods are read-only and use the same response contract; no body fields are required.
POST https://www.webwms2u.com/api/connection-status.php
This read-only endpoint checks an active API key, its account and the stored sender connection. It sends no messages, reserves no credits and needs no recipient, template or message ID.
curl --request POST 'https://www.webwms2u.com/api/connection-status.php' \
--header 'Authorization: Bearer YOUR_API_KEY' \
--header 'Accept: application/json'X-API-KEY is also supported. Keys in URLs or request bodies are not accepted.
Call from your application backend over HTTPS; keep keys out of browser scripts and logs.
Response example
{
"success": true,
"key_valid": true,
"channel": "personal",
"account_enabled": true,
"subscription_valid": true,
"channel_connected": true,
"ready": true,
"error_code": null,
"message": "API key verified; account and stored channel status are available",
"status_source": "database",
"checked_at": "2026-11-02T14:00:00+00:00",
"request_id": "..."
}| Field | Meaning |
|---|---|
| success | The status lookup completed successfully. This alone does not indicate readiness. |
| key_valid | True: active key matched. False: missing, invalid or inactive key. Null: verification was not completed, for example a database failure before key lookup. |
| channel | personal or meta, determined by the key. Null until a key matches. Coexistence uses meta. |
| account_enabled / subscription_valid | True or false once checked; null when not checked. Subscription expiry follows the send endpoint's UTC date rule. |
| channel_connected | Stored sender is available and authorized using the send endpoint's routing rules. Null if not checked. |
| ready | True only after active key, enabled account, unexpired subscription and available sender checks pass. |
| error_code / message | Reason the check failed or the channel is unavailable. Do not use message text for program logic. |
| checked_at / request_id | UTC check time and request identifier, also returned in X-Request-ID. |
HTTP results
| HTTP | Result | Portal display |
|---|---|---|
| 200 | key_valid true; ready true | Verified / connected according to stored status. |
| 200 | key_valid true; ready false; DEVICE_NOT_CONNECTED or META_NUMBER_UNAVAILABLE | Key verified; channel unavailable. |
| 401 | key_valid false; AUTH_MISSING or AUTH_INVALID | Missing or invalid/inactive key. |
| 403 | key_valid true; ACCOUNT_NOT_FOUND, ACCOUNT_DISABLED or ACCOUNT_EXPIRED | Key verified; resolve account status. |
| 405 | METHOD_NOT_ALLOWED | Use POST or GET. |
| 500 | INTERNAL_ERROR; key_valid can be null or true depending on how far verification got. | Unable to verify; retry later. Do not label the key invalid. |
Integrating with your application
- Configure the server-side read-only status URL as
https://www.webwms2u.com/api/connection-status.php. - Send the saved key in the Authorization header. Do not call send-message.php for this check.
- Parse JSON on non-200 responses too. Use strict boolean comparisons.
- Compare the returned channel with the channel selected in your application: Personal expects personal; Meta or Coexistence expects meta. A mismatch should prevent a green ready indication.
- Show green only when success, key_valid and ready are all true and the channel matches.
- A timeout, invalid JSON, HTML response or HTTP 500 means verification is unavailable. Preserve that distinction from an invalid key.
Cache results for up to 300 seconds if desired, and invalidate the cache whenever the key or selected channel changes.
The endpoint returns Cache-Control: no-store; application status caching must be intentional.
Always returns standard HTTP statuses. It does not require X-API-Version and does not use the sending endpoint's legacy HTTP-200 error mode.