Reference · built on requestConnectorMessaging & notifications

Postmark

Transactional email, bounces, message streams, inbound mail, and delivery webhooks through the Postmark API.

Request accessPricing ↗

About

Postmark is a transactional email service from ActiveCampaign. Its API at api.postmarkapp.com is organised around Servers, and each Server holds up to 10 Message Streams of type Transactional, Broadcasts, or Inbound, with outbound and inbound present by default. A Server API token sends mail and reads its bounces and message history; an Account API token manages account-level resources. Webhooks report Delivery, Bounce, Spam complaint, Open, Click, Subscription change, and Inbound.

Through Fibric, an operator reads inbound mail and bounce records for a stream, then proposes a send, a batch, or a suppression change for a person to approve.

This is a reference listing. It documents what Fibric would read from Postmark and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Bounces through GET /bounces with type, tag, messageID, fromdate, todate, and messagestream filters, and the raw source through GET /bounces/{bounceid}/dump
  • Sent-message history through GET /messages/outbound, searchable by recipient, tag, status, subject, and metadata, with GET /messages/outbound/{messageid}/details
  • Inbound mail posted by the Inbound webhook as JSON: FromFull, ToFull, Subject, MessageID, TextBody, StrippedTextReply, Headers, and base64 Attachments
  • Open and click events through GET /messages/outbound/opens and GET /messages/outbound/clicks
  • Suppressed addresses per stream through GET /message-streams/{stream_id}/suppressions/dump, with reason and origin
  • Delivery statistics through GET /deliverystats

Proposed actions

  • Target capability: propose a single message through POST /email with Tag, Metadata, and MessageStream set
  • Target capability: propose a batch of up to 500 messages through POST /email/batch
  • Target capability: propose reactivating a bounced address with PUT /bounces/{bounceid}/activate
  • Target capability: propose adding or removing a ManualSuppression through POST /message-streams/{stream_id}/suppressions and /suppressions/delete
  • Target capability: propose reprocessing a blocked inbound message with PUT /messages/inbound/{messageid}/retry

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • First reply on a shared inbox

    Each Inbound webhook post becomes a case with StrippedTextReply as the customer's words. The operator drafts a reply and proposes it through POST /email on the transactional stream.

    With First Response

  • Survey sent at the right moment

    After a Delivery event on the order confirmation, the operator waits the interval you set and proposes the survey message with a Tag for the campaign. A person approves the batch each morning.

    With Survey Timing

  • Payment retry notice that respects suppressions

    Before a retry notice goes out, the address is checked against the stream's suppression dump. A HardBounce origin stops the send; the operator proposes reactivation only when a person confirms the address.

    With Payment Retry

Requirements

  • A Postmark account with a Server and a Server API token
  • A Sender Signature or Domain covering the From address
  • An HTTPS endpoint Fibric operates for the Bounce, Delivery, and Inbound webhooks, configured in the app or through the Webhooks API
  • For inbound mail: the Server's inbound address or an inbound forwarding domain with its MX record pointed at Postmark
Authentication
A Server API token in the X-Postmark-Server-Token header for sending and reading a Server, and an Account API token in X-Postmark-Account-Token for account-level requests.

Limits

  • At most 50 recipients per message across To, Cc, and Bcc; a batch takes 500 messages and 50 MB, returning 200 even if some fail
  • Message data expires after the retention period, 45 days by default; a search returns at most 500 per page and 10,000 in total
  • Postmark does not sign webhooks with an HMAC; protection is HTTPS, Basic auth in the URL, and its published IP range
  • SpamComplaint suppressions cannot be removed through the API

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Postmark ↗

Questions and answers

Does Postmark sign its webhooks?
No. Postmark states it does not currently support HMAC signature verification. It recommends HTTPS, Basic authentication embedded in the webhook URL, and restricting your firewall to its IP range. Failed posts are retried after 1, 5, 10, 10, 10, and 15 minutes for 5xx, 408, 429, and network errors; other 4xx responses are not retried.
How long can sent messages be searched?
Messages expire after the retention period, which is 45 days by default. GET /messages/outbound returns up to 500 per request, and count plus offset cannot exceed 10,000. Filters include recipient, fromemail, tag, status, subject, messagestream, and metadata fields.
What is a Message Stream?
A stream separates mail within one Server. Types are Transactional, Broadcasts, and Inbound. A Server starts with outbound and inbound, may hold up to 10 streams, and can have only one Inbound stream. Default streams cannot be deleted; an archived stream can be restored for 45 days.
Ask about Postmark

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with Postmark through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy