Skip to main content
The Support API lets your loan officers and processors file support tickets about a specific loan directly from your own tooling, instead of emailing or messaging the Pylon team. Tickets are created in Pylon’s support platform (Plain), where the support team triages and replies — and your integration can read the ticket’s status and full conversation back over the same API. Everything on this page lives under the support GraphQL namespaces:
  • support mutation — file tickets, add messages, request attachment uploads. Authorized with the create:support-ticket scope.
  • support query — discover issue types, read tickets and their conversations, list tickets. Authorized with the read:support-ticket scope.
The Support API is experimental: both namespaces additionally require the use:experimental-api scope, and their shape may change.

Discovering issue types

Every ticket is filed under an issue type — a stable key that routes the ticket to the right team. Query issueTypes to list the ones available:
The id (e.g. PRE_LOCK) is what you pass as issueType when filing a ticket. Issue types can change over time, so discover them at runtime rather than hard-coding the list.
To request a change to a loan’s terms (a change of circumstance), use loan.openChangeRequest rather than filing a ticket under a change-of-circumstance issue type. openChangeRequest files the support ticket for you and also records the change request on the loan; it returns the ticket ID as plainTicketId, which you then read back with the queries below.

Filing a ticket

Use the createSupportTicket mutation. A ticket is always about one loan, and carries the identity of the person filing it (the loan officer or processor) so support replies reach the right person:
Example variables:

Input fields

The response’s ticket.id is the ticket’s unique identifier (the underlying support thread ID) — hold on to it to read the ticket back or add follow-up messages. reference is the human-readable ticket number (e.g. T-1234) the support team will also use.
Additional recipients are CC’d on the email for that message only — each message carries its own list, and a later message does not inherit an earlier one’s. Each entry is an email and an optional name shown on the email, the address must be a valid one, and at most 10 are accepted per message.

Attachments

Tickets and messages can carry file attachments — a rate-sheet screenshot, a borrower document, a PDF. There are two ways to reference a document in attachmentDocumentIds:
  1. A document already on the loan — pass its document ID.
  2. A new file — upload it through the two-step flow below, then pass the returned document ID.

Uploading a new attachment

First, request an upload slot with the requestSupportDocumentUpload mutation:
Then POST the file to the returned uploadUrl as multipart/form-data with a single files field, authenticated the same way as your GraphQL requests:
The response contains the stored document’s ID, which you pass in attachmentDocumentIds when filing a ticket or adding a message. Attached documents are posted on the ticket as an internal note that the support team sees inline in the thread. The email copy of the message that the requester and any additionalRecipients receive contains the text only, not the files.
Attachment constraints:
  • Exactly one file per upload slot; request a new slot for each file.
  • Files must be between 1 byte and 50 MB. Larger files are rejected with a 400 and errorDetails.code of SUPPORT_ATTACHMENT_TOO_LARGE.
  • Executable and script file types (e.g. .exe, .js, .sh, .ps1) are rejected.
  • At most 20 attachments per ticket or message.
  • An upload URL expires 24 hours after it is requested (see expiresAt); request a new one if it lapses. Once uploaded, the document is stored on the loan and can be attached to tickets and messages any number of times.

Adding a message to a ticket

Follow up on an existing ticket with the addSupportMessage mutation:
additionalRecipients works the same way here, copying people on this reply only.

Resolved tickets are locked

Once the support team resolves a ticket (its status becomes DONE), the support platform locks the thread and it no longer accepts replies. Calling addSupportMessage on a locked ticket fails without sending anything:
Check extensions.errorDetails.code for SUPPORT_TICKET_LOCKED and do not retry: the ticket will stay locked. File a new ticket for the loan with createSupportTicket instead, and mention the earlier ticket’s reference (e.g. T-1234) in the body so the support team can connect the two. To avoid the round trip, read the ticket’s status first and hide the reply action in your UI when it is DONE. See Error handling for the general error format.

Reading tickets back

A single ticket

status reflects the ticket’s current state in the support platform (e.g. whether it is waiting on support, snoozed, or done). A ticket with status of DONE has been resolved and no longer accepts replies. This is also how you track a change request: pass its plainTicketId here.

A ticket’s conversation

supportTicketMessages returns the full thread, oldest first — both the messages filed through this API (author: REQUESTER) and the support team’s replies (author: SUPPORT):
additionalRecipients on a message is who was copied on it, so your UI can show the recipients alongside the sender. Poll this query to surface support replies in your own UI.

All tickets for a loan

All of your organization’s tickets

supportTickets is a paginated connection ordered by creation time, newest first by default. Pages are capped at 50 tickets:

Looking up the loan’s Pylon team

Sometimes the right move isn’t a ticket but a conversation with the people working the loan. The pylonTeam query returns the loan’s assigned team with contact details and booking links where available:

Operations reference

All operations also require use:experimental-api.