API
Ping and health check: is it me or is it you?
Two tiny endpoints that separate a credentials problem from an outage — GET /ping proves your key works, and GET /up reports whether the API itself is healthy.
Last updated September 2, 2026
When an integration stops working, the first question is always whether the problem is your credentials, your request, or the API. These two endpoints answer it in seconds.
Ping: are my credentials good?
GET https://api.gorilladash.com/api/v1/ping, with your two authentication headers. A 201 with {"ping":true} in the data means the key and access token are valid and the API is switched on for your organisation.
| Response | What it tells you |
|---|---|
| 201 | Credentials are good. Any failure elsewhere is about that request, not your key. |
| 401 | The key and access token are missing, mismatched or wrong. |
| 403 | Credentials are fine, but the RESTful API is switched off for your organisation. |
| 429 | You are over the rate limit — which is itself worth knowing. |
Health check: is the API up?
GET https://api.gorilladash.com/api/v1/up needs no credentials at all. It returns 200 with {"status":"ok","checks":{"database":true,"redis":true}} when the service can reach everything it depends on, and 503 when it cannot.
It is an infrastructure probe, so it deliberately breaks the usual conventions: real 200 and 503 status codes rather than the standard 201, and a flat body with no envelope.
Using them to diagnose
/up | /ping | Conclusion |
|---|---|---|
| 200 | 201 | The API and your credentials are both fine. Look at the specific request that is failing. |
| 200 | 401 | The API is fine. Your key or access token is wrong, or someone regenerated it. |
| 200 | 403 | The API is fine. Someone has switched on Disable RESTful API in Gorilla Settings — switch it back off to restore access. |
| 503 | anything | The API is unhealthy. Wait and retry — this is not something you can fix. |
| no answer | no answer | A network or DNS problem between you and api.gorilladash.com. |
