Sign in
Start free7-day free trial
Live API contract
Start here

Make your first API request

Connect a server to the Waiver.com API, verify authentication and choose the next workflow to implement.

Start with one read request. You will verify the hostname, your organization's API key and its permissions before creating records or sending invitations. Use a server-side terminal or application; never put a secret key into a public website, mobile bundle or browser request.

Create a narrowly scoped key

In the app, open Settings, then API keys, and create a key with templates:read. Give it a name that identifies the integration and environment. Copy the secret when it is shown and save it in your server's secret storage. The full value is shown once.

A key belongs to the organization that created it. You do not select an organization by adding an ID to the request. If a record belongs elsewhere, changing its ID will not grant access.

List your templates

curl 'https://api.waiver.com/v1/templates'   --header 'Authorization: Bearer YOUR_API_KEY'

Replace the placeholder with your key in your local environment. Avoid saving a real credential in shell history or source control. A successful response lists the organization's non-archived templates. An empty list is a valid result; it does not mean authentication failed.

The list templates reference describes the response. A template's activeVersion can be null when it has never been published. Do not offer a draft-only template as a public signing destination.

Diagnose the first response

A 401 usually means the credential is missing or invalid. A 403 means authentication succeeded but the operation needs a scope the key does not have. Save the response's x-request-id when you need help tracing a failure. Do not include the key in a support message.

Use the error guide for status-specific recovery. A request to the public health endpoint can help separate connectivity from authentication, but it cannot verify your key or access to a particular organization.

Choose a workflow

For a booking system, start with prefill links and let guests sign on the hosted page. For records synchronization, subscribe to webhooks, then retrieve the records you need. For a custom signing experience, read submission and validation before implementing the form.

Keep a small acceptance checklist: correct organization, expected template, least-privilege key, a saved request ID on failures and no credentials in browser traffic. Confirm those basics before adding write operations.