Connection methods

Before you can handle chats and messages, you need to connect an account for the messaging provider you want to reach. This page covers the connection methods postpress offers and how to pick the right one for your product.

Overview

postpress provides two account connection methods so you can synchronize accounts across messaging and email providers in a way that fits your product. Both paths authenticate the user with the upstream provider and return a stable account id you can store on your side.

Supported authentication features for messaging

Supported authentication features for email

Hosted auth wizard

The hosted auth wizard is the quickest path to connect accounts. A single API call generates a short-lived link that redirects the user to a postpress-hosted flow. The wizard walks the user through every step and handles the authentication methods supported by each provider, including QR codes, 2FA, and one-time codes.

Custom authentication

If you want to embed the authentication form inside your own product, choose the custom authentication approach. You build the UI, collect the credentials, and call the postpress API directly. This gives you a tailored experience that matches your brand.

It is a more advanced integration. You are responsible for the flows that the hosted wizard normally handles for you, such as QR code scanning, 2FA challenges, and one-time passwords.

Recommended steps for account management

These steps assume you have chosen the hosted auth method, which is what most postpress customers ship with.

• Add a Connect an account button to your product. On click, call the hosted auth endpoint to generate a unique link and redirect the user to it.
• Store connected accounts in your database. A workable shape is id, user_id, account_type (such as LINKEDIN, GMAIL, WHATSAPP), account_id, status (OK, CREDENTIALS, and so on), last_update, created_on.
• Expose a backend endpoint that postpress can call when a user finishes a connection. Persist the returned account_id against your internal user_id so future API calls find the right account.
• Build a landing page for both success and failure outcomes that refreshes the user's account list. Add a Reconnect button per account that calls the hosted auth flow with the reconnect parameter.
• Configure a webhook in postpress to receive account status changes.
• Consume the webhook on your backend. Compare the new status with the stored one and react to changes. The status that matters most is CREDENTIALS, which means the user needs to reconnect. Surface this in your UI and, if appropriate, email the user.

Browser extension flow for LinkedIn

If your product ships a browser extension and you want to connect LinkedIn accounts, you can implement a background authentication flow. Reuse the cookie collected from the user's active LinkedIn session with custom authentication. When a disconnect webhook arrives, refresh the cookie and call reconnect without any action from the user, which keeps the experience seamless.

Recommended steps for cookie synchronization from a browser extension:

• Collect li_a, li_at, the user_agent, and the user's IP. For postpress, use a country-based IP. Parse the LinkedIn page for the user id, which lives in the JSON payload at { "data": { "plainId": ... } }, so you can detect account switches.
• Send this data to your backend on a regular interval. A workable shape is internal_user_id, postpress_account_id (empty on the first call), postpress_status, date_last_cookie, date_last_status, li_a, li_at, user_agent, ip, date_last_try_connect.
• When postpress_account_id is empty, call custom authentication to do the initial connection.
• When the LinkedIn account is disconnected and a webhook arrives, call custom authentication with the reconnect flag using the most recent cookie and the stored account_id. If reconnection still fails after a day, email the user to reconnect, and if date_last_cookie is stale, ask them to verify their extension is set up correctly.

Proxies

Some providers monitor the IP addresses used to access their services. If too many accounts connect from the same address, they may raise flags or trigger security measures.

To avoid this, postpress automatically assigns a fixed proxy to each account. When you call the API for that account, the request is routed through the proxy instead of going straight from our servers to the provider.

By default postpress picks a proxy near the user's IP. You can request a specific country, or provide your own proxy if you need to.

Available proxy countries

{
  "ar": "Argentina",
  "au": "Australia",
  "at": "Austria",
  "bd": "Bangladesh",
  "be": "Belgium",
  "bg": "Bulgaria",
  "br": "Brazil",
  "ca": "Canada",
  "cn": "China",
  "co": "Colombia",
  "cy": "Cyprus",
  "cz": "Czechia",
  "dk": "Denmark",
  "eg": "Egypt",
  "ee": "Estonia",
  "fr": "France",
  "de": "Germany",
  "hk": "Hong Kong",
  "gt": "Guatemala",
  "in": "India",
  "id": "Indonesia",
  "ie": "Ireland",
  "il": "Israel",
  "it": "Italy",
  "jp": "Japan",
  "my": "Malaysia",
  "ma": "Morocco",
  "mx": "Mexico",
  "nl": "Netherlands",
  "no": "Norway",
  "pa": "Panama",
  "pk": "Pakistan",
  "pl": "Poland",
  "pt": "Portugal",
  "ro": "Romania",
  "sa": "Saudi Arabia",
  "sg": "Singapore",
  "za": "South Africa",
  "es": "Spain",
  "se": "Sweden",
  "ch": "Switzerland",
  "th": "Thailand",
  "tn": "Tunisia",
  "tr": "Turkey",
  "ua": "Ukraine",
  "ae": "United Arab Emirates",
  "gb": "United Kingdom",
  "us": "United States"
}