V2 LeadSource Endpoint is down

API Q&A
1 
{
  "code": 500,
  "message": "There was a problem loading these Lead Source records",
  "status": "Internal Server Error",
  "details": [
    {
      "domain": "leadsource",
      "resource": "GET /rest/v2/leadSources"
    }
  ]
}
2

Hi Christian, thanks for flagging this.

I just tested it on my end and it’s working as expected. When you have a moment, could you share the details of the request you’re making (or the curl you’re using)? That would help us compare and narrow down what might be happening here.

3

@Christian_Wiles - If the Filter parameter is not correctly set, you will get those type of errors. Make sure the equal signs are being formatted correctly.

4

Omar, respectfully, we are using the GET method in the URL and providing only the access token. This is working on all of our tables in bulk where v2 has a legitimate GET endpoint, with the exception of lead sources and payments. Here are the two URLs that we are having a problem with.

If the v2 method is get and it is a list, then we should be able to return the entire list, correct?

https://api.infusionsoft.com/crm/rest/v2/leadSources?access_token=123456789asdfghjk



https://api.infusionsoft.com/crm/rest/v2/sales/payments?access_token=123456789asdfghjk


Here are the error messages:

{
  "code": 500,
  "message": "Unknown error",
  "status": "Internal Server Error",
  "details": [
    {
      "domain": "sales",
      "resource": "GET /rest/v2/sales/payments"
    }
  ]
}

[6:58 AM]

{
  "code": 500,
  "message": "There was a problem loading these Lead Source records",
  "status": "Internal Server Error",
  "details": [
    {
      "domain": "leadsource",
      "resource": "GET /rest/v2/leadSources"
    }
  ]
}

{
  "code": 500,
  "message": "Unknown error",
  "status": "Internal Server Error",
  "details": [
    {
      "domain": "sales",
      "resource": "GET /rest/v2/sales/payments"
    }
  ]
}

Success with this as an example

https://api.infusionsoft.com/crm/rest/v2/products?access_token=123456789asdfghjk

Success:

{
“products”: [
{
“id”: “1733”,
“name”: “Deluxe Thanks Again No Feedback”,
“price”: {
“amount”: 0,
“currency_code”: “USD”,
“formatted_amount”: “$0.00”
},
“active”: true,
“shippable”: false,
“weight”: 0,
“taxable”: false,
“categories”: [],
“options”: [],
“inventory”: {
“inventory_limit”: 0,
“out_of_stock_enabled”: false,
“email_for_inventory_notifications”: null
},
“subscription_only”: false,
“storefront_hidden”: false,
“country_taxable”: false,
“state_taxable”: false,
“city_taxable”: false,
“subscription_plans”: [
{
“id”: “1137”,
“active”: true,
“prorate”: false,
“billing_cycle”: “MONTHLY”,
“billing_frequency”: 1,
“number_of_cycles”: 0,
“plan_price”: {
“amount”: 0,
“currency_code”: “USD”,
“formatted_amount”: “$0.00”
},
“order_index”: 1
}
],
“is_package”: false,
“needs_digital_delivery”: false,
“has_legacy_image”: false,
“create_time”: “2026-04-14T16:50:20Z”,
“update_time”: “2026-04-14T16:51:22Z”

5

@Christian_Wiles - To future proof your code, I recommend that you put the Access Token into the Header of the cURL call.

Authorization: Bearer 123456789asdfghjk

Not sure if this is causing you the problem with the “?access_token” URL parameter.

@OmarAlmonte can verify things on his end.

6

@Christian_Wiles Would you mind sending me a direct message with the app ID(s) you’re using when encountering these errors? That will allow us to take a closer look and investigate more thoroughly.

As a quick note, the access token should be passed as a Bearer token in the Authorization header rather than in the query parameters as @Pav mentioned. However, this would not be the cause of the errors you’re seeing, so there is likely something else contributing to the issue.

Thanks,
Omar

7

We have solved this problem.

It was not a problem with the endpoint. It was actually a problem where the leadsource did not have an active or inactive status setting.

This may have been because we had created a lead source via API and not set those fields when we created the lead source.

We can close this issue.

Thank you for the feedback @Pav @OmarAlmonte !

8

Thanks for the update, Christian. Glad to hear you were able to resolve it. We’ll still track this internally, as there’s an opportunity for us to improve the error handling in that scenario.