The most common concern we hear from engineering teams evaluating Replylume is some version of "we already have Zendesk set up exactly the way we want it, and we don't want to rebuild our workflow." That concern is reasonable -- support infrastructure is painful to migrate, and the institutional knowledge embedded in a Zendesk configuration (macros, views, routing rules, escalation triggers) represents months of operational work. The good news is that Replylume is not a replacement for your helpdesk. It's an action layer that sits behind it, connected through standard APIs.
This guide covers the integration architecture specifically, what data Replylume reads and writes, and the security and permission model for each connection. If you're an engineer who needs to understand what you're actually authorizing before you agree to anything, this is written for you.
The Three-Layer Stack
When Replylume is integrated with a SaaS support stack, the architecture has three layers, and the data flows between them in a specific direction.
Layer 1 is the helpdesk -- Zendesk, Intercom, or Freshdesk. This is where tickets originate, where customer communications live, and where agents work. Replylume receives ticket data from the helpdesk via webhook (on ticket creation or on assignment to a designated Replylume-action queue). It writes resolution outcomes back to the helpdesk via API -- adding internal notes, sending the customer-facing resolution message, and closing the ticket. Replylume does not modify agent workflows, macros, views, or routing rules. It operates as an additional agent user in the helpdesk context.
Layer 2 is the billing system -- Stripe or Paddle. This is where Replylume reads order data (customer, order ID, amount, date, status) and issues refund actions when a ticket meets configured criteria. The integration uses OAuth scoped to read charges/orders and issue refunds. It cannot modify subscription plans, change payment methods, access financial reporting, or create new charges. The scope is narrow by design and defined at the OAuth grant level, not just by application logic -- which means the limitation is enforced at the API provider layer, not just in Replylume's code.
Layer 3 is the CRM -- Salesforce or HubSpot. This is where Replylume writes resolution records: a timestamped activity log entry noting the ticket type, the action taken (or the escalation reason), and the outcome. The CRM integration is write-only for activity records and read-only for customer health data when escalation logic is configured to use it. Replylume does not modify deal stages, contact ownership, account properties, or any other CRM field outside the activity log and a configurable resolution status field.
The Zendesk Integration in Detail
For Zendesk specifically, the integration uses a dedicated Replylume agent account in your Zendesk instance. This is intentional -- it means every action Replylume takes appears in the ticket audit log as attributable to a named entity ("Replylume Automation"), not as an anonymous API write. You can see, for every ticket Replylume touched, exactly what it did and when.
The connection flow: when a ticket is created and meets the initial classification criteria (configured in Zendesk's routing rules, by you, before Replylume runs), a trigger assigns it to the Replylume-action group. Replylume picks it up via the Ticket Events API, fetches the ticket body and customer contact record, queries the billing system for the associated order, evaluates against configured resolution criteria, and either executes the resolution (returning a closing update to Zendesk with the customer message and marking the ticket solved) or escalates it (adding an internal note with the reason and routing it to the appropriate human agent group).
The response time from ticket assignment to Replylume's action is typically under 15 seconds, end to end. The bottleneck is usually the billing API response (Stripe's charge lookup typically responds in 200-400ms; Paddle can run longer on their sandbox environments). The Zendesk write is fast once the data is assembled.
What Replylume Reads from Zendesk
Replylume reads the following fields from a Zendesk ticket: subject, body text (first message only for initial evaluation), requester email, ticket ID, created-at timestamp, current status, and any custom fields you've mapped to order identifiers. It does not read ticket comments after the first message, internal notes, or conversation history from prior tickets. If you have fields containing PII beyond what's needed for order lookup (for example, custom fields capturing full billing addresses), Replylume does not request those fields in its API calls.
When Replylume queries Zendesk's Users API to get the requester's email address for billing lookup, it accesses the email and name fields only. It does not pull the full user profile, organization associations, or custom user fields.
What Replylume Writes to Zendesk
Replylume writes two types of updates to Zendesk. On successful automated resolution: a public reply containing the resolution confirmation message (text you configure during setup, with order ID and refund amount filled from actual data), a status change to "Solved," and an internal tag for audit purposes. On escalation: an internal note with the escalation reason code, a status assignment to the configured human agent group, and no customer-facing message (the customer continues to wait for a human response rather than receiving an automated "being looked at" message, which in our experience generates more follow-up noise than it reduces).
OAuth Scopes and Security Posture
The Stripe OAuth application used by Replylume requests three scopes: read_only:charges, read_only:customers, and write:refunds. The write refund scope is the sensitive one, and it's worth understanding what it does and doesn't cover. Stripe's write:refunds scope allows issuing refunds against existing charges. It does not allow creating new charges, modifying subscriptions, updating payment methods, or accessing payout data. The scope boundary is at the API key provider level -- even if Replylume's code attempted to issue a new charge, the API call would be rejected by Stripe with a 403.
For HubSpot, Replylume uses two scopes: crm.objects.contacts.read (for health score lookups when escalation logic is configured) and crm.objects.contacts.write for activity log entries. The write scope is limited to creating engagement records (activity notes) -- it does not include updating contact properties, company associations, or deal data.
Local Deployment Considerations
Replylume processes ticket data in transit but does not persist customer PII beyond what's needed for the current resolution cycle. Resolution records (order ID, action taken, outcome, timestamp) are stored in Replylume's audit log for 90 days by default (configurable). Raw ticket body text is processed and discarded immediately after the resolution decision; it is not stored in Replylume's data layer. If you have GDPR or CCPA data minimization requirements for your support data, the data flow described above is the complete picture -- there's no secondary storage or analytics pipeline on customer content.
If your organization requires all processing to occur within a specific AWS region, we support region selection at the workspace level. Contact us to discuss the specifics before configuring your integration if this is a hard requirement for your procurement process.
What the Setup Actually Looks Like
Most teams complete the integration in a single afternoon session. The steps, in order: create the Replylume agent user in Zendesk and add it to a new group called something like "Replylume Action Queue"; configure a Zendesk trigger that routes matching tickets (you define the trigger criteria -- we suggest starting with your most clearly-defined refund category) to that group; connect Stripe via OAuth (takes about 90 seconds); connect HubSpot or Salesforce if you want CRM write-back (another 2-3 minutes); configure resolution criteria in Replylume's settings UI (the key decision points are the return window in days and the per-transaction amount threshold); run five test tickets through the staging environment; and enable for production.
The configuration is not code -- it's a form-based UI with clear labels. The one step that sometimes requires more than an afternoon is the resolution criteria configuration, specifically when the team hasn't previously written down explicit policy boundaries. If that's the case, the configuration step surfaces a useful internal conversation that should probably have happened earlier anyway.