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.
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" }
}'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
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…"
}
}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
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.
The catalog.
Every entry below is a tenant-scoped collection under the base path. Read-only resources expose list and get only.
Audience
contactscontact-emailscontact-phonescontact-fieldslistssegmentstagssubscription-topicssubscriptionssuppressions
Capture
formslanding-pagespreference-centersform-submissions
Content
templatescontent-blocksrss-feeds
Messaging
campaignscampaign-recipientsfrequency-capsworkflowsworkflow-enrollmentsworkflow-step-runs
Configuration
brandswebsitesdomainslegal-entitiespostal-addressesprovider-connectionssender-profilessending-routesretention-policieslegal-holds
Platform
integrationsintegration-sync-runsoutbound-webhookswebhook-deliveriescommerce-storescommerce-productscommerce-orders
Reporting
messagesmessage-eventsconversionsdomain-reputationsender-reputationprovider-reputationwebsite-sessions
Operations
import-jobsexport-jobstransactional-historybackground-jobssystem-incidentsprivacy-requestsrisk-eventsnotifications
Administration
membersinvitationsrolesapi-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.