Skip to content
WeZend
Referanse

API-referanse

Hvert endepunkt en API-nøkkel kan kalle, generert fra plattformens egne rutedefinisjoner.

92 endepunkter fordelt på 13 områder. Listen er generert fra plattformens rutedefinisjoner, så den kan ikke beskrive et endepunkt som ikke finnes — men den er et snapshot, tatt 2026-09-04, ikke et live-bilde. Endepunkter som bare virker med dashbord-sesjon er bevisst utelatt: en API-nøkkel svarer 401 på dem, og guidene sier hvilke områder det er.

Base-URL: https://api.wezend.com

API key betyr at X-API-Key er nok. API key or login betyr at samme endepunkt også tar en dashbord-sesjon, som er det produktets eget UI bruker.

/v1/events

MetodeStiAuthHva den gjør
POST/v1/eventsAPI keysingle event OR { events: [...] } / a bare array for batch.

/v1/mcp

MetodeStiAuthHva den gjør
POST/v1/mcpAPI keyMCP endpoint (streamable-HTTP style: single JSON-RPC request → single JSON response).
POST/v1/mcp/actAPI keyPlain REST for a ChatGPT GPT Action: { tool, arguments }.

/v1/webhook-endpoints

MetodeStiAuthHva den gjør
GET/v1/webhook-endpointsAPI key or loginlist + the catalogue of subscribable events
POST/v1/webhook-endpointsAPI key or login{ url, events? } — creates + returns the signing secret ONCE
DELETE/v1/webhook-endpoints/:idAPI key or login
PATCH/v1/webhook-endpoints/:idAPI key or login{ url?, events?, status? }
POST/v1/webhook-endpoints/:id/testAPI key or logindeliver a ping

Account

MetodeStiAuthHva den gjør
POST/v1/account/ai-assistAPI key or loginper-block text assist for the email builder (F2). action ∈ rewrite|shorten|lengthen|friendly|professional|fix|generate|subjects. Always responds (degrades gracefully without an AI key), so the ✨ menu never dead-ends.
POST/v1/account/ai-coach-requestAPI key or logincustomer asks to enable the paid add-on
GET/v1/account/ai-coach-statusAPI key or loginis the coach enabled / requested?
POST/v1/account/ai-recommendationsAPI key or loginpersonalised marketing advice (cached daily) Paid add-on: only available to customers with ai_coach_enabled.
POST/v1/account/ai-writeAPI key or logingenerate a full email from a brief
POST/v1/account/ai-writer-requestAPI key or login
GET/v1/account/ai-writer-statusAPI key or login
GET/v1/account/analyticsAPI key or login
GET/v1/account/balanceAPI key or login
GET/v1/account/billing-currencyAPI key or logincurrent currency + available options
PUT/v1/account/billing-currencyAPI key or login
PUT/v1/account/billing-detailsAPI key or logincustomer chooses their invoice/billing currency. Converts any existing balance to the new currency at the effective rate. PUT /v1/account/billing-details — company/tax details used on invoices
GET/v1/account/brand-voiceAPI key or logincurrent profile
PUT/v1/account/brand-voiceAPI key or loginset (or clear with null/{})
GET/v1/account/channel-deliverabilityAPI key or logindelivery/failure rates for EVERY channel (sms/rcs/whatsapp/voice/email + push), not just email reputation.
GET/v1/account/deliverabilityAPI key or loginbounce/complaint rates + health from the email feedback loop (the deliverability signals the platform already captures).
GET/v1/account/email-domainsAPI key or loginlist domains + their DNS records
POST/v1/account/email-domainsAPI key or loginadd a domain to verify
DELETE/v1/account/email-domains/:idAPI key or login
PUT/v1/account/email-domains/:id/bimiAPI key or login{ logo_url } — set/clear the BIMI SVG logo.
POST/v1/account/email-domains/:id/check-signingAPI key or loginthe ONLY honest DKIM confirmation. /verify above resolves DNS. It cannot see whether the outbound relay actually signs, and presenting those two as one green tick is exactly what let an account show "DKIM verified" while its delivered mail carried no DKIM-Signature header at all. The definitive test is the one a customer spelled out for us: send a mail to an address you can read, open "show original", and look for a DKIM-Signature with d=<your domain>. This endpoint takes those pasted headers and answers it — no guessing, no DNS inference — and records the verdict against the domain so the dashboard stops claiming more than it knows. Body: { headers: "<raw header blob or JSON map>", authentication_results?: "<optional>" }
GET/v1/account/email-domains/:id/dmarcAPI key or loginrecent reports + rollup for a domain
POST/v1/account/email-domains/:id/dmarcAPI key or loginUpload a DMARC aggregate (rua) XML report — parsed to a pass/fail-alignment summary so the customer sees spoofing / auth failures on their sending domain. POST /v1/account/email-domains/:id/dmarc { xml }
GET/v1/account/email-domains/:id/dmarc/readinessAPI key or logincan THIS domain move to p=quarantine? The same four criteria the platform holds itself to, asked for one customer's domain. Answers the decision rather than the data: a table of source IPs is not what tells someone whether it is safe to ask receivers to quarantine their own mail. It also hands back the two records to publish. The second one — RFC 7489 §7.1's external destination authorisation — is the step people miss, and missing it means Google and Microsoft refuse to send anything at all, silently. It is returned next to the first, not in a footnote.
POST/v1/account/email-domains/:id/verifyAPI key or loginrun live DNS checks
POST/v1/account/email-domains/:id/warmupAPI key or login{ action: start|pause|resume|stop } While active, marketing email beyond the day's cap is held (21-day ramp, no cron).
GET/v1/account/link-domainsAPI key or loginlist with the CNAME record + the target host
POST/v1/account/link-domainsAPI key or login{ domain }
DELETE/v1/account/link-domains/:idAPI key or login
POST/v1/account/link-domains/:id/verifyAPI key or loginlive DNS (CNAME) check
GET/v1/account/list-growthAPI key or loginsubscriber growth over time
GET/v1/account/meAPI key or loginworks with both X-API-Key and Bearer JWT
GET/v1/account/planAPI key or logincurrent tier/band, included volumes (annual-adjusted), this month's usage, region mode and the self-serve upgrade options.
GET/v1/account/pricingAPI key or loginReturns ONLY sell prices — never cost prices
POST/v1/account/spam-checkAPI key or login{ subject, html, text } → { score, rating, issues }
GET/v1/account/tracking-identityAPI key or loginthe secret your BACKEND signs contact identifiers with, so the browser SDK can prove a visitor is a particular contact. Needs the settings capability.
PUT/v1/account/tracking-identityAPI key or login{ require_identity: boolean }. Turning it off lets anyone holding the public tracking key name any contact, so the response says so.
POST/v1/account/tracking-identity/rotateAPI key or loginissue a new identity secret, invalidating every user_hash already computed with the old one.
GET/v1/account/tracking-keyAPI key or loginthe customer's public, write-only tracking key plus the ready-to-paste <script> snippet for the browser SDK. Created on first request.
PUT/v1/account/tracking-originsAPI key or loginrestrict which website origins may use the key (e.g. ["https://shop.example.com"]). Empty list = accept any origin.
GET/v1/account/usageAPI key or login

Account — Unsubscribes

MetodeStiAuthHva den gjør
GET/v1/account/unsubscribes/api/listAPI key or logina customer's own suppressions. flexAuth, not requireAuth: this was JWT-only, so a customer's BACKEND could not read it — only a signed-in browser could. That left the contact.unsubscribed webhook as the single way to get opt-outs into their own consent records, with no way to reconcile if their endpoint was down. Reported by a customer on 2026-08-31, and they were right that it made the webhook a single point of failure for data they are obliged to keep. requireCapability("read") covers both callers: an API key must carry the read scope, a dashboard user must have a role that allows reads. It is the customer's own suppression list either way.

Contacts

MetodeStiAuthHva den gjør
GET/v1/contactsAPI key or loginlist contacts
POST/v1/contactsAPI key or logincreate a single contact manually (e.g. to send a test)
DELETE/v1/contacts/:idAPI key or login
PATCH/v1/contacts/:idAPI key or loginPATCH /v1/contacts/:id — update a contact (standard fields + custom fields)
GET/v1/contacts/fieldsAPI key or loginlist this customer's custom field definitions
POST/v1/contacts/fieldsAPI key or logindefine a new custom field
DELETE/v1/contacts/fields/:idAPI key or loginremove a field definition (existing data on contacts is kept)
POST/v1/contacts/importAPI key or loginupload CSV

Conversations

MetodeStiAuthHva den gjør
GET/v1/conversationsAPI key or login
PATCH/v1/conversations/:idAPI key or login
GET/v1/conversations/:id/messagesAPI key or login
POST/v1/conversations/:id/replyAPI key or login

Integrations

MetodeStiAuthHva den gjør
POST/v1/integrationsAPI key or logincreate integration (accepts JWT or API key) Uses flexAuth middleware that tries API key first, then JWT

Lists

MetodeStiAuthHva den gjør
GET/v1/listsAPI key or login
POST/v1/listsAPI key or login
DELETE/v1/lists/:idAPI key or login
GET/v1/lists/:idAPI key or login
PATCH/v1/lists/:idAPI key or login
POST/v1/lists/:id/contactsAPI key or loginadd a single contact to list
DELETE/v1/lists/:id/contacts/:contactIdAPI key or login
PATCH/v1/lists/:id/favoriteAPI key or loginpin/unpin a list to the top
POST/v1/lists/:id/importAPI key or loginimport CSV into this list

Messages

MetodeStiAuthHva den gjør
DELETE/v1/messages/:idAPI key or loginA send with scheduled_at in the future is stored as status='scheduled' (see processOutboundMessage) — but this endpoint only accepted 'queued', so the one thing it exists for, cancelling a scheduled message, answered "Message already sent — cannot cancel". Both pre-dispatch states are cancellable now, claimed atomically so a message the scheduled worker or queue worker has already picked up can't be cancelled from under it.
GET/v1/messages/:idAPI key or loginflexAuth, not requireApiKey: the dashboard is a first-class client of its own API, and an API-key-only status/cancel pair meant a signed-in user could see a scheduled message in the history but had no way to look it up or stop it. Matches /history and /:id/timeline.
POST/v1/messages/:id/resendAPI key or loginCreates a NEW message to the same recipient with the same content.
GET/v1/messages/:id/timelineAPI key or login
POST/v1/messages/bulkAPI key or loginSend up to 10,000 messages in one call. Each item accepts the same per-send options as /send (transactional, reply_to, from_name, headers); an item with an invalid value is counted failed.
GET/v1/messages/historyAPI key or loginMust be defined BEFORE GET /:id so "history" isn't captured as an :id.
POST/v1/messages/sendAPI key or loginSend one message. Body: to, channel, message. `message` (plain text) is ALWAYS required — even for email, where it is the text/plain alternative; add `htmlmessage` (+ `subject`) for the HTML body. A body with only `htmlmessage` and no `message` is rejected with 400. Optional: transactional (bool — exempt from the marketing quota cap), reply_to, from_name and headers (email; headers are safelisted — reserved names are rejected with 400).
POST/v1/messages/send-by-tagAPI key

Segments

MetodeStiAuthHva den gjør
GET/v1/segmentsAPI key or loginlist all segments (with a live contact count each)
POST/v1/segmentsAPI key or logincreate
DELETE/v1/segments/:idAPI key or login
PUT/v1/segments/:idAPI key or loginupdate
GET/v1/segments/:id/contactsAPI key or loginresolve to actual contacts (preview the members)
POST/v1/segments/previewAPI key or logincount matches for a rule set WITHOUT saving (live preview)
GET/v1/segments/schemaAPI key or loginthe fields + operators the builder can offer

Sender

MetodeStiAuthHva den gjør
GET/v1/sender/rulesAPI key
POST/v1/sender/validateAPI key

Senders

MetodeStiAuthHva den gjør
GET/v1/sendersAPI key or login
POST/v1/sendersAPI key or login
DELETE/v1/senders/:idAPI key or login

Én plattform. Hver kundeinteraksjon.

Erstatt lappeteppet av meldings-API-er, CDP og automatiseringsverktøy med én engasjementsplattform bygget for skala.

Start gratisBook en demo

Ingen kredittkort · EU-datalagring · 99,99 % oppetids-SLA