Contacts endpoint - please return more fields

Feature Requests
1

Working with the API contacts endpoint is made far more complex by returning so little information about Contacts. Please could this return:

  • is_client
  • is_supplier
  • id

I have tried a workaround to use the view=clients filter to get a list of clients to match the IDs from a general contacts search, but this requires me to download all client contacts every time I need to check whether a contact is also a client. This could involve many API calls.

For suppliers, the issue is the same.

Having to use regex to convert the URL field to the ID for future use is not ideal. Returning the ID as a value on its own makes the API cleaner and easier to use.

2

I find the concept of suppliers/clients a bit of an odd one in the API. You can add bills and invoices to the same contact so I wouldn’t think of contacts as necessarily falling into one of those two groups.

The ID should be in the url field returned in the JSON though if that helps? The API IDs marry up with what’s in the UI.

3

Hi Lawrence. Thanks for your feedback.

A Contact can be a Supplier, a Client, neither, or both. Within FreeAgent, I feel that filtering contacts is the main use for this, so it’s not that important.

However, within our App, we allow products to be matched to one or more suppliers to allow purchase orders to be created. We also record more information about suppliers (like product returns process/address, ordering websites, etc.). Suppliers are very different to clients in our App. Knowing which Contacts are also suppliers also helps us reduce the list of contacts substantially. Given FreeAgent records this information, it would be helpful to provide it within the API response :+1:

If the URL was the only ‘ID’ we needed to interact with the API that wouldn’t be an issue. The problem is that updating the Contacts/[id] endpoint uses the pure number ID (without the rest of the URL), but creating an Invoice uses

“contact”:“https://api.freeagent.com/v2/contacts/[id]”

Returning the ID we can live without but, would be a quality-of-life improvement :slightly_smiling_face: however, returning is_supplier / is_client would make a real difference to server usage for our App.

The API should use the URL or the ID, not both IMO. I understand that changing may require a new version, so I don’t expect this to change anytime soon!

4

Hey,

Just to be clear - I’m a customer of FreeAgent’s, I don’t work there!

We’ve got a few not too dissimilar challenges where we need to enrich data from FreeAgent (for us it’s managing things like external IDs for other applications).

We use a create or update method to sync everything down in a way that retains that additional information in a local cache table which is pretty fast.

I wonder if you could do something similar here? I’d be a bit wary of using “is there an invoice or a bill that exists” to effectively run any application logic as you’re potentially one bit of human error away from chaos.

5

Thanks for your ideas :+1:

No, I didn’t think you work for FreeAgent. I’m just hoping that someone from there reads the Topics marked as Feature Requests (not much use having the Category if no one does!).

When a new User joins and syncs thousands of contacts, it would be great for us to say “Here’s your supplier list!” immediately :slightly_smiling_face: We maintain our own Supplier/Customer fields locally, so don’t rely on FreeAgent’s data. There are workarounds, but this change to the API would save needing them.

6

Hi Timothy :wave:

Jamie from FreeAgent here. Thanks for reaching out, I can see why this would be useful. I’ve logged this internally as a feature request, this means this will get triaged by the correct team for consideration in due course. :slightly_smiling_face:

Kind regards,
Jamie

1 Like
7

That’s great, thank you, Jamie

Much appreciated :clap: