Almost every ping problem is one of five things, and four of them produce the same symptom: calls stop arriving and nothing in your logs looks broken. Work down this list in order.
Symptom: no calls arrive at all
Start by confirming whether requests are reaching you. If your endpoint is not being called, the problem is configuration or reachability. If it is being called and you are answering, the problem is your response.
- Check that the ping configuration is enabled in Delivery controls, not just saved.
- Check your access logs for POST requests from outside your network. No requests at all means Callmart cannot reach you.
- Confirm the URL in your workspace is the exact path your handler serves, including any trailing segment.
- Confirm you are on HTTPS, port 443, with a publicly resolvable hostname.
- Confirm your certificate chain is complete and not expired. Browsers forgive an incomplete chain more readily than server to server clients do.
Symptom: requests arrive, every call is declined
This is the common one, and the cause is nearly always the response body.
| What you returned | Why it declined |
|---|---|
| A new request_id, or one you generated | The request_id must be copied exactly from the request. A mismatch is a decline. |
| "accept": "true" as a string | It must be a JSON boolean, not a quoted string. |
| An empty body with a 200 status | A 200 with nothing parseable is not an acceptance. The body has to carry both fields. |
| HTML, or a JSON error page from a proxy | Anything that is not valid JSON with the two fields is a decline. Check what your load balancer returns on error. |
| A correct body, but slowly | Past three seconds the request is abandoned regardless of what you eventually send. |
Test this in isolation. Send yourself a request with a known request_id and assert that the bytes coming back are exactly what you expect, from outside your own network, through whatever proxy sits in front of the app.
Symptom: intermittent declines under load
If acceptance rate falls when you get busy, you are hitting the three second timeout. The fix is architectural, not a bigger timeout, because there is not a bigger timeout.
- Take every synchronous call to a database, a CRM, or a third party out of the ping path. Serve the decision from memory or a local cache that a background process refreshes.
- Measure your own p99, not your average. The average is irrelevant here because the limit is per request.
- Check for connection pool exhaustion and cold starts. Serverless handlers that scale to zero are a frequent cause.
- Check for a proxy or WAF adding latency, or rate limiting Callmart's requests as if they were an attack.
Symptom: auth failures
Callmart sends your API key as Bearer followed by the key, in the Authorization header. If you are rejecting valid requests, compare the raw header value byte for byte against what you stored.
- A trailing newline or space on the key when it was pasted in is the usual culprit.
- Some frameworks lowercase or strip headers. Read the header in a case insensitive way.
- If you rotated the key on your side, update it in Delivery controls at the same time, not afterward.
How to confirm a fix
Use test traffic. Requests with is_test set to true let you exercise the whole path without affecting real calls. Watch for three things in order: the request arriving, your response being well formed, and your response time comfortably under a second.
If you have worked through all of this and requests still are not arriving, contact support at support@callmart.io with a few request IDs and the timestamps you expected them, and we can check from our side. Do not send us your API key.
Common questions
01Does Callmart retry a failed ping?
No. There is one request and one response. A timeout, an error, or an unparseable body is a decline, and the call is offered elsewhere. This is why fast, explicit declines matter more than getting every decision perfect.
02Will I be told my endpoint is failing?
Do not rely on it. Monitor your own endpoint's error rate and latency, because it is your system and you will see a problem long before anyone else does.
03Can a slow response still get the call?
No. Once the three second HTTP timeout passes, the request is abandoned. A correct answer that arrives at four seconds is the same as no answer.