---
title: "Stripe Sync Customer"
method: POST
path: "/api/v1/customers/{customer_id}/stripe-sync"
tags: ["customers"]
---

# Stripe Sync Customer

`POST /api/v1/customers/{customer_id}/stripe-sync`

## Path parameters

- `customer_id` string, uuid, required

## Headers

- `authorization` string, nullable — Bearer <token>

## Response `200`

Successful Response

- EnvelopeCustomerResponse
  - `data` CustomerResponse, required
    - `id` string, uuid, required
    - `workspace_id` string, uuid, required
    - `name` string, required
    - `email` string, required
    - `handle` string, nullable
    - `avatar_url` string, nullable
    - `plan_tier` string, nullable
    - `plan_name` string, nullable
    - `mrr_cents` integer
    - `revenue_30d_cents` integer
    - `signup_date` string, date, nullable
    - `last_seen_at` string, date-time, nullable
    - `health` string, required
    - `churn_risk` number, required
    - `lifecycle_stage` string, required
    - `source` string, nullable
    - `primary_channel` string, nullable
    - `actions_30d` integer
    - `activity_14d` integer[], nullable
    - `last_activity_event` string, nullable
    - `last_activity_at` string, date-time, nullable
    - `notes` string, nullable
    - `signal` string, nullable
    - `bug_report_count` integer
    - `outreach_reply_rate` number
    - `last_open_at` string, date-time, nullable
    - `posthog_properties` object, nullable
    - `posthog_location` string, nullable
    - `resolved_timezone` ResolvedTimezone — Whose clock a customer's timestamps should be read in, and how sure we are. The single source of truth is ``app/services/customer_timezone.py``. It is exposed here because the profile page used to run its own precedence (``timezone`` then ``$geoip_time_zone``), which for our only live workspace resolves to the TENANT'S SERVER location rather than the person: measured 2026-08-31, geoip disagrees with the device clock 86.9% of the time on the population where both exist. So the UI showed one zone while the scheduler sent on another. Shipping the resolution rather than the raw properties is what stops those two from drifting apart again. ``source`` is carried so the UI can be honest instead of confident: ``device`` and ``workspace_property`` are worth calling "their local time", ``geoip`` and ``workspace_default`` are a guess and must be hedged. That is exactly the ``confident`` flag.
      - `zone` string, required
      - `source` string, required
      - `confident` boolean, required
    - `stripe_data` object, nullable
    - `revenuecat_data` object, nullable
    - `enrichment_data` object, nullable
    - `derived_properties` object, nullable
    - `enriched_at` string, date-time, nullable
    - `created_at` string, date-time, required
    - `updated_at` string, date-time, required
  - `meta` Meta
    - `request_id` string
    - `timestamp` string, date-time
    - `total` integer, nullable
    - `truncated` boolean, nullable
    - `reply_total` integer, nullable
    - `metric_total` integer, nullable
    - `people_total` integer, nullable

## Other responses

- `422` — Validation Error

## Changes

- **2026-09-05** `5691a8e12158` — 2 info
  - the `meta` response's property default value changed from `{"request_id":"","timestamp":"2026-09-04T03:53:05.348646"}` to `{"request_id":"","timestamp":"2026-09-05T02:09:45.736252"}` for the status `200`
  - the `timestamp` response's property default value changed from `2026-09-04T03:53:05.348646` to `2026-09-05T02:09:45.736252` for the status `200`
- **2026-09-04** `6be81c2b5273` — 5 info
  - added the optional property `meta/metric_total` to the response with the `200` status
  - added the optional property `meta/people_total` to the response with the `200` status
  - added the optional property `meta/reply_total` to the response with the `200` status
  - the `meta` response's property default value changed from `{"request_id":"","timestamp":"2026-09-03T19:42:04.697120"}` to `{"request_id":"","timestamp":"2026-09-04T03:53:05.348646"}` for the status `200`
  - …1 more
- **2026-09-03** `dd130eae1c32` — 2 info
  - the `meta` response's property default value changed from `{"request_id":"","timestamp":"2026-09-03T04:12:49.531787"}` to `{"request_id":"","timestamp":"2026-09-03T19:42:04.697120"}` for the status `200`
  - the `timestamp` response's property default value changed from `2026-09-03T04:12:49.531787` to `2026-09-03T19:42:04.697120` for the status `200`
- …earlier changes not shown

[Full history](https://skmtc.dev/minro/apis/minro-cs-platform/changes/api/v1/customers/:customer_id/stripe-sync/post.md)

---

[API](https://skmtc.dev/minro/apis/minro-cs-platform.md) · [All operations](https://skmtc.dev/minro/apis/minro-cs-platform/llms.txt) · [OpenAPI document](https://skmtc-service-production.skmtc.workers.dev/v1/apis/minro/minro-cs-platform/revisions/5691a8e12158/schema)