Test Triggers#

A test trigger is a regular trigger with a special responsibility. The test trigger is the trigger Zapier will use to verify the authentication credentials users provide when they first attempt to access your API through Zapier. If your API returns a 2XX status code, we will assume the credentials are valid. Anything else (or an empty response that isn't a 204), and we will assume the credentials are bad.

You can only mark one trigger as the test trigger. A test trigger can be made for any endpoint in your API that:

  1. Requires authentication
  2. Is guaranteed to always return some data (or a 204 for empty responses)

Some examples of good endpoints to use for the test trigger:

  • A url like /ping that is meant solely to test authentication
  • An endpoint that returns a user's profile
  • An endpoint for high-level objects in your API that users are virtually guaranteed to have (i.e. contacts if you are a CRM, tickets if you are a support center)

Setting one up#

In your app, you'll need choose a trigger that performs a "simple test" when its Polling URL is used to access an endpoint that requires valid authorization/credentials.

If your trigger is intended to be solely used for authentication testing, then you can mark it hidden.

Important make sure that the test trigger doesn't have any "Required" trigger fields (because they'll be empty when we perform the auth test)


When your test trigger fails, a message will be displayed to the user "App returned (400) Error and said nothing" or something similar. This is constructed from the response status code and status message returned from your endpoint, along with a message from the response body, like so:

App returned (response.status_code) response.status_message and said response.body.message

The message is interpreted from the response.body as such:

  1. We check to see if you send back JSON. If so, we look for a message field, or similar in the JSON object.
  2. We check to see if you send back an XML file (i.e., xml in the Content-Type header). If so, we do a similar lookup for an error message in the body.
  3. We then check to see if you sent back a plain text response(i.e., Content-Type: text/plain). If so, we check that the content is < than 180 characters and use it verbatim.

Alternatively, you can compose a custom error message by raising an ErrorException in your Scripting. More information in the Available Exceptions section of our docs.


To select your test trigger, use the button "Manage Trigger Settings":

Scroll down to the bottom of the page, and select the appropriate trigger:

↑ Was this documentation useful? Yes No
Get Help