Skip to content
WeZend
Referenz

API-Referenz

Jeder Endpoint, den ein API-Key aufrufen kann — generiert aus den Routendefinitionen der Plattform selbst.

92 Endpoints in 13 Bereichen. Diese Liste wird aus den Routendefinitionen der Plattform generiert, kann also keinen Endpoint beschreiben, der nicht existiert — sie ist aber eine Momentaufnahme vom 2026-09-04, keine Live-Ansicht. Endpoints, die nur mit Dashboard-Session funktionieren, fehlen absichtlich: ein API-Key antwortet dort mit 401, und die Guides sagen, welche Bereiche das sind.

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

API key heißt, dass X-API-Key genügt. API key or login heißt, dass derselbe Endpoint auch eine Dashboard-Session akzeptiert — die nutzt die eigene UI des Produkts.

/v1/events

MethodePfadAuthWas er tut
POST/v1/eventsAPI keysingle event OR { events: [...] } / a bare array for batch.

/v1/mcp

MethodePfadAuthWas er tut
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

MethodePfadAuthWas er tut
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

MethodePfadAuthWas er tut
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

MethodePfadAuthWas er tut
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

MethodePfadAuthWas er tut
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

MethodePfadAuthWas er tut
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

MethodePfadAuthWas er tut
POST/v1/integrationsAPI key or logincreate integration (accepts JWT or API key) Uses flexAuth middleware that tries API key first, then JWT

Lists

MethodePfadAuthWas er tut
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

MethodePfadAuthWas er tut
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

MethodePfadAuthWas er tut
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

MethodePfadAuthWas er tut
GET/v1/sender/rulesAPI key
POST/v1/sender/validateAPI key

Senders

MethodePfadAuthWas er tut
GET/v1/sendersAPI key or login
POST/v1/sendersAPI key or login
DELETE/v1/senders/:idAPI key or login

Eine Plattform. Jede Kundeninteraktion.

Ersetzen Sie Ihren Flickenteppich aus Messaging-APIs, CDP und Automatisierungstools durch eine Engagement-Plattform, die für Skalierung gebaut ist.

Kostenlos startenDemo buchen

Keine Kreditkarte · EU-Datenhaltung · 99,99 % Uptime-SLA