Support

Pact is an actively developed platform. This page explains how to get unblocked quickly, what a good report looks like, and how issues move from a ticket to a fix.

Before you file: check these first

Most questions resolve faster with a quick self-serve check:

FAQThe most common setup, billing, consent, and data questions.Environment variablesIf a feature seems missing, it may be flag-gated — check the switch.Migration guideImport and connector questions.GlossaryTerminology used across the product and docs.

A feature that looks absent is often just gated

Voice, some AI, and staged admin surfaces are controlled by feature flags (the VOICE_*, AGENT_*, and AI_* families among others). If a capability isn't visible in your environment, confirm whether it's disabled for your tenant before reporting it as broken.

In-app support surfaces

Pact ships its own support tooling — cases, queues, an SLA clock, and a knowledge base — so if your organization uses Pact for its own customer support, those live under the Support section of the app:

CasesTrack and resolve support cases.QueuesRoute and prioritize incoming work.Knowledge basePublish self-serve articles.

Filing a good report

The fastest resolutions come from reports that let us reproduce the problem without a back-and-forth. Include:

1
What you did
The exact steps, the screen or endpoint (e.g. /v1/integrations/salesforce/sync), and the record type involved. If it's an API call, the request method and path — never paste tokens, keys, or passwords.
2
What you expected vs. what happened
The concrete difference. "The sync button returned 402" is actionable; "sync is broken" is not.
3
When and where
Approximate timestamp (with timezone) and your environment (production, staging, local). A 402 at a specific time lets us line it up against metering and logs.
4
Scope
One record or all of them? One user or the whole tenant? This decides whether it's a data issue or a systemic one.

Never send secrets in a support request

Do not include API keys, bearer tokens, passwords, or full customer PII in a ticket, screenshot, or log paste. If a credential looks wrong, describe the symptom — we can diagnose from error codes and request shapes without the secret itself. Provider keys belong only in the in-app BYOK/settings flow, which encrypts them.

How issues are triaged

Reports are prioritized by blast radius, not order of arrival:

Tenant-isolation or data-exposure concerns are treated as top priority — anything suggesting one tenant can see another's data, or that an identifier resolved cross-tenant, gets immediate attention.
Delivery, billing, and auth (the critical paths) come next: blocked or wrongly-sent mail, unexpected 402 metering lockouts, login/SSO failures.
Correctness and UX issues are scheduled against the active build.
Feature requests are logged against the roadmap; where a surface is currently a preview rather than an enforced backend, we'll tell you plainly rather than promising a date.

Status and outages

Live service status is surfaced through the status link configured for your deployment (NEXT_PUBLIC_STATUS_URL). During an incident, check status first — if it's a known outage, a fix is already in flight and a duplicate report won't speed it up. If you're seeing something the status page doesn't reflect, that's exactly the report worth filing.

Response times scale with severity, not with volume

A suspected security or isolation issue is escalated on sight. Everyday questions are answered against the team's working hours. Including the details above is the single biggest thing you can do to shorten resolution time.

FAQAnswers to the most common questions.SecurityHow Pact protects and isolates your data.APIThe REST contract for programmatic access.Migration guideGetting your data in.