> ## Documentation Index > Fetch the complete documentation index at: https://docs.nautilus.co/llms.txt > Use this file to discover all available pages before exploring further. # Introduction > Nautilus external API reference ## Overview The Nautilus API allows authorized external systems to interact with the Nautilus platform programmatically. The canonical API is read-only and tenant-scoped. It exposes your organization's sites, products, checkout links, purchases, contacts, marketing signups, forms, vouchers, links, automations, surveys, cases, and cancellation records, plus Sonny's POS data for supported organizations. Its machine-readable contract is available without authentication: ``` GET https://app.nautilus.co/api/v1/openapi.json ``` ## Base URL ``` https://app.nautilus.co/api ``` ## Authentication All data endpoints require a Bearer token passed in the `Authorization` header. ```bash theme={null} curl "https://app.nautilus.co/api/v1/products" \ -H "Authorization: Bearer YOUR_API_KEY" ``` Requests with a missing or invalid token receive a `401 Unauthorized` response. The `Bearer ` prefix is required and case-sensitive. ### Key types Nautilus issues two kinds of API keys: * **Tenant-scoped keys** — bound to a specific organization. All canonical data endpoints require a tenant-scoped key. Sends are attributed to that tenant and use the tenant's own sender identity (email from your slug-derived address on `@mail.nautilus.co`, SMS from your configured tenant phone number). * **Platform keys** — legacy Nautilus-issued keys that send as the Nautilus brand (SMS from the Nautilus shortcode, email from `contact@mail.nautilus.co`). Platform keys work only for the message and email send endpoints. Most integrations use tenant-scoped keys. Contact Nautilus to provision one for your organization. ### Tenant isolation The organization bound to your API key is the only tenant scope. Requests cannot supply or override an organization ID. Collection queries are always scoped to your organization, and detail endpoints return `404` for both missing and cross-tenant IDs so resource existence is never disclosed. Responses are built from narrow public serializers. They do not expose API credentials, provider configuration, access tokens, webhook secrets, raw provider payloads, or internal workflow data. Form, signup, and survey answer payloads also have sensitive internal keys removed recursively. ## Canonical resources All canonical endpoints use `GET` and share the [collection envelope and cursor pagination](/api-reference/pagination). | Resource | Collection | Detail or nested collection | | --------------------------------- | -------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- | | Sites | `/api/v1/sites` | `/api/v1/sites/{siteId}` | | Products | `/api/v1/products` | `/api/v1/products/{productId}` | | Checkout links | `/api/v1/checkout-links` | `/api/v1/checkout-links/{checkoutLinkId}` | | Purchases | `/api/v1/purchases` | `/api/v1/purchases/{purchaseId}` | | Contacts | `/api/v1/contacts` | `/api/v1/contacts/{contactId}` | | Contact lists | `/api/v1/contact-lists` | `/api/v1/contact-lists/{listId}`, `/api/v1/contact-lists/{listId}/contacts` | | Marketing signups | `/api/v1/marketing/signups` | — | | Forms | `/api/v1/forms`, `/api/v1/forms/submissions` | `/api/v1/forms/{formId}`, `/api/v1/forms/{formId}/submissions` | | Vouchers | `/api/v1/vouchers`, `/api/v1/vouchers/redemptions` | `/api/v1/vouchers/{voucherId}` | | Voucher groups | `/api/v1/voucher-groups` | `/api/v1/voucher-groups/{groupId}`, `/api/v1/voucher-groups/{groupId}/vouchers` | | Links | `/api/v1/links`, `/api/v1/links/analytics` | `/api/v1/links/{linkId}`, `/api/v1/links/{linkId}/analytics` | | Automations | `/api/v1/automations`, `/api/v1/automations/runs` | `/api/v1/automations/{automationId}`, `/api/v1/automations/{automationId}/runs`, `/api/v1/automations/runs/{runId}` | | Surveys | `/api/v1/surveys`, `/api/v1/surveys/responses` | `/api/v1/surveys/{surveyId}`, `/api/v1/surveys/{surveyId}/responses`, `/api/v1/surveys/{surveyId}/responses/{responseId}` | | Cases | `/api/v1/cases` | `/api/v1/cases/{caseId}` | | Cancellation records | `/api/v1/cancellations/records` | `/api/v1/cancellations/records/{membershipId}` | | Sonny's transactions | `/api/v1/pos/sonnys/transactions` | `/api/v1/pos/sonnys/transactions/{transactionId}` | | Sonny's customers | `/api/v1/pos/sonnys/customers` | `/api/v1/pos/sonnys/customers/{customerId}` | | Sonny's recurring accounts | `/api/v1/pos/sonnys/recurring-accounts` | `/api/v1/pos/sonnys/recurring-accounts/{accountId}` | | Sonny's recurring account details | `/api/v1/pos/sonnys/recurring-account-details` | `/api/v1/pos/sonnys/recurring-account-details/{accountId}` | The four `/api/v1/pos/sonnys/*` resources are provider-specific. They are available only when your organization has the supported Sonny's Shared data source; other organizations receive the route's documented `400` or `404`. Cancellation records include normalized signup discounts (`signupDiscounts`, `hadSignupDiscount`) and first-year billing coverage (`firstYearPayments`, `firstYearPaymentCoverage`) built from normalized billing events. ## Legacy endpoints The following endpoints predate the canonical API. They remain available and unchanged, and are marked deprecated in the OpenAPI document: * [Send SMS](/api-reference/endpoint/send-message) — `POST /v1/message` * [Send email](/api-reference/endpoint/send-email) — `POST /v1/email` * [Export members](/api-reference/endpoint/members) — `GET /v1/members` * [Signup cohorts](/api-reference/endpoint/cohorts) — `GET /v1/cohorts` * [Retention offers](/api-reference/endpoint/retention-offers) — `GET /v1/retention-offers` * [Cancellations](/api-reference/endpoint/cancellations) — `GET /v1/cancellations` * [Cancellation survey](/api-reference/endpoint/cancellation-survey) — `GET /v1/cancellation-survey` Analytics endpoints require tenant-scoped keys because they return organization-scoped data. ### Legacy date parameters Legacy analytics date filters are interpreted in UTC. For members, retention offers, cancellations, and cancellation survey, date-only lower bounds such as `2026-01-01` start at `2026-01-01T00:00:00.000Z`. Date-only upper bounds include the full day and end at `23:59:59.999Z`. Cohort `start` and `end` values are truncated to their month. Explicit timestamps are used as exact inclusive instants for the other analytics endpoints. Invalid date values are ignored unless an endpoint documents stricter validation. Canonical endpoints are stricter: timestamp filters such as `createdAfter` must include an explicit UTC offset, for example `2026-07-01T00:00:00Z`.