Skip to main content
Welcome to the uPortal360 API! The purpose of this document is to provide a guide for developers that are integrating 3rd party applications with the uPortal360 API. While many topics are covered, some details have been abbreviated or omitted for brevity. If you require assistance with a scenario that is not listed, please reach out to the UGA Finance Technical team for support at: salesforcedev@ugafinance.com.

Support

During development, you may always reach out to the UGA Finance development team for support at: salesforcedev@ugafinance.com When requesting support, we recommend you send the following when debugging specific endpoints: Make sure to remove any sensitive information when sending data!
  1. The endpoint you’re connecting to.
  2. The request headers
  3. The request body
    • Any sensitive data should be removed.
  4. The response body

API - General Usage

API Base URLs

Your credentials will be different for each environment. Don’t expect your sandbox credentials to also work in the production environment!

Requirements

In order to use the uPortal360 API, you must have the following:
  • OAuth 2.0 Protocol
  • TLS 1.2
  • User-Agent Header

OAuth 2.0 Protocol

Our authorization process uses OAuth 2.0. See the authorization section for more details. What is OAuth https://en.wikipedia.org/wiki/OAuth

TLS 1.2 Requirement

For security and compliance, we require that TLS 1.2 or greater be used. It’s likely the technology you use supports this without any extra work, however, in the off-chance that it doesn’t, connection errors will differ based on the platform and libraries you’re using. In general, the error message will reference SSL/TLS explicitly, or make reference to a “handshake” error, or an “error when establishing secure communication.”. What is TLS 1.2 https://en.wikipedia.org/wiki/Transport_Layer_Security

User-Agent Header

All HTTP requests must include a User-Agent header. The value of the User-Agent header is up to your discretion – we recommend following convention and identifying your application product name and optionally, your product version. Only the existence of the header is required by our firewall. Requests made without this header will receive an “Error 1010: The owner of this website has banned your access based on your browser’s signature”. https://support.cloudflare.com/hc/en-us/articles/360029779472-Troubleshooting-Cloudflare-1XXX-errors#error1010 What is the User-Agent Header https://en.wikipedia.org/wiki/User_agent

Format

The uPortal360 API supports only JSON in the request and response bodies, with authorization being the only exception. Other common formats, including XML, HTML, YAML, and TXT, are not supported. As a result, all requests that include a request body must include the following header:
Additionally, it is considered best practice to include the following header on all HTTP requests that will include a response body:
JSON Definition https://en.wikipedia.org/wiki/JSON

Authorization

The uPortal360 API requires that requests are authenticated with a Bearer token via OAuth 2.0. Please see the following sections for instructions on authentication.

Obtaining Credentials

Production Credentials - To receive production OAuth2 credentials, your company must work with our sales team to structure a program, and you will have to pass a code review with one of our integration specialists. For technical support, please contact us at: salesforcedev@ugafinance.com Sandbox Credentials - The Sandbox test credentials are shared across all credit application programs in our test environment and are reset daily. You can find the credentials in the request section below.

Retrieve Access Token

Using your credentials, request an access token for use with the API. To do this, make a POST request to the authorization server with credentials passed as form-data. Request
Response
The most important piece of this response object is the access_token. Use this as a Bearer Token authorization header for subsequent API requests. The expires_in value equals the number of seconds the access_token will remain valid for.

Using the Access Token

To use the obtained access token with the API, send the access token in an Authorization header with your request.
Sample Request (Valid Token) Requesting an endpoint with a valid access token will permit usage and evaluate the request. Request
Response
Sample Request (Expired Token) If you attempt to use the access token after it has expired, the API will return HTTP 401 Unauthorized. In this case, you must obtain a new token; this can be done by requesting a new token. Request
Response

Reference

This is the reference to available endpoints. All endpoints may be called in either the Staging or Production environment.

Test Data

The following mock information may be used to test desired outcomes in both the Staging and Production environments.

Applications

The /v1/applications endpoint is the entrypoint to the application process, and may only be used to create (POST) and update (PATCH) applications. Once an application has been decisioned, the application may no longer be updated.

POST

Use the POST request to create a new application. Request Accepts an ApplicationRequest
The apply field in the response should be used to send the consumer to the uPortal360 Apply application to finish the credit application process. Response - when request status is DRAFT Returns a DraftResponse
Response - when request status is PROCESS Possible return types: Example SuccessResponse

PREQUAL

Request Accepts an ApplicationRequest
Response - when request status is PREQUAL
No-Hit ScenarioIf a matching credit report was unable to be found while processing the application, a StandardResponse with a status of NO_HIT will be returned. When this happens, the application may be updated with corrected applicant information and re-processed.Consecutive No-Hit responses will result in the application being immediately declined.

Duplicate Contract Handling

Duplicate Contract OverviewOur system doesn’t allow Duplicate contracts. To get more information on the duplicate contract use the contract: id returned in the response, and follow this link Contract GET endpoint.Example Duplicate Contract Response
Bypassing Duplicate ContractUsing one of the Demo Cases below will bypass the duplicate check.
Duplicate Check Endpoint Use this standalone endpoint to run the SSN-based duplicate contract check during the application flow. It mirrors the logic used during normal application processing and is typically invoked right after the consumer clicks “Apply.”
Request body
Request notes
  • applicationId (path): required; identifies the application context and program.
  • applicantSsn: required; full 9-digit SSN (hyphens/spaces allowed).
  • No additional fields are required; caller should only invoke after any no-hit or credit-freeze checks have passed.
Behavior
  • Derives the duplicate search scope from the application’s finance program and its duplicate-account rule (top-of-hierarchy, ancestor accounts, account client number, or exact program). If the rule is N/A/empty, the program filter is empty and no duplicate will be returned.
  • Normalizes SSN into hyphenated and non-hyphenated forms and matches against applicant/co-applicant SSNs on active contracts (statuses not in Cancelled/VOID/Closed), returning the most recent match.
  • Read-only: no persistence; returns metadata for the caller to act on.
  • Response payload uses the standard ApiResponse envelope (data + errors).
Responses 200 OK – No duplicate found (or skip case)
409 Conflict – Duplicate found
400 Bad Request – Invalid input (e.g., missing SSN or application)
500 Internal Server Error – Unexpected failure

PATCH

Returns the same types as the POST method Use the PATCH request to edit an existing application. Only applications that meet one or more of the following criteria are eligible to be updated:
  • Mismatched on either the SSN or DOB
  • The application status is DRAFT
  • A No-Hit response was returned when processing the application
The PATCH request matches the POST request, however, all fields are optional. If a field is sent, the format validation still applies. If the location, program, or email is changed, the application will be compared against other applications in the database for duplicates; If a duplicate is found, the request will fail with HTTP status 409, and the response body will contain relevant errors and data, as described in the Error Codes article.

GET

A GET request may be made to retrieve a single application’s details. Request
Response Returns a CreditApplicationResponse

Bulk

Bulk load contracts into our system.

Fields Required for Bulk Transfer

Listed below are fields that will help with a successful transfer, but are not limited to these.

Bulk Transaction Required Fields

One of the following fields need to be set and not 0.

GET

The bulkRequestId variable should be the external Id of the bulk contract request object. Request
Response The contracts will be a list of contract external ids that were created.

POST

Request
Response The id is the Bulk Contract Request’s External Id that was created.

Contracts

View a certain contract.

GET

The contractExternalId variable should be the external Id of the contract. Request
Response Returns a ContractsResponse

Offers V2

Offers

View the available offers for a contract.

GET

GET


Path Parameters
Query Parameters
Request with a contract
Request with a contract

Notes
  • if the request is with a contract then the applicationId will return null
  • only offers that have a promotional period will return with “promo” populated
  • open contracts contain a minPaymentFixed property which only applies to open lines of credit

Closed Response Returns an OffersResponse
Open Response Returns an OffersResponse

Accept

POST

Accept the application’s credit decision to continue with contract creation. Request
Response Returns an AcceptResponse

Charges

View, modify, or create charges for a contract.

POST

Creates a new charge, or updates the most recent unsigned charge. Request Accepts a ContractChargeRequest
Response Returns a ContractChargeResponse

PATCH

Updates the specified charge. Request Accepts a ContractChargeRequest
Response Returns a ContractChargeResponse

PATCH

Updates the specified charge on non-charge slip contract. Request Accepts a ContractChargeRequest
Response Returns a ContractChargeResponse

GET (All)

View all charges on a contract. Request
Response Returns a ContractChargeListResponse

GET (Single)

View a specific charge. Request
Response Returns a ContractChargeResponse

Returns

  • Only one return is permitted per charge per day.
  • The maximum return amount allowed is limited to the original cash price.
  • If a return has already been processed, the maximum returnable amount is the cash price minus the total of previous returns.
  • If the return results in a refund, please allow 7–10 business days for processing.

POST

Create a return transaction on contract/chargeslip Request Accepts a ContractReturnRequest
Response Returns a ContractReturnResponse

GET (All)

Request
Response Returns a ContractReturnResponse

GET (Single)

Request
Response Returns a ContractReturnResponse

Support Tickets

Gets Support Ticket data and creates remarks.

GET (Single)

Get Support Ticket data from a single Support Ticket. Request
Response

GET Remarks

Returns all Private and Public (Support Ticket Notes Log) Remarks from a single Support Ticket. Request
Response

POST Add Remarks

Adds a Private and/or Public (Support Ticket Notes Log) Remark to a single Support Ticket. Request
Response Returns 201 Created if successful

PATCH

Support Ticket status must be “Merchant Review”. Updates a given Support Ticket with given data. Request
Response Returns Support Ticket data.

Patch Resolve

Support Ticket status must be “Merchant Review”. Sets Support Ticket status to “CHD Review”, sets Hold Date to today’s date, and sets Merchant Status to “Resolved”. Request
Response Returns Support Ticket data.

Identity Verification

GET (All)

Get all the questions Request
Response

GET (Single)

Gets next unanswered question Request
Response

POST (Answer single)

Answer question Request
Response Returns either the next question or the kyc result as FAIL or PASS

POST (Answer All)

Answer all KYC questions. Request
Response Returns the kyc result as FAIL or PASS

Envelopes

This endpoint will void a DocuSign envelope if it hasn’t been signed. Voiding an envelope will allow Merchants and Consumers to change contract or charge details and generate a new DocuSign envelope. If an envelope has already been signed, then it may no longer be voided. To void an envelope during the origination process, make a DELETE request to /v1/contracts/{contract-id}/envelope. To void an envelope on an additional charge, make a DELETE request to /v1/contracts/{contract-id}/charges/{charge-slip-id}/envelope.

Delete

To Void Origination Envelope
To Void an Additional Charge
Response Only should get back a 200 OK response with an empty body.

Contacts

This endpoint allows you to generate a login link to https://uportal360.com using your API credentials. The generated link is valid for 15 minutes. After 15 minutes, the endpoint should be called again to generate a new link. A link may be generated using a POST request to /v1/contact/generateTemporaryLoginLink: Request
Response Making a GET request with a web browser using the data.url value will automatically log the user into uPortal360. The link may be re-used for up to 15 minutes.

Demo Merchant User

These credentials could be used to access uPortal360. Test User Name and Password

Payment Methods

The payment method endpoints allow users to manage payment methods related to a particular contract. They support creating new methods, updating existing card details, deleting payment methods, retrieving stored methods such as cards or ACH, and discovering available types that can be added. Recommended Usage Sequence:
  1. GET
    • Retrieve existing payment methods and view available types and subtypes that can be added.
  2. POST
    • Create a new payment method using supported types returned from the previous step.
  3. PUT
    • (Optional) Update non-sensitive details of an existing card-based payment method, such as billing address or expiration date.
  4. DELETE
    • (Optional) Remove a payment method that is no longer valid or needed.

GET

Retrieve a list of saved payment methods (e.g., cards or ACH) associated with a contract. Also returns available payment method types and subtypes that the user can add (e.g., “Bank Account”, “Card” with supported subtypes). Usage:
  • Used by customer portals and admin tools to:
    • Display stored payment methods to the user.
    • Enable adding new payment methods based on available options.
  • Helps users understand what types of payment methods they can use and manage existing ones.
Request
Path Parameter
  • contractId (string) (required)
    • Description: The unique identifier for the contract or account that owns the payment methods.
    • Use: Scopes the request to a specific customer contract, ensuring only associated payment data is retrieved.
    • Example: ABC1234LOA01, ABC1234LOA02
Response
paymentMethods
  • paymentMethodId (string)
    • Unique identifier for the payment method.
  • contractId (string)
    • Associated contract identifier.
  • type (string)
    • Payment method type (e.g., “Credit Card”, “Bank Account”).
  • subType (string)
    • Card brand or bank account type (e.g., “Visa”, “Checking”).
  • lastFour (string)
    • Last 4 digits of card/account number.
  • expirationMonth / expirationYear (string)
    • Expiration info (only for cards).
  • firstName / middleInitial / lastName (string)
    • Cardholder or account owner info.
  • address1 / address2 / city / state / zip / country (string)
    • Billing address details.
  • autopay (boolean)
    • Indicates if this method is enrolled in autopay.

paymentOptions
  • type (string)
    • The general category of payment method the user can add, such as a card or a bank account.
    • “Credit Card” and “Debit Card” will be combined under “Card” in paymentOptions when applicable.
  • subTypes (string[])
    • Array of supported sub-types (e.g., card brands or account types).
Error Response
Possible cause:
  • Invalid or missing authentication.

Possible cause:
  • User doesn’t have access to the contract account.

Possible cause:
  • Unexpected server failure.

POST

This endpoint is used to register a new payment method (such as a credit card, debit card, HSA card, or ACH bank account) to a specific contract account, which is typically associated with a customer. Once the payment method is added, it can be used for recurring or one-time bill payments. For PCI compliance, the CVV is never stored and will not be saved under any circumstance. Each time a payment is made using a stored payment method, the CVV must be re-entered to complete the transaction. Usage:
  • A customer portal adds a payment method when a user updates their billing preferences.
  • A customer service representative uses this endpoint through an admin tool to register payment details on behalf of a customer.
  • The system will validate the structure of the request.
    • For cards:
      • The system will tokenize the card via a PCI-compliant service.
      • It may run a $0 or $1 authorization to verify validity.
    • For ACH:
      • The system will verify the account number via an identity service.
    • If successful, the system stores the method securely and associates it with the contract account.
Request
Path Parameter
  • contractId (string) (required)
    • Description: The unique identifier for the contract or contract account to which the new payment method will be linked.
    • Use: Identifies the contract account that the payment method is being attached to.
    • Example: ABC1234LOA01, ABC1234LOA02
Create ACH Payment Method Sample Request
Create Card Payment Method Sample Request
  • firstName (string) (required)
    • Description: The payment method holder’s first legal name.
    • Use: Used for billing verification and display on account records.
    • Example: John
  • middleInitial (string) (optional)
    • Description: Middle initial of the payment method holder.
    • Use: May be required for identity resolution or matching existing records.
    • Example: T
  • lastName (string) (required)
    • Description: The payment method holder’s last legal name.
    • Use: Used for billing verification and record keeping.
    • Example: Smith
  • address1 (string) (required)
    • Description: Primary street address.
    • Use: Required for AVS (Address Verification System) validation by card processors and for ACH verification.
    • Example: 1234 Maple Street
  • address2 (string) (optional)
    • Description: Apartment, suite, or secondary address line.
    • Use: Used in AVS checks.
    • Example: Apt 123
  • city (string) (required)
    • Description: City for the billing address.
    • Use: Used in AVS checks.
    • Example: Springfield
  • state (string) (required)
    • Description: State or province for the billing address.
    • Use: Used in AVS checks.
    • Example: IL
  • zip (string) (required)
    • Description: ZIP/postal code.
    • Use: Required for AVS (Address Verification System) validation by card processors and for ACH verification.
    • Example: 62704
  • country (string) (required)
    • Description: The billing address associated with the payment method.
    • Use: Used in AVS checks.
    • Example: UNITED STATES

ach
  • Note: Only one of ach or card should be populated.
  • accountType (string) (required)
    • Description: Indicates the type of bank account:
      • “CHECKING”
      • “SAVINGS”
    • Use: Some financial services use different processing rules or verifications based on account type.
    • Example: CHECKING
  • routingNumber (string) (required)
    • Description: The ABA routing number (also known as the bank routing number) that identifies the financial institution where the account resides. Exactly 9 digits in the U.S.
    • Use: Used to route the ACH transaction to the correct bank.
    • Example: 021000021
  • accountNumber (string) (required)
    • Description: The bank account number to be used for ACH transactions. Typically 6–17 digits.
    • Use: Identifies the specific bank account from which ACH payments will be pulled.
    • Example: 123456789012
card
  • Note: Only one of card or ach should be populated.
  • cardType (string) (required)
    • Description: Indicates the type of card:
      • “CREDIT CARD”
      • “DEBIT CARD”
      • “HSA”
    • Use: Indicates the functional category of the card being added as a payment method.
    • Example: CREDIT CARD
  • cardNumber (string) (required)
    • Description: The full 15–16 digit card number (PAN).
    • Use: Value will be encrypted and tokenized, never saved in plain text.
    • Example: 1234 1234 1234 1234, 1234 123456 12345
  • cardBrand (string) (required)
    • Description: The brand or network of the card:
      • “VISA”
      • “MASTERCARD”
      • “AMEX”
      • “DISCOVER”
    • Use: Identifies the card brand.
    • Example: VISA
  • cvv (string) (required)
    • Description: The 3 or 4-digit card verification value (CVV2 or CVC). CVV is never stored and will not be saved under any circumstance.
    • Use: Used for security and fraud checks during authorization.
    • Example: 123 1234
  • cardExpiration (string) (required)
    • Description: Indicates card expiration in MMYY format.
    • Use: Required for authorization and to ensure card validity.
    • Example: 0126, 1227
Response
  • paymentMethodId (string)
    • Unique identifier for the payment method.
Error Response
Possible cause:
  • Missing required fields or invalid format.

Possible cause:
  • Invalid or missing authentication.

Possible cause:
  • User doesn’t have access to the contract account.

Possible cause:
  • Invalid card or bank account details.
  • The payment method type cannot be added to this account at this time.
    • For example, if a user submits a payment method and the system detects through verification that it is a PrePaid card, and the contract is set up to not allow PrePaid, the system will return an error.

Possible cause:
  • Unexpected server failure.

PATCH

Updates non-sensitive metadata of an existing card-based payment method (e.g., expiration date, billing address, name).
  • Cannot be used for:
    • Updating ACH methods - must create a new one.
    • Changing card number - must create a new one.
Usage:
  • Update billing address or refresh card expiration details.
  • Used by customer portals or admin tools when the card is still valid but associated information changes.
Request
Path Parameter
  • contractId (string) (required)
    • Description: The unique identifier of the contract or contract account that owns the payment method.
    • Use: Used to scope the update to a specific customer account. Ensures the update is authorized and routed to the correct context.
    • Example: ABC1234LOA01, ABC1234LOA02
  • paymentMethodId (string) (required)
    • Description: The unique identifier for the specific card payment method to be updated.
    • Use: Determines which existing payment method record to update. Must refer to a card method, or the request will be rejected.
    • Example: ABC1234LOA01-A12
  • firstName (string) (required)
    • Description: The payment method holder’s first legal name.
    • Use: Used for billing verification and display on account records.
    • Example: John
  • middleInitial (string) (optional)
    • Description: Middle initial of the payment method holder.
    • Use: May be required for identity resolution or matching existing records.
    • Example: T
  • lastName (string) (required)
    • Description: The payment method holder’s last legal name.
    • Use: Used for billing verification and record keeping.
    • Example: Smith
  • address1 (string) (required)
    • Description: Primary street address.
    • Use: Required for AVS (Address Verification System) validation by card processors and for ACH verification.
    • Example: 1234 Maple Street
  • address2 (string) (optional)
    • Description: Apartment, suite, or secondary address line.
    • Use: Used in AVS checks.
    • Example: Apt 123
  • city (string) (required)
    • Description: City for the billing address.
    • Use: Used in AVS checks.
    • Example: Springfield
  • state (string) (required)
    • Description: State or province for the billing address.
    • Use: Used in AVS checks.
    • Example: IL
  • zip (string) (required)
    • Description: ZIP/postal code.
    • Use: Required for AVS (Address Verification System) validation by card processors and for ACH verification.
    • Example: 62704
  • country (string) (required)
    • Description: The billing address associated with the payment method.
    • Use: Used in AVS checks.
    • Example: UNITED STATES

card
  • cardExpiration (string) (required)
    • Description: Indicates card expiration in MMYY format.
    • Use: Required for authorization and to ensure card validity.
    • Example: 0126, 1227
Response
  • Payment method updated successfully.
Error Response
Possible cause:
  • Missing required fields or invalid format.

Possible cause:
  • Invalid or missing authentication.

Possible cause:
  • User doesn’t have access to the contract account.
  • User doesn’t have access to this payment method.

Possible cause:
  • Invalid card details.

Possible cause:
  • Unexpected server failure.

DELETE

Removes a payment method (ACH or card) from active use on a contract. The deletion is irreversible and recovery is not guaranteed. Usage:
  • Called when a customer or admin removes a saved payment method.
  • Can be used to manage expired, unused, or revoked cards/accounts.
Request
Path Parameter
  • contractId (string) (required)
    • Description: The unique identifier of the contract or contract account that owns the payment method.
    • Use: Scopes the delete operation to the correct contract account, ensuring that only authorized and context-specific deletions occur.
    • Example: ABC1234LOA01, ABC1234LOA02
  • paymentMethodId (string) (required)
    • Description: The unique identifier for the specific card or ACH payment method to be deleted.
    • Use: Specifies which existing ACH or card payment method to delete. Must exist and belong to the contract, or the request will be rejected.
    • Example: ABC1234LOA01-A12
Response
  • Payment method deleted successfully.
Error Response
Possible cause:
  • Missing required fields or invalid format.

Possible cause:
  • Invalid or missing authentication.

Possible cause:
  • User doesn’t have access to the contract account.
  • User doesn’t have access to this payment method.

Possible cause:
  • Unexpected server failure.

Payments

The payment endpoint allows users to initiate a charge using a previously stored and authorized payment method, enabling seamless transactions without re-entering payment details. Recommended Usage Sequence:
  1. GET Payment Methods
    • Retrieve the list of existing payment methods and available options for adding new ones.
  2. POST Payment Methods (if needed)
    • Add a new payment method if the user has not previously stored one.
  3. POST
    • Initiate a one-time payment using a stored and authorized payment method.
    • Note: The CVV must be re-entered at the time of payment, as it is never stored for PCI compliance.
For more details on managing payment methods, see the Payment Method API section.

POST

This API endpoint is used to initiate a payment on behalf of a user using a previously stored and authorized payment method. It enables systems to process charges without requiring users to re-enter their payment information. Usage:
  • A client application (web, mobile, or backend service) needs to charge a user for a specific transaction.
  • The payment method has already been securely stored (e.g., via tokenization or encryption) and is referenced by its unique ID.
  • When the payment is processed successfully, a receipt is automatically emailed to the user using the email address on file associated with the provided contractId.
    • The receipt includes:
      • Payment amount (in USD)
      • Date/time of payment
      • Payment method used (masked details)
      • Confirmation number, transaction ID, or order reference number
      • Merchant name
Request
Path Parameter
  • contractId (string) (required)
    • Description: The unique identifier for the contract or contract account to which this one-time payment is being made.
    • Use: Tells the system where to apply the payment.
    • Example: ABC1234LOA01, ABC1234LOA02
  • cvv (string) (required)
    • Description: The 3 or 4-digit card verification value (CVV2 or CVC).
    • Use: Used for security and fraud checks.
    • Example: 123 1234
  • paymentAmount (number) (required)
    • Description: The monetary value to be charged for this transaction. Must be a positive number and formatted to two decimal places.
    • Use: This is the actual charge amount in USD.
    • Example: 25.00
  • paymentMethodId (string) (required)
    • Description: A unique identifier for the payment method (e.g., credit card, ACH account) that has been stored and authorized for use.
    • Use: This ID is usually obtained from a prior call where the user added their payment method securely.
    • Example: ABC1234LOA01-A12
Response
  • Payment processed successfully.

  • Payment failed due to a decline reason.
Error Response
Possible cause:
  • Missing or invalid fields.

Possible cause:
  • Invalid or missing authentication.

Possible cause:
  • User doesn’t have access to the contract account.
  • Unauthorized use of the payment method.
  • Payment method is not available.

Possible cause:
  • Unexpected server failure.

Webhook

Application Status Change

  • Gives visibility to the progression of a Credit Application

Expected Responses

  • UAS expects to receive 200 when post is successful
  • UAS expects to receive 500 if not successful or not accepted by the receiver.

Payload: Headers

  1. Content-Type: application/json

Payload: Event Examples

Newly Drafted Application
Application Approved
Offer Accepted
Pending Application
Declined Application
Duplicate Application

Contract Status Change

  • Gives visibility to the status changes of a contract.

Expected Responses

  • UAS expects to receive 200 when post is successful
  • UAS expects to receive 500 if not successful or not accepted by the receiver.

Payload: Headers

  1. Content-Type: application/json

Payload: Event Examples

Went Past Due
Became Current
Account Paid in Full
Account Closed - Default
Account Closed - Product Returns
Contract Signed

Support Ticket Status Change

  • Gives visibility to the progression of a Support Ticket.

Expected Responses

  • UAS expects to receive 200 when post is successful
  • UAS expects to receive 500 if not successful or not accepted by the receiver.

Payload: Headers

  1. Content-Type: application/json

Payload: Body

Payload: Event Examples

Closed Support Ticket
Initial Review Support Ticket
Merchant Review Support Ticket
Pre-Buyback Support Ticket