Gentic Subscriptions — Documentation

Check whether the calling organization has connected Loop (the Shopify subscriptions app). Returns `{ connected, shop_domain, updated_at }` when connected, or `{ connected: false }` otherwise. Free. Call before loop_sync to give the user actionable guidance when the integration is missing. Never returns the API token.

This tool takes no parameters.

Sync subscription data from Loop (the Shopify subscriptions app) into this organization's data backend — READ-ONLY, verbatim, one BOUNDED chunk per call. Uses the org's connected Loop integration (dashboard → Integrations; no API token is passed here). Warehouses four resources into per-org tables: `loop_subscriptions`, `loop_orders`, `loop_billing_attempts`, `loop_cancellation_reasons` (dedupe-upserted on their natural key, so re-syncs refresh rows in place). BOUNDED + RESUMABLE: each call pages the requested resources only until `max_pages_per_run` pages OR `max_seconds_per_run` seconds are reached, then returns `has_more` + `next_cursor: { resource, page_no }`. The recommended flow: call again passing that `next_cursor` back as `cursor` until `has_more` is false — the walk resumes exactly where it stopped. Returns `{ synced: { <resource>: count }, has_more, next_cursor, persisted }`. INCREMENTAL SYNC — READ THIS BEFORE SETTING UP A POLL. **Page order is NOT creation order.** Measured on a 400,000-subscription store (2026-09-16): Loop's unfiltered `/subscription` page 1 returned rows created in 2023-2024, not the newest ones. So a repeating poll that starts at page 1 re-reads the same old rows forever and NEVER reaches anything created since — it will report success every time while the warehouse silently stops moving. A page number is not a time cursor. TWO TIME FILTERS, FOR TWO DIFFERENT JOBS. Both are real Loop filters on `subscriptions` (2023-10), both take ISO-8601, and Loop ANDs them if you pass both. **`created_after` — BACKFILL THE NEW ONES.** Filters on creation time, so the result set is small by construction. This is what moves a warehouse that has fallen behind: `created_after` = the newest `created_at` you already hold, then page with `cursor` until `has_more` is false. One pass, done. **`updated_after` — KEEP EVERYTHING CURRENT.** Filters on Loop's updatedAt, so one pass catches new rows AND changed ones (cancellations, swaps, pauses). This is the hourly poll: `updated_after` = the start of your last SUCCESSFUL run minus ~1h of overlap (re-upserting is free — rows dedupe on their natural key — and the overlap covers a run that died midway), then page with `cursor`. DO NOT USE `updated_after` TO BACKFILL. Every active subscription`s billing cycle bumps its updatedAt, so on a 55,000-subscription store a six-week `updated_after` matched 40,000-55,000 rows — 400-550 pages — in no useful order, with the few rows actually created in that window buried deep inside. Measured, 2026-09-17. `created_after` covers the same window in roughly 100 pages on that store (it creates 5,000-8,000 subscriptions a month), against 400-550 for `updated_after` — still a real walk, so page it with `cursor`, but a bounded one that reaches the new rows immediately instead of after hundreds of pages of 2021-2024 subscriptions. Both are `subscriptions` only; asking for either on another resource is an error, not a silently-unfiltered walk. FREE.

Check whether the calling organization has connected Skio (the Shopify subscriptions app). Returns `{ connected, shop_domain, updated_at }` when connected, or `{ connected: false }` with a hint otherwise. Free. Call before skio_sync so a missing integration produces actionable guidance rather than a failed sync. Never returns the API token. Set check_schema to true to also VERIFY the connection against Skio and compare our GraphQL query against Skio's real schema — it reports, per resource, any field we request that Skio does not have (which would fail a sync outright) and any field Skio has that we do not request (which would be silently missing from the synced tables). AFTER CONNECTING A NEW SKIO ACCOUNT, call this with check_schema:true and read `available_not_selected_detail` BEFORE trusting the first data pull — a result that reports success can still have silently omitted fields, and ten field names in our query did not exist in Skio's schema when first checked against a real account. Re-run it if queries later start failing.

Sync subscription data from Skio (the Shopify subscriptions app) into this organization's data backend — READ-ONLY, verbatim, one BOUNDED chunk per call. Uses the org's connected Skio integration (dashboard → Integrations; no API token is passed here, and there is no shop argument — a Skio token is scoped to one shop when it is minted). Warehouses four resources into per-org tables: `skio_subscriptions`, `skio_subscription_lines`, `skio_orders`, `skio_order_line_items`, upserted on their id so re-syncs refresh rows in place. BOUNDED + RESUMABLE: each call pages only until `max_pages_per_run` pages OR `max_seconds_per_run` seconds are reached, then returns `has_more` + `next_cursor: { resource, after_id, order: "id" }`. Call again passing that back as `cursor` until `has_more` is false — the walk resumes exactly where it stopped. Returns `{ synced: { <resource>: count }, has_more, next_cursor, persisted, pages_fetched }`. THE WALK IS PARENT-DRIVEN, AND THAT IS WHY IT COMPLETES. Only the parent tables are paged — `subscriptions` and `orders` — keyset on `id` (`id _gt`, ordered by `id`), with `created_since` / `updated_since` applied as plain filters on the parent. The line tables are never paged on their own: for each parent page, all of its `subscription_lines` / `order_line_items` are fetched by foreign key in one request. `resources` therefore names what gets STORED, not what gets walked — see that parameter. WHY, MEASURED ON A REAL STORE (2026-09-29). Ordering by `updatedAt` while filtering on `createdAt` made the sort key and the filter key different columns, so the walk entered the `updatedAt` index at the oldest row and rejected rows until it reached the filtered range: the FIRST page of `orders` took over 60s. The same filter ordered by `id` takes about 147ms. The line tables are worse and cannot be fixed by any filter — `order_line_items` took over 45s for one page under a bare primary-key keyset, and over 60s under any time predicate — while the same rows fetched by foreign key for 100 parents come back in about 400ms. So there is no fast way to page the line tables directly, and there is no need to. CURSORS FROM OLDER SHAPES ARE REFUSED, NOT REINTERPRETED. The `offset` and `{ after_updated_at, after_id }` shapes both encode a position that means nothing in an `id`-ordered walk; honouring one would resume somewhere arbitrary and report success. If you hold one, drop it and re-run — every resource upserts on `id`, so re-reading costs time and never duplicates. If a page times out, RAISE `page_size` rather than lowering it — see that parameter. FREE.