> ## Documentation Index > Fetch the complete documentation index at: https://docs.rippit.com/llms.txt > Use this file to discover all available pages before exploring further. # Pylon > Technical reference for the Rippit Pylon data integration: API token authorization, US and EU regions, API endpoints, what an issue becomes in Rippit, and sync behavior. A read-only API token integration that syncs Pylon issues, their messages, and your Pylon users into Rippit on a schedule. For what applies to every integration, see [how data integrations work](https://docs.rippit.com/plg/data-integrations.md). For the security model, see [Data integration security](https://docs.rippit.com/security/data-integrations.md). This page covers the data integration. To let the Rippit agent search Pylon live instead, see the [Pylon connector](https://docs.rippit.com/agentic-chat/connectors/pylon.md). ## Connection summary | | | | - | - | | Authorization | A Pylon API token, sent as a Bearer token | | Scope parameter | None | | Token requirement | Only Pylon Admins can create API tokens | | Writes to Pylon | None. Calls are `GET`, or `POST` to Pylon's issue search endpoint, which takes its filters in the request body | | Credentials shared with Rippit | The API token. Rippit stores it and uses it for every sync | | Credential check | The token is tested against Pylon before the connection is created. Rejected tokens create no connection, and Rippit does not keep them | | Connection identity | Your Pylon organization, read from the token. One connection per organization | | Region | Detected from the token. US and EU Pylon accounts are both supported | | Required Rippit role | Workspace admin | | API base | `https://api.usepylon.com` for US accounts, `https://api.eu.usepylon.com` for EU accounts | | Sync method | Scheduled polling | | Attachments | Not downloaded | | Maximum historical backfill | 90 days. The default is 7 | ## Before you connect Rippit asks for one value: an API token. Create it in Pylon under **Settings → Integrations & dev → API tokens**. Only Pylon Admins can create tokens. Tokens cannot contain spaces. You do not choose a region. EU tokens start with `pylon_api_eu_`, and Rippit uses the EU API for them. Older tokens without a region prefix are tried against the US API first, and against the EU API if Pylon reports that the token belongs to the other region. ## Data handling | Question | Answer | | - | - | | Is issue content ingested, or only metadata? | Full content: each issue, every message on it, and your Pylon users | | Are internal notes ingested? | Yes. Private messages are stored and marked as not public | | Are attachments stored? | No. Rippit does not download files attached to Pylon messages | | Can Rippit modify Pylon? | No. No write code path exists | | Is data used to train models? | No. Rippit does not train any AI models. Your data is used for inference only | ### What an issue becomes in Rippit Each Pylon issue becomes one conversation in Rippit. | Rippit record | Content | | - | - | | Subject | The issue title | | Agent | The issue's assignee | | Start and end | The issue's created time and the time of its latest message | | Link | The issue's link in Pylon | | Fields | Status (the issue state), platform (the issue source), tags, assignee, issue number, issue type, team ID, customer account ID, CSAT score (from the issue's most recent CSAT response), first response time in seconds, and resolution time in seconds | | Default selected fields | Subject, status, platform, tags, assignee, CSAT score, commenters, first commenter, and last commenter | | Conversation comments | Every message on the issue, with its HTML body, its time, and its author's name. Messages are attributed to the Pylon user or contact who wrote them | | People | Pylon users, including deactivated users, with name and email. They are the agents assigned to issues | ## API endpoints ### Authentication | Purpose | Endpoint | Method | | - | - | - | | Credential check, region check, and organization lookup | `/me` | GET | ### Issues, messages, and users | Object | Endpoint | Method | | - | - | - | | Issues updated in a time window | `/issues/search` with an `updated_at` `time_range` filter and `limit` 100 | POST | | A single issue, to re-sync it | `/issues/` | GET | | An issue's messages | `/issues//messages` | GET | | All users, including deactivated users | `/users?include_deactivated=true` | GET | | A sample of issues, for field discovery | `/issues/search` with `limit` 100 | POST | Issue search pages with a cursor returned in the response. Rippit sends it back in the next request body with the original filter. Messages are not part of the issue search response. Each issue returned by the search has its messages fetched separately, one request per issue. ## Sync behavior | | | | - | - | | Issue discovery | Windowed on issue `updated_at`, cursor pagination | | Window width | 7 days, one window at a time | | Trailing buffer | Each window closes 5 minutes behind the current time | | Messages | Fetched per issue, one request each, one at a time | | Users | Full list once a day | | Re-sweep | Once a day the last 24 hours of issues are listed again, which picks up issues missed the first time | | Update handling | An updated issue is listed again, and the issue and its messages are refetched | | Resumption | High water mark on issue `updated_at`. Changed issues only, no full rescan | ## Rate limiting Pylon limits requests to an issue's messages to 120 per minute for each organization. Rippit fetches messages one issue at a time to stay under it. When Pylon returns `429`, Rippit waits for the time in the `Retry-After` header and tries again. Because messages take one request per issue, a large backfill spends most of its time there, which is why the default backfill is 7 days. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.