Getting support

How to get help and what to include in a support request.

View as MarkdownInstall skills

When something breaks in production, the fastest resolution comes from a well-formed request. This page shows how to self-diagnose first, where to reach us, and exactly what to attach so an engineer can reproduce your issue without a round-trip.

Self-service firstAsk

Most issues resolve faster than a support ticket can be triaged. Before contacting us, check:

  • Status page — confirm there is no active incident affecting Payments, Billing, or Engagement.
  • Troubleshooting — common errors, declined cards, and webhook delivery failures with fixes.
  • API reference — every error has a stable code; search it to find the cause and remediation.
  • Dashboard logs — the Developers → Logs view shows the full request and response for any API call by request ID.

Every API response includes a vinr-request-id header (for example req_8sKd2...). Quoting it in a ticket lets us pull the exact request, response, and internal trace in seconds.

Contacting supportAsk

ChannelBest forWhere
In-dashboard supportAccount-specific issues, billing, live dataHelp → Contact support
EmailAsync questions, follow-upssupport@vinr.com
Developer communityHow-to questions, integration patternscommunity.vinr.com
Security disclosuresVulnerabilities, suspected breachessecurity@vinr.com

Open tickets from the dashboard whenever possible — they arrive pre-populated with your account, environment (sandbox vs. live), and recent API activity, which removes a whole verification step.

Never include a full secret key (VINR_SECRET_KEY), card numbers, or raw webhook signing secrets in a ticket, chat, or email. Share the last 4 characters of a key if you must identify which one is in use, and rotate any credential that has been exposed.

What to includeAsk

A good report is reproducible. Gather these before you write:

Identify the resource

Copy the relevant object ID — pay_, sub_, inv_, loy_, we_, etc. One ID is worth a paragraph of description.

Capture the request ID

Grab the vinr-request-id from the failing response. If you do not log it yet, add it now.

State environment and timestamp

Tell us sandbox or live, and the UTC time of the failure so we can match logs.

Describe expected vs. actual

One sentence each: what you expected to happen, and what actually happened.

If you are filing programmatically or want to pull the diagnostic bundle yourself, fetch the event and any failed webhook deliveries:

import { Vinr } from '@vinr/sdk';
const vinr = new Vinr({ secretKey: process.env.VINR_SECRET_KEY });

// Pull the event behind a failed webhook so you can attach it to a ticket
const event = await vinr.events.retrieve('evt_3aF9...');

const attempts = await vinr.webhooks.deliveries.list({
  endpoint: 'we_2bQ7...',
  status: 'failed',
  limit: 10,
});

console.log({
  requestId: event.requestId,
  type: event.type,
  livemode: event.livemode,
  failedDeliveries: attempts.data.map((a) => ({
    id: a.id,
    responseStatus: a.responseStatus,
    attemptedAt: a.attemptedAt,
  })),
});

For raw API users, the same lookup carries the request ID back in the response header:

curl -i https://api.vinr.com/v1/events/evt_3aF9... \
  -H "X-Api-Key: $VINR_SECRET_KEY"
# -> look for the `vinr-request-id` header in the output

Severity and response timesAsk

Set severity honestly so our triage matches your actual impact. Targets below are for accounts on a standard support plan; enterprise agreements may define tighter SLAs.

Prop

Type

A "first response" target means an engineer engages with your ticket — not that the issue is resolved. Keep the ticket thread open and reply with new findings rather than opening duplicates, which reset the queue position.

Status and incidentsAsk

Subscribe to status.vinr.com for email or webhook alerts on platform incidents and scheduled maintenance. During a declared incident:

  • We post the affected systems (Payments, Billing, Engagement, Dashboard, API) and update at least every 30 minutes.
  • You do not need to file a P0 for a confirmed incident already on the status page — subscribe instead and we will post the all-clear.
  • After resolution, a post-incident review is published for any incident lasting longer than 30 minutes.

Build for resilience regardless of status: make webhook handlers idempotent, retry idempotently with an idempotency key, and reconcile against the API rather than trusting a single synchronous response.

Next stepsAsk

Was this page helpful?
Edit on GitHub

Last updated on

On this page