Developers · API reference

One API,
one shape.

One shape for every resource: list, get, create, update, delete — with idempotent commands for state changes and structured errors you can branch on.

Every resource is tenant-scoped. There is no global namespace.
Quick start

List contacts for a brand.

Every collection follows this pattern. Swap the resource name and the shape stays identical.

curl https://api.sendnectar.com/api/v1/tenants/$TENANT_ID/contacts?brand_id=$BRAND_ID&status=active \
  -H "Authorization: Bearer $SENDNECTAR_API_KEY" \
  -H "Accept: application/json"

Send a transactional message

curl -X POST https://api.sendnectar.com/api/v1/tenants/$TENANT_ID/transactional \
  -H "Authorization: Bearer $SENDNECTAR_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: order_confirm_10432" \
  -d '{
    "brand_id": "…",
    "template_version_id": "…",
    "to_email": "[email protected]",
    "external_reference": "order_10432",
    "variables": { "order_total": "48.00" },
    "metadata": { "store": "eu" }
  }'
Conventions

The same six rules, everywhere.

Learn the pattern once and every resource in the catalog behaves the way you expect.

Base path
/api/v1/tenants/{tenant_id}
Collection
GET, POST on /{resource}
Item
GET, PATCH, DELETE on /{resource}/{id} — DELETE returns 204
Commands
POST to a named sub-path, e.g. /campaigns/{id}/schedule
List filters
brand_id, status, q, plus pagination parameters
Idempotency
Send an idempotency-key header on state-changing commands
Errors

Structured, with a request ID.

Failures return a machine-readable code alongside a human message, optional details, and a request ID to quote when you contact us.

{
  "error": {
    "code": "validation.failed",
    "message": "A date and time is required.",
    "details": { "path": ["scheduled_at"] },
    "request_id": "req_01J…"
  }
}
Authentication

Scoped keys, shown once.

Keys are tenant-scoped and carry their own permissions. Machine access follows the same least-privilege principle as human access.

Header
Authorization: Bearer <api key>
Modes
live or test — set per key, never mixed
Scopes
One to fifty explicit scopes per key, required at creation
Brand restriction
Optionally limit a key to specific brand IDs
Expiry
Optional expiry timestamp per key
Token visibility
Shown exactly once at creation — store it immediately
The boundary

What the API deliberately cannot reach.

The API addresses an explicit allow-list of resources and fields. Secret and credential tables are not merely permission-gated — they are unreachable by construction.

Provider passwords, integration tokens, and webhook secrets are written only through dedicated credential endpoints, encrypted server-side, and never returned by any read path.

Resources

The catalog.

Every entry below is a tenant-scoped collection under the base path. Read-only resources expose list and get only.

Audience

  • contacts
  • contact-emails
  • contact-phones
  • contact-fields
  • lists
  • segments
  • tags
  • subscription-topics
  • subscriptions
  • suppressions

Capture

  • forms
  • landing-pages
  • preference-centers
  • form-submissions

Content

  • templates
  • content-blocks
  • rss-feeds

Messaging

  • campaigns
  • campaign-recipients
  • frequency-caps
  • workflows
  • workflow-enrollments
  • workflow-step-runs

Configuration

  • brands
  • websites
  • domains
  • legal-entities
  • postal-addresses
  • provider-connections
  • sender-profiles
  • sending-routes
  • retention-policies
  • legal-holds

Platform

  • integrations
  • integration-sync-runs
  • outbound-webhooks
  • webhook-deliveries
  • commerce-stores
  • commerce-products
  • commerce-orders

Reporting

  • messages
  • message-events
  • conversions
  • domain-reputation
  • sender-reputation
  • provider-reputation
  • website-sessions

Operations

  • import-jobs
  • export-jobs
  • transactional-history
  • background-jobs
  • system-incidents
  • privacy-requests
  • risk-events
  • notifications

Administration

  • members
  • invitations
  • roles
  • api-keys

Create a test key.
Build the integration.
Pay nothing yet.

Sandbox includes test-mode API keys, so the whole integration can be built and verified before you send a single production message.