How API responses are shaped, and what the errors mean

Every endpoint in the Gorilla Dash API answers in the same shape. Learn it once and the rest of the API is predictable.

Success is always 201

This is the one thing that catches everybody. A successful call answers HTTP 201 — reading a list, reading one record, creating something, updating something. Not 200.

DO NOT TEST FOR 200

Code that checks status === 200 will treat every successful Gorilla Dash call as a failure. Check for a 2xx range, or check for 201 specifically. This is by far the most common integration bug we see.

The envelope

The body of a successful call always wraps the real content in an envelope: {"success":true,"status":201,"data":...}. Your records are under data — an object for a single record, an array for a list.

Key	What it holds
`success`	`true` on a successful call.
`status`	The HTTP status, repeated in the body.
`data`	The record, or the array of records. This is what you want.
`pagination`	Present on list endpoints. See below.

Paging through a list

List endpoints take page (starting at 1) and results_per_page. Contacts, leads, enquiry forms and media cap it at 1000, and blog articles, knowledge articles, food menu items and digest posts cap it at 100 — ask for more than the cap on any of those and the call is refused with a validation error rather than quietly trimmed. Two do not follow that rule: the tribe list clamps silently at 1000 rather than refusing, because WordPress integrations deliberately send 99999 to pull every tribe, and reviews have no cap at all.

The pagination block tells you where you are: total records overall, count on this page, perPage, currentPage and totalPages. Loop until currentPage reaches totalPages.

WHY ORDER MATTERS

The people and enquiries endpoints deliberately return oldest id first. It looks less friendly than newest-first, but it is the only ordering where paging through a changing dataset cannot skip a record. Do not fight it.

What can go wrong

Code	What happened	What to do
401	The key and access token were missing, mismatched or wrong.	Check both headers are present and copied whole. Check nobody has regenerated the token.
403	You are authenticated but not allowed.	Either the API is switched off for your organisation, or a tribe key asked for a different tribe.
404	Something named in the request does not exist.	On `POST /enquiries` this usually means the form slug is wrong, or the organisation has no default website. Elsewhere, a bad id or slug.
422	The payload failed validation.	The body lists each field and what was wrong with it. Fix and resend.
429	You are going too fast.	Back off and retry. See the rate limits guide.
500	Something failed on our side.	Retry with a short delay. If it persists, contact support with the time and the endpoint.

Reading a validation error

A 422 names every field that failed, so you rarely have to guess. The usual causes are a missing required field, a value of the wrong type — a number where a string was expected inside fields — or a page size above the cap.

When a call succeeds but nothing appears

You sent an identical lead twice. Gorilla Dash recognised the repeat and returned the original — see the guide on pushing an enquiry.
You are using a tribe key and the record belongs to a different tribe.
You are reading a cached endpoint and the change is newer than the cache window. See the caching guide.
You filtered on updated_after with a timestamp that has no time zone on it. Always send a full ISO 8601 timestamp with an offset.