Connect AI Stripe

CData Connect AI — Stripe Skill

⚠️ Prerequisites — load these first

• connect-ai-base skill

Before proceeding, locate and read the connect-ai-base skill. If it is not available in the current environment (not loaded, not enabled, or not installed), stop immediately. Do not proceed with the task. Tell the user that the connect-ai-base skill is required and ask them to install and enable it before continuing.

This skill provides Stripe-specific guidance for querying Stripe data through CData Connect AI. It composes on top of the connect-ai-base skill, which handles the discovery workflow, error recovery, SQL dialect, and three-part query naming convention.

Precedence

This skill replaces getInstructions for the Stripe driver. Do not call getInstructions for Stripe — the guidance it provides is already incorporated here and in the per-surface references. Proceed directly to getSchemas (to identify the surface — see below) and then schema discovery (getTables / getColumns) after identifying the Stripe connection via getCatalogs.

Stripe exposes two API surfaces

A Stripe connection presents one of two surfaces, determined by the CData Schema connection property. A connection exposes only the surface it is configured for, so getSchemas returns a single schema. The surface cannot be inferred from the connection name, so the first move on any Stripe connection is to identify it with getSchemas.

Always run getSchemas as the FIRST tool call against any Stripe connection — before any queryData, getTables, or getColumns call. Do not infer the surface from the connection name. The schema returned by getSchemas is the only authoritative signal: Stripe → classic surface, StripeV2 → V2 surface.

Step 1 — Identify the surface with getSchemas

Run getSchemas on the Stripe connection before anything else:

• Returns Stripe → classic surface → load references/stripe.md.
• Returns StripeV2 → V2 surface → load references/stripev2.md.

Step 2 — Load the matching surface reference

Each surface has its own reference with the full data model, query workflow, important columns, query patterns, stored procedures, write operations, and conventions. Read the one that matches the surface identified in Step 1 before writing queries:

• Classic → references/stripe.md — the customer-centric Customers / Invoices / Subscriptions / Charges / PaymentIntent model, the broad ~80-object catalog, monetary/unit and column-naming conventions, lifecycle stored procedures, cloud-compatible download patterns, and write operations.
• V2 → references/stripev2.md — the narrow V2 surface: EventDestinations and ThinEvents (which requires a filter), meter-event and event-destination procedures, and write operations. For customers/invoices/charges, the connection must use the classic Stripe schema instead.

The three-part name is always [Catalog].[Schema].[Table]:

-- Classic surface
SELECT [Id], [Email], [Name] FROM [YourConnection].[Stripe].[Customers] LIMIT 10

The middle segment is the schema (Stripe or StripeV2), not the connection name and not a "driver name."

Cross-cutting Stripe conventions

These hold on both surfaces, though the exact table and column names differ — see each reference for specifics.

• Identify the surface first. It dictates the object model and column conventions. Never assume — run getSchemas.
• Monetary amounts are integers in the smallest currency unit (cents). Divide by 100 for major-unit currencies (USD, EUR, …); zero-decimal currencies like JPY are already whole units. Never present a raw amount as dollars.
• Timestamps are exposed as SQL TIMESTAMP (the driver converts Stripe's Unix-epoch seconds).
• Discover columns with getColumns before querying. Stripe tables are wide and flatten nested API objects into prefixed columns. Confirm names on the live connection rather than assuming.
• Use explicit date literals ('2025-01-01') over DATEADD() for performance on time-based filters.