Recently, our team had the opportunity to integrate with Salesflare, a customer relationship management (CRM) platform that aims to simplify the sales process and help businesses manage their customer relationships effectively. This experience provided us with invaluable insights into the Salesflare API which we are sharing in this article.

What We Learned about Salesflare API:

  1. Authentication and Authorization: Salesflare API uses bearer token based authentication, which means you need to use the key-value pair Authorization : Bearer APIKEY in the header to authenticate. OAuth2 is not supported, and a user needs to create an API token from Settings (API Keys) in Salesflare.

    We have integrated their authentication into Aurinko’s auth flow and created a login form for Salesflare authorizations:

  2. Comprehensive API: The API seems to cover all aspects of data management in the platform, i.e. managing contacts, accounts, opportunities, pipelines, tasks, tags. The platform does not seem to support calendars. Meetings, calls, notes are there too for activity logging.

    We worked closer with their contact object and here is what we noticed:

    • When receiving a contact the account field will actually have an object describing its account (their docs incorrectly state that it’s a number) but it’s a number field indead when you need to post an update.
    • A contact may have a list of positions (role + organization). Those are most likely loaded from Google or web scraped from LinkedIn. We have not seen this feature in other CRMs, only in Google Contacts.
    • There is only one field for email.
    • Phones can be accessed through an array (phone_numbers) and as individual fields (phone_number, mobile_phone_number, home_phone_number, fax_number).
    • Similarly, with addresses (array) vs address (one object).
    • Another thing that ис different from other CRMs is that those phone_numbers and addresses arrays can carry ‘archived’ contacts (essentially deleted).
    • We have not noticed structures to hold urls. Perhaps social_profiles are used for that.
  3. Documentation and Resources: The Online API documentation is quite comprehensive and provides ‘getting started’, ‘authorization’, ‘responses’ pages. The site is powered by Redoc which we love and also use. It would be nice to have more descriptions for individual methods and fields. For example, it is not clear how ?q= queries are supposed to be constructed.

  4. Useful Search Capabilities: Individual list methods support ‘?q=’, ?search=, and a number of other usesful query parameters and there is a dedicated [Persons] search endpoint that supports querying by a list of ids, email, or name. Lack of documentation for them is a problem though.

  5. Sync/Deltas API: The contacts list method supports modification_after query parameter, so it’s possible to load updates incrementally. But the list methods for Accounts and other objects don’t support such parameters. This seems inconsistent.

  6. Real-time Notifications: We have not found endpoints to set up real-time notifications or webhooks. But if you are looking to monitor contact changes modification_after query parameter is supported, so you could do polling.

Conclusion

Salesflare is a powerful CRM for small businesses focusing on simplicity, automation capabilities, and data insights. Integrating with Salesflare could provide a way to expand the market for your app.

We have extended Aurinko to support Salesflare API to make it a connector for our CRM Contact sync logic, so Salesflare contacts could sync to Google, Office 365, MS Exchange, or other CRMs. Developers can also access Salesflare contacts through our Unified Contacts API or define their own unified data models using our Virtualized API.