The Zendesk API in Postman

When an integration misbehaves, you're debugging two things at once: your code and your understanding of the API. Postman removes one of them.

It also gives you something to hand over. A collection with working requests, documented variables and a couple of tests is worth more to the next developer than a page of notes, and it survives the rewrite when your integration moves from a script to a service.

Two other reasons. You can see the exact shape of a response before you model it, which stops the classic mistake of assuming a field is a string when it is an array. And you can safely test destructive calls against a sandbox by flipping one variable.

Zendesk API token auth is HTTP basic auth with a twist: the username is your email address with /token appended, and the password is the token itself.

Set it once at the collection level, on the Authorization tab, and let every request inherit it. Doing it per request is how you end up with three requests that work and one that mysteriously 401s.

Username field:

{{email}}/token

Password field:

{{api_token}}

If you prefer to see what is actually going over the wire, the equivalent header is a base64 encoding of that same pair.

Authorization: Basic base64(email/token:api_token)

For anything a customer installs, you want OAuth rather than a token. Postman handles OAuth 2.0 natively, and Zendesk exposes the standard authorize and token endpoints under your subdomain. Check the current API reference for the exact paths and scope names.

A collection without tests is a bookmark folder. Two small scripts change that.

In the Tests tab of the create request, capture the new ID so the next request can use it.

pm.test('created', () => pm.response.to.have.status(201));
const body = pm.response.json();
pm.environment.set('ticket_id', body.ticket.id);

In the list request, capture the cursor so you can page through by hitting Send again.

const body = pm.response.json();
pm.environment.set('next_page', body.links && body.links.next ? body.links.next : '');
pm.test('has results', () => pm.expect(body.tickets.length).to.be.above(0));

Zendesk uses cursor pagination on modern list endpoints, which means you follow the link the API gives you rather than incrementing a page number. Prove that in Postman and your production loop will be right first time.

One more test worth adding everywhere, because it catches the failure people design for last:

pm.test('not rate limited', () => pm.expect(pm.response.code).to.not.eql(429));

Rate limits are per account and vary by plan, so check the current API reference for your numbers. A 429 returns a Retry-After header and honouring it's not optional.