.png)
Postmark Integration Guide
Integrate Postmark with enterprise systems through REST APIs, batch email endpoints, SMTP, templates, inbound email, and event webhooks.
Postmark integration options at a glance
Postmark’s primary integration mechanism is its REST API for sending individual or template-based messages, submitting batches, managing Servers, Templates, Domains, Bounces, Suppressions, and retrieving message activity and statistics. Postmark also supports webhook-style notifications for selected delivery events, opens, clicks, bounces, spam complaints, subscription changes, and inbound email forwarding to an HTTP endpoint. SMTP remains available for applications that cannot use REST. Attachments can be included as Base64 content in message payloads, while reporting data can be retrieved through APIs rather than direct database access. Martini can authenticate requests, orchestrate workflows, map payloads, expose callback APIs, and persist delivery results.
| Integration point | Supported by Postmark? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Send individual and template-based messages, submit batches, manage Templates, Servers, Domains, Bounces, Suppressions, and query message activity or statistics. | Martini can consume Postmark REST endpoints from workflows, map business data into request payloads, expose internal email APIs, and persist responses. |
| Webhooks and inbound callbacks | Yes | Receive selected delivery, open, click, bounce, spam complaint, subscription-change, and inbound email notifications. | Martini can expose a protected API endpoint or receive the callback through a workflow trigger, validate the payload, route events, and update downstream systems. |
| Bulk and batch APIs | Yes | Send multiple individual or template-based messages in one request within Postmark’s documented batch and payload limits. | Martini can assemble and validate batches, call the batch endpoint, process individual response results where applicable, and handle retryable failures. |
| Templates | Yes | Render reusable Postmark email templates using recipient, sender, template identifier, and model data. | Martini can select a template, construct and validate its model, invoke the template send endpoint, and store the returned message identifier. |
| SMTP delivery | Yes | Submit email through SMTP when an existing application cannot make REST API requests. | Martini can orchestrate SMTP-based delivery where required, although REST is generally preferable for structured responses, templates, identifiers, and error handling. |
| File and attachment payloads | Limited | Include attachments in email payloads, generally as Base64 content with a filename and MIME type; Postmark does not provide a general-purpose attachment repository. | Martini can retrieve or receive file content, validate size and MIME rules, encode attachments, and include them in the email request. |
| Statistics and analytics APIs | Limited | Retrieve usage, delivery statistics, message activity, bounce data, and suppression information for reconciliation and reporting. | Martini can schedule API reads, paginate through results, apply a watermark, deduplicate message identifiers, and write results to a database or reporting system. |
| Authentication | Yes | Authenticate REST requests with server or account tokens, SMTP with configured SMTP credentials, and webhook endpoints with configured options such as HTTP Basic Authentication. | Martini can keep tokens and credentials in protected secrets or environment configuration and apply the appropriate authentication model per workflow. |
How Postmark exposes data and business events
Postmark REST APIs
Postmark’s REST APIs are the primary interface for sending messages, using Templates, submitting batches, managing Servers and Domains, querying Messages, and retrieving Bounces, Suppressions, usage, and statistics.
Martini implementation pattern
Martini implementation pattern: a workflow receives a business event or scheduled request, authenticates with a server or account token, constructs the Postmark request, transforms the response into a canonical result, and persists identifiers and status for reconciliation.
Implementation sequence
Postmark webhooks and inbound email
Postmark supports webhook-style notifications for selected delivery, open, click, bounce, spam complaint, and subscription-change events. It can also forward inbound email messages to an HTTP endpoint.
Martini implementation pattern
Martini implementation pattern: Martini exposes a protected API endpoint or workflow trigger, authenticates and validates the callback, normalizes the event, and routes it to customer, support, order, or monitoring systems. Webhook coverage is limited to the event types Postmark exposes.
Implementation sequence
Postmark batch email API
Postmark provides batch endpoints for sending multiple individual or template-based messages in one request. These are request/response operations rather than a general-purpose asynchronous job queue.
Martini implementation pattern
Martini implementation pattern: a workflow groups eligible messages, enforces Postmark’s documented batch and payload constraints, maps each message, submits the request, and processes the returned results without assuming that submission itself represents durable asynchronous processing.
Implementation sequence
Postmark SMTP delivery
Postmark supports SMTP delivery for applications that submit email through SMTP rather than REST. SMTP credentials are configured separately from REST API tokens.
Martini implementation pattern
Martini implementation pattern: Martini uses SMTP only where an existing application or interface requires it, while REST remains the preferred path when templates, structured responses, message identifiers, and detailed error handling are needed.
Implementation sequence
Common Postmark integration patterns
Pattern 1: Send transactional template email from business events
When to use this pattern
Use this pattern when orders, payments, account changes, support cases, or other enterprise events must produce controlled transactional email. Template selection and model validation should occur before sending so malformed business data does not create avoidable Postmark failures.
Integration direction
Example Mapping
| Postmark Field | Canonical Field | Target Field |
|---|---|---|
| recipient email | recipientAddress | To |
| event type | notificationTemplateKey | TemplateId |
| order or case data | templateModel | TemplateModel |
| business correlation ID | correlationId | Metadata or stored integration key |
Martini implementation pattern
Martini receives the event through an API or workflow trigger, validates the recipient and model, selects the Postmark Template, maps and enriches the payload, applies rules such as notification eligibility, calls the template endpoint, and stores the returned message identifier. Transient failures can be retried while validation and recipient errors are routed for correction.
Martini capabilities used
- workflows
- API consumption
- data mapping
- business rules
- error handling
- secure environment configuration
Pattern 2: Synchronize delivery and bounce events
When to use this pattern
Use this pattern when downstream systems need reliable visibility into delivery, bounce, spam complaint, open, click, or subscription-change events. It is useful for updating customer communication status and preventing future sends to unsuitable recipients.
Integration direction
Example Mapping
| Postmark Field | Canonical Field | Target Field |
|---|---|---|
| MessageID | externalMessageId | PostmarkMessageId |
| Recipient | recipientAddress | |
| RecordType | deliveryEventType | EventType |
| BouncedAt or received timestamp | eventTimestamp | OccurredAt |
Martini implementation pattern
Martini exposes a protected callback endpoint, validates and normalizes the Postmark event, deduplicates by event and message identifiers, applies rules for hard bounces or complaints, and updates the target system. Slow downstream processing can be separated from callback acceptance through durable workflow processing or a queue where available.
Martini capabilities used
- API exposure
- webhook consumption
- data mapping
- business rules
- idempotency
- error handling
Pattern 3: Reconcile Postmark message activity on a schedule
When to use this pattern
Use this pattern when reporting, finance, customer operations, or compliance processes require a periodic view of Messages, Bounces, Suppressions, or statistics rather than relying only on callbacks.
Integration direction
Example Mapping
| Postmark Field | Canonical Field | Target Field |
|---|---|---|
| MessageID | externalMessageId | MessageId |
| MessageType or event type | activityType | ActivityType |
| DeliveredAt or event timestamp | activityTimestamp | OccurredAt |
| Recipient | recipientAddress | RecipientEmail |
Martini implementation pattern
A scheduled Martini workflow retrieves paginated Postmark data using a stored watermark and bounded time window, maps the results into reporting tables, deduplicates by stable message or event identifiers, and records checkpoints only after successful writes. Late-arriving results are handled through overlap windows rather than relying solely on timestamps.
Martini capabilities used
- scheduled workflows
- API consumption
- pagination control
- data mapping
- database integration
- checkpointing
- monitoring
Pattern 4: Process inbound Postmark email
When to use this pattern
Use this pattern when replies, support messages, or inbound email need to create or update business work items. It is suitable for associating inbound messages with orders, cases, customers, or automated classification workflows.
Integration direction
Example Mapping
| Postmark Field | Canonical Field | Target Field |
|---|---|---|
| From | senderAddress | RequesterEmail |
| Subject | messageSubject | Subject |
| TextBody or HtmlBody | messageBody | Description |
| Attachments | messageAttachments | Attachments |
Martini implementation pattern
Postmark forwards the inbound message to a Martini API endpoint. Martini authenticates and validates the payload, extracts sender, recipient, subject, body, headers, and attachments, identifies the related business object, applies routing and classification rules, and creates or updates the target item. Invalid payloads and downstream failures are recorded without acknowledging successful business processing prematurely.
Martini capabilities used
- API exposure
- workflow orchestration
- JSON handling
- data mapping
- business rules
- file and attachment handling
- error handling
Applications commonly integrated with Postmark
Postmark can be integrated with adjacent enterprise applications when transactional email, inbound message processing, or delivery status needs to be coordinated with business workflows. These are standards-based architecture patterns rather than claims of native Postmark integrations.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Salesforce | Send transactional customer notifications and synchronize delivery, bounce, or suppression status with Contacts, Leads, Cases, and related customer processes. | Salesforce → Martini → Postmark | Martini receives Salesforce business events or retrieves relevant data, maps it to a Postmark template model, sends the message through the REST API, and processes Postmark webhooks back into Salesforce. |
| Shopify | Send order, fulfillment, account, and customer notifications using Postmark templates while retaining delivery results for operational workflows. | Shopify → Martini → Postmark | A Martini workflow receives or polls Shopify events, validates recipient and order data, selects a Postmark template, sends the message, and records the returned message identifier and status. |
| HubSpot | Coordinate application-generated transactional email with customer records and make delivery or bounce information available to downstream processes. | HubSpot → Martini → Postmark | Martini transforms HubSpot-originated business data into Postmark message or template payloads and routes selected Postmark event notifications back to HubSpot or an operational data store. |
| ServiceNow | Send incident, request, approval, and notification email while processing delivery failures and suppressions for operational workflows. | ServiceNow → Martini → Postmark | Martini consumes ServiceNow events or API data, sends Postmark template messages, and exposes a protected endpoint for delivery, bounce, and complaint callbacks before updating ServiceNow. |
| Jira | Send issue, workflow, and project notifications from an application-controlled email service and retain delivery outcomes. | Jira → Martini → Postmark | A Martini workflow receives Jira-related events, applies notification rules, maps issue context into a Postmark template model, and stores message identifiers for event reconciliation. |
| Zendesk | Send support notifications and process inbound replies, delivery events, and bounce information in customer service workflows. | Zendesk → Martini → Postmark | Martini sends Postmark messages from Zendesk-related workflows and receives inbound email or webhook payloads, normalizing them before routing replies and status changes to Zendesk. |
How to build a Postmark integration in Martini
Objective
Establish the Postmark integration using the appropriate server token, account token, SMTP credentials, or webhook authentication model while keeping secrets outside workflow mappings and source code.
Instructions in Martini
- Use a server token for server-level sending and message operations.
- Use an account token only for account-level operations that require it.
- Store Postmark credentials in protected Martini secrets or environment configuration.
- Separate development, test, and production Postmark Servers where appropriate.
Objective
Select the trigger that matches the business process: an incoming API request, an application event, a Postmark callback, inbound email, or a scheduled reconciliation workflow.
Instructions in Martini
- Use an API or workflow trigger for business events that initiate email.
- Expose a protected Martini API for Postmark webhooks and inbound email.
- Use a scheduler for message, bounce, suppression, or statistics reconciliation.
- Define correlation and deduplication keys before processing begins.
Objective
Receive business data or Postmark event payloads and retrieve additional Postmark resources when the initial event does not contain the required detail.
Instructions in Martini
- Validate the structure and required fields of each input.
- Call Postmark REST endpoints for templates, messages, bounces, suppressions, or statistics as needed.
- Implement pagination and persist a watermark for scheduled reads.
- Treat callback coverage as limited to Postmark’s documented event types.
Objective
Coordinate validation, API calls, routing, enrichment, persistence, and downstream updates in a maintainable Martini workflow.
Instructions in Martini
- Separate input validation, Postmark communication, business rules, and target-system writes into clear stages.
- Route template sends, batch sends, delivery events, and inbound email through appropriate branches.
- Capture Postmark response status, error code, message identifier, and business correlation data.
- Use reusable workflow logic for common notification and event-processing behavior.
Objective
Convert source application data and Postmark payloads into stable canonical models before writing to downstream systems.
Instructions in Martini
- Map business fields into Postmark message or TemplateModel payloads.
- Normalize message identifiers, recipients, event types, timestamps, and delivery statuses.
- Encode and validate attachment content when attachments are required.
- Preserve useful unknown event fields where practical for forward compatibility.
Objective
Apply communication eligibility, suppression, retry, routing, and template-selection rules before committing integration actions.
Instructions in Martini
- Prevent sends to recipients identified by applicable suppression rules.
- Distinguish transient failures from invalid requests and permanent recipient failures.
- Use a business-level send key to reduce duplicate email risk.
- Validate template variables, sender configuration, attachment limits, and recipient requirements.
Common Postmark data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Servers | Represent logical Postmark environments used to send and manage email streams. | Configuration stores, deployment environments, monitoring platforms | Martini can call account or server APIs, keep environment-specific identifiers in configuration, and avoid mixing development, test, and production resources. |
| Messages | Represent individual outbound or inbound email messages with identifiers, delivery metadata, and activity information. | CRM, customer database, order system, reporting database | Martini maps message identifiers and business correlation keys, persists send results, and reconciles later delivery events idempotently. |
| Templates | Provide reusable email presentation and model-driven content for transactional messages. | Order, payment, account, support, and notification workflows | Martini selects the template, validates required model fields, maps business data, and invokes the template sending endpoint. |
| Bounces | Capture hard and soft delivery failures and related delivery information. | CRM, customer database, suppression process, monitoring platform | Martini receives webhook notifications or retrieves bounce data, classifies failures, applies business rules, and updates downstream communication status. |
| Suppressions | Identify recipients that Postmark should not send to because of bounces, complaints, or subscription changes. | Customer preference store, CRM, marketing operations, messaging database | Martini synchronizes suppression information, prevents prohibited sends, and reconciles changes using stable recipient or message keys. |
| Domains | Represent configured and verified sending domains for Postmark delivery. | Configuration management, deployment controls, sender administration | Martini can retrieve or manage domain-related data through account-level API operations while keeping account tokens protected. |
Authentication and security considerations
Token-based REST authentication
Postmark REST requests use server tokens for server-level operations and account tokens for account-level operations. These are HTTP header credentials rather than OAuth 2.0 or JWT access tokens.
SMTP and webhook security
SMTP credentials are configured separately from REST tokens. Postmark webhook endpoints can use configured authentication options such as HTTP Basic Authentication.
Martini secret management
- Store Postmark tokens and SMTP credentials in protected Martini secrets or environment configuration.
- Use separate credentials and Postmark Servers for development, test, and production.
- Protect callback APIs and avoid logging full message bodies, tokens, or sensitive attachments.
Operational considerations for Postmark integrations
Limits and pagination
Confirm Postmark plan limits, API restrictions, sending limits, batch limits, and payload constraints. Implement documented pagination for message, bounce, suppression, and administrative resources.
Idempotency and retries
Treat sends as potentially non-idempotent unless the specific endpoint provides an idempotency mechanism. Persist a business send key and Postmark message identifier, retry transient failures selectively, and do not retry invalid recipient or validation errors without correction.
Webhooks and schema changes
Validate callback authentication and event structure, tolerate duplicate delivery, and do not assume webhook coverage for every message or account state. Version template models and preserve unknown event fields where practical.
Attachments and observability
Validate attachment size, MIME type, filename, and Base64 payload impact before sending. Capture HTTP status, Postmark error code, correlation identifiers, and processing results without exposing sensitive content in logs.
Why use Martini instead of scripts or point-to-point integrations?
Orchestrate more than a single API call
Martini coordinates triggers, validation, template selection, Postmark API calls, downstream updates, scheduled reconciliation, and callback processing in reusable workflows.
Maintain a canonical data model
Mappings and transformations separate business systems from Postmark message, event, bounce, and suppression structures. This makes template changes, target-system changes, and reporting requirements easier to manage.
Build reliable integration behavior
Martini provides structured workflow logic for business rules, error handling, retries, monitoring, protected configuration, and idempotent event processing instead of leaving these concerns scattered across scripts or point-to-point integrations.
Frequently asked questions
Postmark can be integrated through its REST APIs for sending messages, templates, batches, Servers, Domains, Bounces, Suppressions, messages, and statistics. It also supports selected webhook-style event notifications, inbound email forwarding to HTTP endpoints, SMTP delivery, and attachments within message payloads.
Yes. Martini can consume the Postmark REST API, call template and batch endpoints, expose APIs for Postmark webhook and inbound-email callbacks, orchestrate workflows, transform payloads, and persist message or delivery results. A native Martini Postmark connector is not documented in the supplied materials.
No dedicated Postmark connector is required. Martini can integrate using Postmark’s native REST APIs, batch and template endpoints, webhook callbacks, inbound email forwarding, SMTP where necessary, and token-based authentication.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Postmark. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Postmark, cloud infrastructure, or other third-party systems based on their subscription, usage, and deployment models.
The REST API is generally the preferred method because it supports structured message, template, batch, identifier, and error handling. Webhooks are appropriate for selected delivery and engagement events, while SMTP is mainly useful for existing applications that cannot submit REST requests.
Yes, Postmark supports webhook-style notifications for selected deliveries, opens, clicks, bounces, spam complaints, and subscription changes. It can also forward inbound email to an HTTP endpoint. These mechanisms do not represent a general-purpose notification stream for every Postmark account or API change.
Martini can process callbacks in near real time or use scheduled workflows to retrieve Messages, Bounces, Suppressions, usage, and statistics through Postmark APIs. It can paginate results, use watermarks and overlap windows, deduplicate by Postmark message identifiers, and write normalized data to databases, CRMs, support systems, or reporting platforms.
Martini maps business data into Postmark message or template payloads and normalizes returned events for downstream systems. Workflows can distinguish validation failures from transient errors, retry eligible failures, record Postmark error details, and use application-level send keys plus returned message identifiers to reduce duplicate sends. Webhook handlers should also be idempotent.
Related Martini documentation
Workflows
Build a reliable Postmark integration with Martini
Use Martini to connect Postmark with enterprise applications, orchestrate transactional email workflows, process callbacks, synchronize delivery data, and manage integration reliability at scale.