The Zendesk Sell API Base URL and Beyond

People arrive at the Zendesk Sell API base URL having read the Support docs and finding that nothing works. That's correct behaviour: Sell is a different product.

Start free trial All guides

Two products, two APIs

Zendesk Support and Zendesk Sell share a company and, in most accounts, very little else at the API level. Sell arrived through the acquisition of Base CRM and it kept its own platform, which is why the developer experience feels like a different vendor. Because it is.

That means a separate base URL, separate credentials, a separate rate limit budget, separate pagination conventions and a separate response envelope. Nothing you learned in the Zendesk API guide transfers cleanly, beyond the general shape of REST.

The practical rule: if the object is a ticket, a user, an organisation or a help centre article, you want the Support API. If it is a lead, a contact, a deal, a pipeline stage or a sales task, you want Sell.

The Zendesk Sell API base URL, and why it looks wrong

The Support API is built from your own subdomain, so every account has a different host:

https://acme.zendesk.com/api/v2/tickets.json

Sell doesn't work that way. It's a shared, versioned host that carries no trace of your subdomain, and at time of writing the documented base is the legacy Base CRM domain:

https://api.getbase.com/v2/

That surprises people, and it should, because the hostname doesn't say Zendesk anywhere. Zendesk has been consolidating domains across its products for years, so confirm the current base against the Sell developer reference before you hard-code it. Put it in configuration, not in a constant halfway down a file.

There's also more than one Sell API surface. The core CRM API is what most integrations want. Separate surfaces exist for bulk data synchronisation and for search, and they have their own semantics. Read which one your use case belongs to before you start paginating the wrong thing.

Authentication isn't the same either

Support accepts basic auth with an email plus API token, which is why so much sample code looks like this:

curl -u "you@acme.com/token:$ZD_TOKEN" \
     https://acme.zendesk.com/api/v2/users.json

Sell uses OAuth 2 bearer tokens. You generate an access token from the Sell settings for a personal integration, or you register an OAuth application when a customer has to grant access. Either way it goes in a header, not in basic auth:

curl -H "Authorization: Bearer $SELL_TOKEN" \
     -H "Accept: application/json" \
     https://api.getbase.com/v2/contacts

A Support API token pasted into a Sell request returns an authentication error that looks like a permissions problem, and people lose an hour to it. If you're getting 401s with credentials you're sure about, check which product the credentials belong to first.

The response envelope catches everyone

Support returns a named array at the top level, so a list of users comes back under a users key and you iterate it directly. Sell wraps things. A collection response carries an items array, and each entry inside it has its own data object holding the record plus a small meta object describing its type. So the record you want is one level deeper than instinct suggests.

Practically, that means your parsing code can't be shared between the two APIs, and a generic client that works for Support will silently return objects full of metadata when pointed at Sell. Write the mapping once, in one place, and test it against a real payload rather than against the documentation snippet.

Pagination differs too, and sort parameters are spelled differently. None of it's hard. All of it is different, which is worse, because it fails quietly.

Before you build anything

Ask whether you need the API at all. Zendesk ships a native link between the two products, and for the common case of wanting sales context beside a ticket, the Sell and Support integration does it without code.

If you do need code, three things save time later. Use a dedicated integration user so permissions and audit trails belong to nobody in particular. Honour the rate limit headers rather than guessing, because Sell has its own budget entirely separate from Support. And log the full response body on failure, since the error messages are more useful than the status codes. Treat the two products as separate integrations in your own code, with separate clients and separate configuration, because sharing one HTTP wrapper between them saves nothing and hides bugs for months.

For background on what Sell is and whether it belongs in your stack at all, the Zendesk Sell overview covers the product side.

FAQ

Frequently asked questions

How does authentication differ on the Sell API?

Zendesk Sell API authentication uses an OAuth bearer token from Sell itself, not a Support API token. That's the first thing that breaks when people assume the Zendesk Sell REST API behaves like Support.

What is the Zendesk Sell API base URL?

It is a shared host rather than your subdomain, and the documented base is the legacy Base CRM domain, https://api.getbase.com/v2/. Confirm against the current Sell reference before hard-coding it.

Can I use my Zendesk Support API token with Sell?

No. They are separate credential systems. Sell expects an OAuth 2 bearer token in an Authorization header, not basic auth with an email and token.

Why does my Sell response look empty?

It probably isn't. Sell wraps records in an items array where each entry has its own data object, so the fields sit a level deeper than in a Support response.

Do Sell and Support share a rate limit?

No. They are separate platforms with separate budgets. Read the rate limit headers on the responses you actually get rather than assuming a number.

Do I need the API to link Sell and Support?

Usually not. There is a native integration for surfacing sales context alongside tickets, and it covers the common case without any code at all.